Use case

Agents across systems that were never meant to talk to each other

Most enterprise work crosses three or four systems before it is finished, and the crossing is where the time goes. Agents are good at that crossing, which is also where they are most dangerous.

Yaju Team · 12 May 2026

Inside a large organisation, very little work lives in one place. A request arrives in one system, the record of truth sits in a second, the approval happens in a third, and somebody copies information between them by hand.

That copying is a genuinely good target for an agent. It is also the point where an agent has the widest reach and the most capacity to do damage quietly.

Why integration work suits agents

The task is well-defined: take this from here, check it against that, put the result there. The difficulty is not judgement, it is that the systems have different identifiers, different formats and different ideas of what a complete record looks like.

An agent that reconciles those without a person retyping anything removes a category of work that is pure overhead and reliably error-prone when done manually.

Why it needs the tightest boundary

An integration agent by definition touches multiple systems, several of which are systems of record. The blast radius of a mistake is larger than for almost any other kind of agent.

Two rules make this manageable.

Read broadly, write narrowly. An agent may read from everything it needs and write only to an enumerated set of places, enforced where the write occurs rather than requested in a prompt.

Every write carries an identity. Credentials resolving at runtime from the org vault, scoped per agent, so the audit trail answers "which agent changed this" rather than showing a shared service account.

Staleness is the specific failure

The record the agent read at the start of the run may have moved by the time it writes. This produces work that is internally consistent and externally wrong, and it has to be unpicked by a person who did not do it.

Situation awareness exists for this: keeping track of what has happened within a run and what changed underneath it, so a step is flagged rather than applied to a record that has moved.

What to measure

Reconciliation accuracy against a known-good sample, not a general quality score.

How often a write had to be reversed, which is the number that matters and the one nobody instruments.

Cost per completed reconciliation rather than per run, because a run that fails after three writes has cost you three writes and produced nothing.

Starting shape

One pair of systems. Read-only for the first weeks, producing a proposed change a person applies. Then a narrow enumerated write, behind approval for anything with financial or contractual consequence.

Named owner. Evaluation criteria from real records. A budget that blocks.

Next

The Agent Orchestration System pages cover policy enforcement, the credential vault and the audit trail. The MCP Gateway pages cover connecting systems.