I built message orchestration for a federal immigration system. It was the same problem.

Before any of this was called agentic anything, I spent a couple of years at Avanade building enterprise integration on BizTalk Server for Citizenship and Immigration Canada — moving applicant and case data through the stages of a federal business process, making sure the right data reached each downstream system.

I did not expect that work to be relevant again. It is the single most relevant thing I have done.

Strip the vocabulary off both and they are the same problem: get a message through a multi-step process across systems you do not control, validate it at every boundary, and know what happened when it does not arrive.

The mapping is almost embarrassingly direct

That last row is the one I find genuinely funny. BizTalk's central idea was that the durable message store is the system — orchestrations are stateless things that wake up, read the box, and write back to it. An agent loop is the same architecture with a much smaller box. The conversation array is the messagebox. Everything else is a stateless function over it.

Three things the older field settled that the newer one keeps relearning

1. Validate at the boundary, and make the rejection informative

BizTalk validated inbound XML against an XSD before any orchestration logic saw it. My actual job was writing business and technical validation rules that caught missing, malformed or invalid application data before it reached downstream processing — with explicit exception handling for messages that could not be routed.

The reason was not tidiness. It was that a bad message which gets halfway through a multi-step process is dramatically more expensive than one rejected at the door, because now you have partial state in three systems and no clean way to unwind it.

That is precisely the argument for a strict tool input schema. A model that sends sides: 0 should be told so before your handler runs, in a form it can correct — not deep inside a tool that has already written a row.

2. A suspended message is a first-class state

BizTalk had a suspended-message queue, and diagnosing it was a job: transactions failing across schemas, maps, pipelines, orchestration logic, XML payloads and database connectivity. Nobody pretended failures were exceptional. There was a place for them to sit, with enough context attached to work out what happened.

Agent systems mostly do not have this yet. A tool call fails, an error string goes back to the model, the model apologises to the user, and the incident leaves no trace anybody can query. When I built persistence and replay into my own agent host — every message, every pending call, every trace, replayable step by step — I was rebuilding the suspended-message queue without initially noticing that was what I was doing.

3. The orchestration is worth writing down separately

A BizTalk orchestration was an artefact. You could look at it, review it, version it, and point at the step where a message stopped.

An agent loop's "orchestration" is emergent — the model decides the next step each turn. That is the entire appeal, and it is also why the trace matters so much more, not less. If the process is not written down in advance, the record of what it actually did is the only artefact there is.

Where the analogy genuinely breaks

I want to be careful here, because "it's all just integration" is a comfortable thing for someone with my background to believe, and it is not quite true.

Non-determinism at the routing layer. A BizTalk orchestration always routes the same message the same way. An agent may pick a different tool on the same input, and it may be right to. Every reliability technique that assumes deterministic routing — replay-to-compare, exact-match regression tests — needs rethinking rather than porting. Mine ended up asserting on outcomes and costs, not on step sequences.

The schema is now a prompt. In BizTalk, an XSD described a message to a machine that would parse it. In MCP, a tool description also has to persuade — it is the evidence the model uses to decide whether the tool is relevant. A perfectly precise schema with a vague description is never called. There is no 2006 equivalent of that failure.

Latency and cost per hop. Passing a message through five BizTalk components cost microseconds. Five agent iterations cost seconds and real money, and the cost grows with the conversation. That changes which designs are sensible: batching, caching the stable prefix, and delegating to sub-agents to keep context small are all responses to an economics that classic integration did not have.

Why I think this is worth saying out loud

There is a lot of writing right now that treats agent reliability as an unprecedented problem. Some of it is. Most of it is distributed systems, message-oriented middleware, and transaction design — fields with decades of hard-won answers.

If you are building agent infrastructure and you have not read anything about enterprise integration patterns, you are going to derive a subset of them, slowly, from your own outages. Correlation identifiers, dead letter channels, idempotent receivers, compensating transactions — these have names, and the names come with the reasoning attached.

And if you have twenty years of that behind you and are wondering whether it counts: it counts. The interesting problems in agent systems are not the model calls. They are everything around the model calls, and that part is not new.