The empathy test for agentic software delivery

It's easy to buy into the narrative that AI is best at coding and software. That's not wrong, but without human judgment and guidance at the right points, you will release the wrong things at best, and damage your brand's reputation at worst.

An early bad assumption by an AI agent can lead to a problematic release to users before anyone at your company notices. What makes this worse is the wasted human effort to automate these workflows (yes, you still need humans to set up those AI pipelines!) and the mountains of unnecessary LLM tokens.

These complications point to why AI hasn't yet produced a measurable productivity gain. Companies bolt it onto old ways of working without reconsidering where human judgment shapes the outcome. The level of human empathy and context needed to make decisions drives your entire journey into AI-enabled automation.

Apply the same thinking to software delivery. You must decide what agents can own, establish shared context, and manage cultural change to make the software delivery process work in this brave new world.

Before delegating any part of software delivery work to an agent, we ask two questions. We call it the empathy test:

• Does this outcome depend on understanding and taking responsibility for its effect on people (empathy), or is it better judged impersonally against explicit criteria? Here, empathy does not mean warmth, intuition, or language. It means understanding how a software decision lands with customers, employees, partners, and the organization, and being accountable for the consequences.
• Does the right answer depend on the current situation, or can it be determined from something explicit and verifiable? Choosing a technical architecture may depend on this organization's strategy, existing systems, skills, and constraints. Running a well-defined regression test suite can be documented and explicit.
  

Humans, and only humans, decide the answers to this test. Its purpose is to help understand the consequences of decision-making before delegating work to agents and to put effort (and tokens) towards the pieces of work that can best leverage AI tooling with low risk.

Plot your answers against each other, and the decisions and actions inside a software delivery project fall into four places. An entire project doesn't belong in one box. Break it into decisions and actions, then assign each one the appropriate operating model.

The empathy test helps determine how much leeway agents have to make decisions and how humans supervise that work. The test doesn't tell you how dangerous a mistake would be to release to users. For example, a data migration can be fully documented and impersonal while carrying enormous risk.

Some classes of changes, or even whole pieces of software, carry varying levels of risk if released to users. The empathy test process encourages us not to build something that's too risky. But even if you do, it's not too late to wait, or even not release it at all.

To mitigate the risk early, apply a "blast-radius test" to any process you're considering agentifying/automating:

• How confident are you that your software delivery pipelines can detect problems before this gets to users?
• How quickly would you detect an error if it did get to users?
• How far could the issue spread?
• Could you reverse the change safely?

The answers determine how much freedom the agents get.

Consider release risk when building, but it's a crucial human gate to help you decide if, when, and how to push your change to users. And we know what you're thinking: Yes, use agents to help direct and inform your decisions.

There may be some changes that your business is ok with releasing to users fully agentically. But those changes should fit a well-defined pattern, and you should have plenty of human-directed "reps" of that process before letting the agents go fully autonomous.

As tools and processes get more advanced, organizations are getting much better at this, so we expect the number of fully agentic user releases to increase as the whole industry matures.

A retail brand is experiencing high cart abandonment. The suspected cause is the flow's complex fraud-verification steps. They need to analyze and (potentially) rebuild their checkout flow.

The growth opportunity here is helping more customers complete their purchase. Starting with that outcome gives the team a reason to change the checkout-and a way to judge whether faster delivery actually creates value.

Here's an experiment to try: Take your software delivery team's last two weeks of work and sort its decisions and actions into the four empathy test quadrants. Look for documented, impersonal work that consumed experienced people's time. Those are the places to start getting your agentic "reps" in and build outward from that.

Ideally, as a quick follow-on, you want to agentify processes that are large enough that they require the whole team surrounding how software gets to users - not just developers or engineers. This includes business analysts, project managers, product owners, key business stakeholders, and others. Through a release-risk lens, they should also be relatively low risk.

Agentic software delivery isn't a destination or tool rollout. It requires reconfiguring processes and the ability to delegate while staying intimately aware of internal operating decisions. Tools and ways of working change too fast for anyone to call their toolset and playbook "done."

Once the hype moves on, the teams producing the most value will keep experimenting with new tools, sharing what they know, writing down decisions, learning from what works and what fails, and changing how they work together without giving up human judgment or accountability.

As agents take on more routine work, your team gains capacity to test a new service, improve a customer journey, or pursue a product idea that previously cost too much to explore. Human judgment helps decide which opportunities deserve that investment.

The goal isn't to build agents that pass the empathy test. It's to build a team that never stops applying it.