A carmaker had a paint defect on roughly one in forty cars. Consultants spent three months on sensor data, operator interviews and defect logs, and delivered a 94-page report. The root cause was a humidity swing, triggered by an air-conditioning timer, that disturbed the paint during the second shift. The fix took two days.

Now picture an agent watching the same 38 sensors. It sees the defect rate creeping up on the first afternoon, links it to the pressure and humidity readings, checks the maintenance log and hands the plant manager a short brief: two ranked hypotheses and a test for each. (The example comes from Davar Azarmi's Generative AI for Leaders series.)

That is the shift from AI that answers to AI that acts. Most organizations still use AI for the first scenario, only faster. The prize sits in the second one. And you do not win it by buying a tool. You win it domain (e.g. value stream or customer journey) by domain, through a learning journey that leaders have to own.

From answers to actions

A model answers when asked. An agent works toward a goal: it breaks a task into steps, picks its tools, acts, looks at the result and adjusts, until the job is done or it needs a person. Engineers sum it up as agent = model + harness. The model thinks. The harness is the software around it that decides which systems it can reach, what it remembers, what it may touch and when it has to stop and ask.

That makes the harness, not the model, the part your organization has to build. Someone has to connect the agent to the sensors and give it the maintenance logs. Someone has to define what counts as anomalous on a paint line, decide whether the agent may change the timer itself or only recommend a change, and set up the monitoring that shows what it did. Every one of those choices is a business decision, and it takes people who know the domain.

McKinsey's Rewired shows the same pattern at E.ON Next, where a team of eight agents works through the customer conversation. More than 40% of calls are fully identified and verified by the voice agent, and the cost of handling an inbound call fell by close to 50%. The authors' lesson: the value comes from redesigning the workflow, not from the cleverness of the agent.

The learning journey of a domain

Rewired describes four levels of agentic AI, each more complex than the last. We read them as four learning stages, because at every step the domain has to learn something new, and what worked on the previous step stops being enough.

  1. Individual augmentation. People use AI to draft, search and summarize. The domain learns the basics: what the tools can and cannot do. Personal productivity gains of 20-30% on single tasks are common, but the impact is too diffuse to show up in the P&L.
  2. Task automation. An agent takes over a repeatable task or a simple workflow, with a human still in the loop. The domain learns to spot which tasks are worth automating. Cycle times and handling costs improve by 20-40%, but little sets you apart from competitors.
  3. Agentic workflows. Teams of agents run a workflow end to end and people move above the loop, overseeing the agents. The domain learns to redesign the process itself: reorder steps, merge tasks, open up data. This is where the value turns strategic.
  4. Agentic systems. Agents optimize across several workflows at once, for example dispatching technicians, rescheduling visits and ordering parts. The domain, and the leadership around it, learns to run a different operating model. The book says plainly that this asks for a clear break with past practice.

Most companies today sit on the first two steps, buying off-the-shelf tools for narrow use cases. That is a fine start. The trap is to stay there and call it a transformation.

You cannot skip a step. A team that has never worked with AI in its daily tasks will not suddenly redesign a workflow around agents. Azarmi puts it well: autonomy should be earned, not granted. The organizations that scale agents successfully are patient enough to let reliability come before reach.

Autonomy is a dial, not a ladder

The four stages describe what a domain can do. A second question is how far the human steps back on each task. A framework from researchers at the Knight First Amendment Institute at Columbia University names five roles for the person: operator, collaborator, consultant, approver and observer. Down the list, the agent does more and the person does less.

Resist the urge to treat that as a ladder you have to climb. The goal is to match the level to the task. Some work belongs at the operator level because an error costs too much or the judgment is too human. Well-defined work with bounded stakes can run with a person approving only at the gates. Full autonomy is possible, but it only makes sense when the worst a bad run can do is something the business can absorb. Otherwise the emergency stop is decoration.

Every level has its own way of failing. Collaborators drift apart when they lose shared context. A consultant-style agent asks too often or too late. Approvers start rubber-stamping routine requests until a consequential one slips through, and even a careful approval cannot audit the chain of reasoning behind a decision. Observers have no gate left at all.

So autonomy is a dial. Leaders turn it up where the evidence supports it and leave it alone where it does not. That judgment cannot be delegated to the technology team, because it depends on what the domain can afford to get wrong.

What it costs and what can go wrong

Autonomy is paid for in three currencies: money, reliability and security.

  • - Money. A single model call costs a fraction of a cent. An agent that reasons over ten steps, calls tools and retries can cost anywhere from cents to several dollars for the same task, which is orders of magnitude more. At a thousand tasks a day, agent usage becomes an operating cost you budget like cloud computing.
  • - Reliability. Errors compound across steps. A model that is right 95% of the time per judgment produces a workflow that is right only about 60% of the time over a chain of ten. Agents can also drift from the original goal through a series of locally sensible choices, with no failed step to point at.
  • - Security. Agents that read emails, documents and web pages can be steered by instructions hidden in that content, a trick known as prompt injection. Sometimes a false fact is enough: the agent accepts it and carries the error through every step that follows.

 

Two more risks come with scale. A thousand loan officers make a thousand different mistakes, and many cancel out. One agent running a thousand times makes the same mistake a thousand times, on the same day. And liability has not caught up. In 2024 a tribunal ordered Air Canada to honor a bereavement fare that its chatbot had invented. The company owns what its agent does, whether or not a human reviewed it.

None of this is an argument against agents. It is an argument for managing them the way you would manage people you hire: define what each agent is authorized to do, put human checkpoints on high-stake decisions, make every consequential action traceable, and watch the cost per task.

What a change like this does to a domain

Take a customer service team of fifty people handling ten thousand tickets a week. A copilot makes them faster, but the team looks the same. Now an agent resolves 40% of the tickets without a person. The team handles six thousand tickets, and they are the hard ones: edge cases that need judgment and empathy. The skills the team needs move from volume to exceptions. The management metrics move from throughput to quality. Careers move from efficiency to expertise.

The pattern repeats across functions. Developers spend more time on architecture and design while coding agents do routine implementation. Compliance analysts focus on novel risks while agents handle standard monitoring. In Rewired terms, people move above the loop: overseeing workflows, handling exceptions, curating data and shaping how humans and agents work together.

That brings new disciplines. The authors advise treating agents like new employees: define the job, onboard them into your systems and evaluate their work continuously, with visibility into every step so you can tell why quality dropped last week. And trust becomes the bottleneck. If people do not trust the agent they stop using it, and adoption dies right there.

It also matters how you frame the change. Under cost pressure it is tempting to present agents as a way to do the same work with fewer people. The stronger framing is capability: doing work you could not do before, at a speed and quality you could not reach, with people on the parts that need judgment. Organizations that choose that framing attract better talent and build capability that lasts.

So treat it as a change program, not a tech rollout. Say clearly what agents will and will not do. Redefine roles instead of removing them. Invest in upskilling so people can work next to agents. Build trust by being open about how the technology works and where its limits are.

Why the domain is the unit of change

You do not get far by repainting the living room. The Rewired authors make the point with a kitchen remodel: take on something substantial and transform it end to end. For a company that something is a domain, an end-to-end process such as customer service, supply chain, finance or R&D. The unit of transformation is the domain, not the individual use case.

Seen against everything above, the case gets stronger. The roles that change, the metrics that shift, the autonomy that is safe and the risks that matter all differ per domain. Only the people inside the domain can judge them. Three practical reasons come on top:

  1. The problem gets solved end to end. Pricing is hard to improve without seeing promotions and trade spend. Fix one step and the dependency next to it becomes the new bottleneck.
  2. Assets are reused. Data, platforms and talent built for one use case in a domain serve the next. A typical domain needs 5-15 related use cases, and they share more than they differ.
  3. Change management happens once. Train the same people once, for the whole domain, instead of every year for the next point solution.

The pattern shows in the results. Most of the companies in the book earn the bulk of their benefits from a few deeply transformed domains: production yield at Freeport-McMoRan, supply chain at Toyota Motor North America, passenger experience at LATAM Airlines. A typical company has 10-20 domains. You do not need to move all of them at once. You need to move a few of them deeply, and learn.

What it asks from leaders

If the domain is the unit of change, the leader of that domain is the person who makes or breaks it. Rewired calls the domain owner possibly the single most important role in a successful transformation, and says the business leader, not IT, should lead the reimagination of the domain. Nobody else has the end-to-end view of how the work gets done, what customers need and what could be much better.

That is a demanding job description. These leaders:

  • - craft a vision for the domain with the customer at the center, and reimagine the work instead of automating what exists;
  • - own the roadmap and the KPIs, and do not hand them to IT;
  • - know enough technology to oversee delivery, set priorities and challenge their teams;
  • - decide how much autonomy each workflow gets, and what a bad run is allowed to cost;
  • - own the change, including adoption, and answer for the value that comes out of it.

 

The book's example is Adam Boyd, then head of home equity lending at Citizens Bank. On top of his day job he spends six to ten hours a week learning about technology, and he learned agile delivery to lead four development teams himself. Two years later the bank had a customer experience that outgrew the industry.

The question the authors say every CEO and board should ask is simple: how many tech-capable senior leaders do we have? It is worth answering with an actual number. And it is not a gap you close with a one-off bootcamp. It takes intent, discipline and long-term focus, or the muscle fades again.

A journey that lasts starts with the leader

Put the pieces together and the conclusion is hard to avoid. Becoming agentic is not a project with an end date. It is a development journey, one domain at a time, with each step building on the last. The domain only moves as fast as the person leading it, and that person sets the dial for what the agents are trusted to do.

That is why we start with the leaders. Before anyone designs an agent, the leaders of a domain need the technical muscle and AI fluency to see AI embedded in their domain as a core competence, not as something that belongs to IT or to a pilot team. Leaders who have it can ask the right questions, challenge the answers and decide what to reimagine. They are in the driver's seat for AI in their departments, processes and domains. Leaders who do not have it end up as passengers, however good the technology.

Long-lasting development is our core business. At Avant Edge we have organized and hosted immersive development programmes for years. We know what it takes to build skills that stay, and to turn a one-off training into a journey a domain keeps walking.

If you want to build that journey for your leaders and domains, get in touch with us. Let's work out where your first domain should start.

 

Sources