Part 12: What carried over from series 1 (and what did not)

Part 12 · One Agent, Five Platforms

Series 1 designed one agent on one platform: a change-approval agent for SAP transports, built on MuleSoft for a fictional company. Series 2 designs one invoice agent for five platforms. Before the next four builds, it's worth checking which series 1 decisions carried over to a different use case, and which didn't.

The short answer: three carried over unchanged. One didn't carry over at all. Several "next time we'd…" lessons became the foundation of this series.

Carried over: the approval gate in the process API

Series 1's human-in-the-loop post made one rule non-negotiable: approvals are checked by a process API before anything touches the system of record, never by an instruction in a prompt.

That rule moved across untouched. In this series it's Part 6: post_invoice_adjustment and notify_supplier both need a valid approval_id, and the process API returns APPROVAL_MISSING without one. Different domain, different systems, same rule. It's also the one rule every platform build has to meet in the same way, because it doesn't depend on the platform at all.

Carried over: tools over process APIs, with contracts

Series 1's lessons post put it plainly: expose process APIs as tools, never system APIs. The business rules an integration team has already built become the agent's safety layer.

Series 2 kept that and made it stricter. The tool contract in Part 7 defines nine tools once, with schemas and descriptions written for the agent, before any platform is opened. Every build has to host or call that same contract unchanged. Series 1 arrived at it along the way; series 2 starts there.

Carried over: gateway allow-lists

In series 1, Omni Gateway policies decided which agent could see which tool. In series 2 the same idea became platform-neutral: every platform has some form of gateway, and every build has to show tool allow-lists, PII detection and token limits.

It also took on a new job. In Part 9, the allow-list is how an agent moves between rollout stages. Part 11 mapped that to MuleSoft's MCP Global Access policy from the documentation. Whether each of the other four platforms can do the same through configuration alone is one of the things the builds will show.

Did not carry over: the broker graph

Series 1's agent network design had four agents (intake, planner, change and approval) and a broker graph with rule-based branches, loop counters and the approval as an edge between two nodes. MuleSoft calls this guided determinism.

None of that transferred, for two reasons.

The process is different. An invoice exception isn't a 21-step change promotion. The invoice flow is shorter: rules first, then one agent investigates and proposes, then a person approves before any write. Four agents would be the wrong shape.

The graph is platform-specific. A broker graph in Agent Script is a MuleSoft construct. The other four platforms orchestrate agents in their own ways. So series 2 describes the flow as platform-neutral steps and lets each build map it onto whatever the platform offers.

What did survive from the graph is its rules, moved to places every platform has:

• "Two tries, then a person" became the retry limit in Part 8: one corrected retry per tool, then route.
• "Gates are edges, not instructions" became the process API check. An edge in a graph is a useful extra; the API check is the control.
• "Validate between steps" became the output schemas in the tool contract.

The lessons that became the foundation

Series 1's lessons post listed five things we'd do differently. Each one shaped a part of this series:

1. Write tool descriptions and named errors first → Parts 7 and 8, written before any build.
2. Build the golden set before the first agent → Part 10, finished before Build 1.
3. Set token budgets from the start → a token limit is part of every build's gateway setup.
4. Keep agents smaller → one exception agent with nine tools. Supplier messages move to a separate agent in Parts 28–29.
5. Plan support before go-live → observability, failure modes and kill switches have their own parts (37–39), not an afterthought.

The process-first lesson carried too. Series 1 sorted 21 steps into rules, agent or person; series 2's Part 2 sorted six exception types the same way.

What still needs confirming

Part 11 was documentation-only, so everything above is a design decision, not a hands-on result. Two things I'll check when the MuleSoft build runs:

• That named errors pass back through the MCP Connector with the shape from Part 8.
• That switching rollout stages really is a policy change with no redeploy.

If either fails, I'll update Part 11 and this part.

The lesson for builds 2 to 5

Carry decisions, not configuration. The approval gate, the tool contract, the named errors and the golden set are decisions. They should look the same on Boomi, SAP, Azure and AWS. Agent graphs, policy syntax and deployment pipelines are configuration. They'll look different on every platform, and that's where the comparison gets interesting.

Next: what each of the five platforms needs before you can build, then Boomi.

What do you reuse on every project?

This series describes a reference build on a fictional company. Series 1 was also a reference model on a fictional company. Product capabilities are based on vendor documentation as of October 2026; check current docs before you build.