By Pavan Kumar T V · 22 August 2026

Series: Part 1 was definitions, Part 2 was money, Part 3 was careers. This is Part 4, the one about building the thing.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027.

Read the reasons carefully, because they're the whole point of this post. Escalating costs. Unclear business value. Inadequate risk controls.

Not one of those is a model limitation. Not one gets fixed by a better benchmark score.

Every hard problem you hit once you have more than one agent is a problem an organisation already hit. Not analogous to it. The same problem, different medium. Which is good news, because organisations have been failing at these for a few thousand years and the survivors left notes.

The question that started this series was about architecture. Four posts in, I still don't have a box diagram for anyone.

Delegation Is the Piece Everyone Skips

I don't care whether one agent reaches another over HTTP, a queue, a shared bus, or a function call. That's plumbing and it's solved.

What isn't solved is the property underneath it.

A backend engineer asked about a UI bug doesn't attempt the UI bug. They say: "that's front-end, and payments is this sprint's priority anyway, so don't start it today."

Look at how much just happened:

1. They recognised the boundary of their own job.
2. They knew who owned the other side.
3. They applied a priority ordering that was nowhere in the question.

Three separate pieces of state, none of which live in the request, all of which we routinely fail to give agents.

So a PM agent, a front-end agent, a backend agent, a devops agent. The interesting part isn't that they can call each other. Anything can call anything. It's that each one holds a boundary, an ownership map, and a shared priority order that no single message contains.

An agent that can only answer is a library. An agent that can say this isn't mine, here's who owns it, and here's why it isn't urgent is a colleague.

Once you have that, your input changes shape. You stop specifying folder layouts. You say "Next.js front end, separate backend, use our auth" and it knows what you mean, because it's built this with you eleven times and remembers what you threw out the last ten.

The specification got shorter because the shared context got longer. Same trade every good team makes. It's why a team that's worked together three years communicates in fragments a new hire couldn't parse.

"Saved" Is Not a Result

Everyone doing agentic work has hit this failure mode. It's the tell that you're dealing with something transactional.

You ask for something. It reports success. You have no way to check the report except by doing the work yourself.

People solved this a long time ago with show-back. You ask a colleague to draft an email. They show you the draft, not the words "email drafted." You fix one thing. Next time it's already applied and you never say it twice.

Three mechanisms hide inside that ordinary exchange:

read-back    here is what I understood, in the shape of the actual output
correction   a channel for you to fix it, cheaply, in the moment
durability   a write path that makes the correction survive the session

Most implementations have the first, sort of. Almost none have the third. I wrote a whole spec about it, because the protocols carefully define the moment an agent stops and asks a human, and say nothing about the moment after. Which is exactly when the only person who knew the answer walks away.

If you build nothing else from this series, build this. An agent that reports the success of its own write, instead of showing you what it now makes of your input, has told you nothing.

Teaching, in Both Directions

The read-back has a failure mode of its own, and the complaint I hear most is some version of please, not another markdown file, I'm already tired.

That's the right complaint. A dump is not a briefing.

If I've stopped doing my own research because I have an agent, then condensing is the job. Producing thirty pages I now have to read to find out whether the thirty pages are correct isn't delegation. It's a very fast intern who assigns me homework.

The hard part of an agent's output isn't generation. It's selection. What did I not need to know?

Same rule applies sideways. An agent should be able to brief another agent. If the only path between two of them is a human copying context from one window into another, you don't have a team. You have two chatbots and a courier.

The Unfair Advantage Nobody Is Building For

This is the most interesting idea in the series and I've buried it in post four, which is my fault.

Think about why sales knowledge never spreads inside a company. Someone finds a clever way past a gatekeeper. They don't share it. A lead is a lead, the ranking is public, and teaching a colleague materially lowers your own standing.

So the single best technique in the building stays in one person's head until they leave and take it with them.

Every organisation on earth leaks value through that hole. A meaningful fraction of management theory is a patch on it. Knowledge bases nobody updates. Brown-bag sessions nobody attends. Documentation written under duress by the person least interested in writing it.

Agents don't have that incentive.

An agent has no promotion to protect, no bonus pool to defend, no reason to withhold what worked. Teach one, and every peer can have it before the day ends.

So an agent org doesn't beat a human org because the agents are smarter. It beats it because knowledge moves at the speed of a write instead of the speed of a career.

This isn't just a nice framing anymore. A paper out of June 2026, Multi-Agent Transactive Memory, tested exactly this: share problem-solving trajectories across a population of agents and measure what happens. Task performance improved and interaction steps dropped, and the phrase that matters is "without coordination or joint training." No retraining, no central orchestrator. Just distribution.

The underlying concept is Daniel Wegner's transactive memory from the 1980s, which is about teams knowing who knows what. It took forty years to build a substrate where distributing that costs nothing.

We're all still benchmarking single agents on single tasks. That's like evaluating a company by interviewing its best employee. The compounding advantage was never in any individual's capability.

The caveat, and it's serious

Instant distribution of a good lesson is instant distribution of a bad one. A wrong rule taught at 9am is wrong across the org by 9:01, with no friction, no scepticism, and nobody quietly ignoring it the way humans quietly ignore bad process.

The research has already named the failure modes. Governed Shared Memory for Multi-Agent LLM Systems, also June 2026, lists four:

unauthorized leakage       memory crosses a boundary it shouldn't
stale propagation          an old fact keeps spreading after it stopped being true
contradiction persistence  two incompatible lessons coexist, both get applied
provenance collapse        nobody can say who taught it that, or when

Provenance collapse is the one that will hurt you. It's the same problem as Part 3's demotion problem: you can't remove a bad lesson if you can't tell which lesson it was.

Their four primitives map onto what you'd build anyway. Scoped retrieval, temporal supersession, provenance tracking, policy-governed propagation. Which brings us to versions.

Versions, or the Thing Nobody Debugs

If an agent learns, it changes. If it changes, "what did it know when it decided that" becomes a real question, asked six weeks later by someone who wasn't in the room.

So:

1. The change needs a version.
2. The version has to be pinned for the duration of a task.
3. The decision has to record which version made it.

Without pinning, "the agent learns" and "the agent changes unpredictably underneath running work" are the same sentence, and you can't debug either. A task that started under version 11 should finish under version 11 even if 12 goes live mid-flight. Otherwise you'll spend a day reproducing a behaviour that no longer exists.

Least glamorous requirement in agent design. First one you'll wish you'd built.

Then People Have to Actually Use It

None of the above is why these projects fail. This is.

Every process has slack in it. Not the ten or fifteen percent you'd admit to in a review. Closer to forty. Some of it is genuine waste. A lot of it is the room a human needs in order to keep doing the job at all.

A machine doesn't need wiggle room. Give it ten things, it does ten, it comes back for eleven. Push a person to that and they leave, or they quietly break your tool and blame the network.

I used to think that last one was a figure of speech. It isn't. A survey of 2,400 knowledge workers across the US, UK and Europe this April found 29% admitted to actively sabotaging their company's AI strategy. Among Gen Z it was 44%. Sabotage included refusing mandated tools and deliberately producing low-quality work to make the AI look ineffective.

Nearly a third of your users. Working against you. On purpose.

Because when you ship the agent that finally gives management complete visibility of how the work gets done, the people doing the work don't experience visibility as a feature. They experience it as scrutiny. The manager gets a dashboard, the company gets numbers, and the person doing the job gets watched more closely for the same money.

The monitoring data says the same thing. Companies with heavy workplace surveillance see roughly 42% of employees planning to leave within a year, against 23% at unmonitored companies. Where monitoring is disclosed up front, reported stress rises 18%. Where it isn't, 62%.

If the person whose slack you're removing is also the person who has to adopt it, you don't have a product problem. You have a nobody-wants-this problem, and no amount of UI fixes it.

Which brings the person-shaped framing around to something ruthlessly practical.

The most-used enterprise software on earth is a spreadsheet and an email client. Not the most innovative tools available. The ones everyone was already trained on. Day-one productivity beats capability every time, because there's no adoption curve when there's nothing to learn.

And everyone already knows how to work with a colleague. How to brief one. How to correct one. When to escalate, how to hand something over, how to tell whether the work came back right.

That's a lifetime of training you don't have to pay for. Building an agent that behaves like a person isn't a poetic framing. It's the shortest path to day-one productivity, and per Part 2, the only pricing story that anchors to a number worth having.

The Bottom Line

There's no agent architecture worth drawing. There's an org design that happens to be implemented in code.

Write the job description. Give it a memory it doesn't lose, a surface a human can teach, a boundary it knows not to cross, and a version number on everything it learns. Let it grow into something more specialised than it started as, make that growth legible, and let it teach every peer what it just learned. That last part is the one thing your competitors' humans structurally cannot do.

Then price it like the job it does.

Gartner's 40% will get cancelled for cost, value and control. All three are org problems wearing engineering clothes. The teams that survive the cull won't be the ones with the best model.

We spent twenty years learning to build software that forgets. The next twenty are about software that doesn't, and almost none of the instincts transfer.

The org chart was the architecture diagram the whole time.