AI agent silos: why agents in every function don't join up the work

Buying an agent for every function hasn't joined the functions up. A deal still moves from sales to finance to operations because people carry it. Where no system holds the process, nobody can say how long that takes, how many people touch it, or whether AI spend changed either number. We think that's the real gap in enterprise AI now. It is a measurement and operating-model gap before it is a technology gap.

This post sets out how we see the problem, why we put measurement ahead of automation in ETA (Enterprise Technology Accelerator), and what we have and haven't measured ourselves.

Where do most enterprises sit on the automation ladder?

Our working view, from the conversations we have had and not from a survey, is that most organisations of this size sit on layer two of a four-layer ladder and are buying layer three. Layer three is where we expect the disappointment to start.

1. Systems of record. Every function runs its own: finance, CRM, HR, delivery tooling.
2. Point-to-point automation. Fields move between tools through scripts and integration platforms. Meaning doesn't move with them.
3. An assistant or agent per function. Each silo gets an agent. None share context, so people still connect them.
4. A governed operating layer. One shared meaning, one set of rules, one record of the work.

Why does an agent per function leave the silos in place?

Because the expensive part of a cross-functional workflow is the hand-off, and an agent inside one function can't see across it.

Take a deal that closes. Finance has to set the client up and raise the purchase order, an invoice has to go out, and operations has to mobilise the work. Each step lives in a different system with a different owner.

Each hand-off is a message to a person. An agent can draft the invoice faster. It can't tell you why the purchase order sat for a week, because the week was spent in the gap between two systems.

We see three deficits here, and none of them is a model problem:

• No shared meaning. Each function's agent has its own idea of what a client, a case or a commitment is.
• No governed action. Most deployments have credentials and optimism, and little else controlling what an agent may change.
• No evidence. Nobody can say what the agents changed, because nobody measured the before.

Better models won't close any of the three. They are operating-model problems that look like technology problems. For the longer argument, including why we call the connected version a nervous system, read our white paper on Artificial Neural Intelligence (ANI).

Which two questions can't most companies answer?

The two questions are simple to ask. What does this outcome cost in human hours and elapsed days? And did our AI spend change that number?

The failure mode is less about capability than about evidence. Your systems hold artefacts: tickets, invoices, contracts. Nothing holds the process, and elapsed time lives in the gaps between systems. Everyone owns the machinery. The number often has no owner.

Why measure before you automate?

Without a baseline, neither faster nor better can be shown. That sounds obvious, and it is routinely skipped, because the pressure is to show automation, not to show a stopwatch.

So the order is the product. In ETA the first phase measures and writes nothing back. The second lets a rules engine write with humans approving. Only the third lets agents act, with the economics instrumented. Each phase is sellable and stoppable, and each is gated on the one before.

There is a commercial reason too. If you automate first, the saving you report is whatever you can argue for. If you measure first, the saving is the movement in a number the client agreed before we started.

How do you measure a workflow that no system owns?

You can reconstruct it backwards from the logs of the systems it passed through, which is what process mining does, or you can record it forwards as the work runs. We chose forwards.

Reconstruction depends on logs that were built for other purposes. Event logs are often short-lived, lack a case identifier that survives a hand-off, or aren't exposed at all, and inbox work leaves almost nothing behind. If the harness runs the work, the record is a by-product of doing it. Every step writes one line to a work ledger.

The ledger is a design decision more than a feature, and it carries a cost. It only records work that runs through the harness. Work that stays outside stays invisible, which is one reason the first phase is a measurement exercise with a limited number of workflows.

What have we measured ourselves?

One workflow, in one function: software delivery for a North American education-technology client. We took a snapshot of the client's work-tracking history on 24 September 2026 (1,244 stories and 1,011 requirements, of which 587 stories could be timed). Across those 587 timed stories, the median took about 18.5 days from start to done, and the median requirement about 30 days. About 47% of story time sat in waiting statuses, and 36% of the timed stories re-entered a status at least once.

Almost half the elapsed time was waiting, which is a finding no amount of coding speed would have changed. We unpack it in where delivery time goes.

We also tried to predict story duration with an estimator and set the pass mark before testing. None of the estimation methods beat the plain median by the margin we had committed to, so we didn't ship it. That story is in set the pass mark before the test. We mention it here because a measurement-first company ought to be willing to publish its own negative results.

When does this not apply?

• If your workflows sit inside one system of record, the vendor's own analytics may answer the question and you don't need a layer above it.
• If a workflow has no ground-truth signal, such as a measurable outcome or a reviewer who can say it was wrong, instrumenting it tells you how long it takes but not whether it improved.
• If nobody with authority owns the workflow and the value, a measurement will be admired and then ignored.

What we don't claim yet

ETA is a design and a method. There is no ETA pilot yet, so we have no ETA results to show, and we won't quote savings for it. Our own baseline above comes from software delivery, not from the workflows ETA is aimed at. The design is additive: it measures and then automates alongside the systems you already pay for, and doesn't replace them.

The ETA white paper covers the ledger, the design rules and the phases in full. If you want to start measuring your own workflows, talk to us through the ETA service page.