Agentic Integration Starts Where the Pipeline Breaks

I have spent most of my career in enterprise integration. Every project I have seen begins the same way: a map. Which systems exist, which fields mean what, which pipeline carries what to whom. Months of workshops before a single useful thing runs.

The map is always wrong. Not because the people are careless — because nobody can know what the work will need before the work runs. Someone always says “this one depends on the situation,” and the real integration begins there, long after the diagram was signed off.

I have come to think the map is not just wrong. It is the wrong first move.

Start with a task, not a systems map

Give a mesh of agents one piece of real work — why did checkout latency spike last Tuesday? — and something useful happens immediately. The work runs until it meets a boundary it cannot cross:

connection refused · field missing · permission denied · system unreachable

Classical integration treats those as exceptions. You log them, retry them, dead-letter them, page someone. The whole discipline is organised around making them go away quietly.

Invert it. That failure is the single most information-dense event your integration produces. It is the system showing you which boundary the work could not cross — and therefore which system may need to become reachable, which enrichment was missing, or which permission was unavailable. The failure names the capability the work actually needed.

I have written before about why failure is a first-class cognition event rather than an exception to suppress. Enterprise integration is where that principle pays the largest dividend, because integration is the discipline that produces the most failures and learns the least from them.

Connectors become demand-driven

Follow the inversion and the economics change. You no longer scope a connector catalog up front. Connectors are discovered by blocked work and ranked by how often work blocks there. The integration backlog stops being a scoping exercise and becomes a by-product of doing business.

Which means you build connectors in response to observed need rather than forecast demand. Anyone who has bought an integration platform with three hundred connectors and used six knows exactly what that is worth.

The cycle is the same one the mesh uses for everything else: Perform → Uncover → Deploy → Evolve. Run real work. Let it uncover the boundary. Make that boundary a node. Watch the next mission find the next one.

What a system looks like once it joins

A system becomes a peer, not a data source. It needs four things: an identity, a way to project what it observes, a membrane deciding what it accepts from others, and a locator pointing back to itself.

One rule does the heavy lifting, and it is what separates this from ETL: a projection carries judgment and a locator — never the payload. The mesh accumulates what matters about a thing and where that thing lives. It never accumulates the thing.

That single rule resolves four problems that normally take a platform to solve:

• Scale. A CRM with ten million rows projects observations, not rows.
• Permissions. The locator can resolve under the caller’s own credentials, so access can stay governed at the source instead of being copied into the integration layer — the copying that turns warehouse projects into compliance projects.
• Freshness. A pointer can resolve to current source state; a copy can only reflect the state captured when it was made.
• Sovereignty. The source keeps its data by construction, not by promise.

The four questions every integrator asks next

“What about enrichment from other systems?” Classically the pipeline performs the join, so it must know which systems to call and in what order. Here the second system admits the first system’s projection and re-projects it enriched, carrying the lineage of who enriched it with what. No central component orchestrates the join. Each system contributes what only it knows.

“What if the enrichment is not available in real time?” This is the question I expected to be hardest, and it turns out to dissolve. A pipeline record claims to be a complete row, so a missing required field breaks that contract and you must choose to block, buffer, or patch. An observation never claimed completeness. It is a projection of state at a time. Late enrichment arrives as its own observation with lineage back to the original, and the receiver decides whether it has enough to act.

“What about downstreams that need different formats?” There is no canonical model to agree, because each consumer admits through its own membrane and re-expresses in its own terms. The committee that never converges never convenes. A legacy consumer demanding a fixed wire format still needs an adapter — this removes the negotiation, not the last mile.

“What if a downstream reports missing data, or a reconciliation check fails?” This is the one I get asked last and care about most, because it is where classical integration hurts worst. The consumer finds the problem late — at month-end close, in a reconciliation report — far from its cause in both time and system. Someone files a ticket. Someone else spends two days tracing backwards through transformation logs in three systems, and the answer is usually a record that was silently dropped six weeks ago.

The trace is built into the structure here, because every projection carries provenance rather than leaving it only in logs. Every projection carries lineage to what it came from, so a wrong reconciled figure walks back through the chain to the observations that fed it. Nobody reconstructs the path; the path is how the figure was assembled.

But the more important part is what the complaint is. The downstream’s report is not a ticket in another system. It is an observation in the same mesh — and specifically it is a grounded outcome: reality, in the form of your reconciliation check, refuted an upstream claim. So it does what grounded outcomes do here. It moves earned authority. In this design, a source whose projections keep failing downstream checks would lose standing without anyone editing a config, and each consumer’s membrane could weigh that standing accordingly.

Data quality stops being only a dashboard someone is supposed to watch, and becomes a signal that can change whose claims consumers trust.

Missing data specifically closes the loop of this whole argument. Because an observation never claimed completeness, “missing” is not a broken record — it is a boundary the mesh has not crossed yet. The downstream’s complaint names it. Which makes it the same event as connection refused at the far end of the pipeline, doing the same job: naming the connector you actually need. Failure arrives from both directions, and both directions are demand.

Two honest limits. The mesh does not invent your reconciliation rule — someone still has to say what “reconciled correctly” means, and that judgment is yours. And nothing here un-consumes a figure that already went out: the correction lands with its lineage, and downstreams re-derive from it.

What this is not

Being precise about the boundary is worth more than claiming everything, so: this is observational, not transactional. There is no two-phase commit across a mesh. Money movement, inventory decrement and order state stay with your systems of record. What gets integrated is the cognition about your business, not its transactions.

There is no total ordering either — lineage gives causal order, not a global sequence. If your requirement is exactly-once processing or strict ordering, that belongs in your transactional messaging layer, and you should keep using one.

Why this matters now

Enterprises are being told to adopt agents, and discovering that the real cost is not the model. It is the preparation: re-sorting processes, organising scattered documents, confirming interfaces, dividing permissions, extracting the judgment that lives only in experienced people’s heads. A customer put it to me plainly — the product is capable enough, but the start-up cost of getting our own house in order is too high.

The preparation is not avoidable. But it does not have to come first, and it does not have to be done in one enormous push before anything works. Run one real task. Let it fail against a boundary. Make that boundary reachable. Run the next one.

Your organization’s integration map gets drawn by the work that needed it — which is which makes it more accurate than one drawn before the work began.