A worked example of one orchestrator, two specialist agents and a shared catalog

The setup: a legal desk and its agents

As dev.to reported, the example is a fictional company, Northwind Gear, whose legal desk reviews supplier contracts. There are two jobs: a clause-by-clause read against the house wording, and a compliance screen that escalates anything that breaks policy. A contract-review orchestrator, the manager agent, takes the brief and passes each job to a specialist.

The two specialists are separate on purpose. The two teams do not want to share a prompt, a model version or a release schedule. Finance adds a further wish: one place where every agent and tool server the company runs is registered and findable, including from a shared services account, without asking engineering for a spreadsheet.

The author ran everything on Amazon's AgentCore Runtime in a single account in us-east-1. Four agents are hosted, one per communication protocol, which is a shared set of rules for how software talks to other software.

Four protocols, four jobs

Each protocol in the build has one role:

• AG-UI is how the orchestrator talks to the person or app calling it. It streams its answer as server-sent events (SSE), a steady one-way flow from server to caller, starting with a RunStarted event and ending with RunFinished.
• A2A (agent-to-agent) carries traffic between the orchestrator and the two specialists.
• MCP (Model Context Protocol, a standard for connecting agents to tools) serves a billing tool server with three tools and no model behind it.

The orchestrator in this demo has no AI model either. It maps a request to a specialist with fixed rules, so that what gets measured is the wiring rather than the model's judgment. It finds the specialists at runtime by listing the deployed agents and reading each one's agent card, a short self-description. One permission line allows both lookups.

Handling work that takes too long

The A2A calls come in three shapes. A quick review uses a blocking send: the caller waits, and a completed task comes back. The legal and compliance specialists each finished their part of the review this way.

The long compliance scan is a five-pass job described as taking 75 seconds. It is sent as non-blocking, so the server replies at once that the task is submitted. The orchestrator then asks for the task's status until it flips to done. In the measured run the scan was accepted at 0.0 seconds and completed at 115.0 seconds with a full report.

The author then sent the same work as a blocking request. It failed at 184.9 seconds in the client's own read timeout, after three retry windows in the software kit. The author's point is that the failure sat with the waiting client, not with the server doing the work.

The third shape is barge-in, meaning interrupting a job midstream. The orchestrator opens a stream of live status updates and sends one cancel request as soon as the first update arrives. The task stops, and the stream closed eleven seconds in with the state marked canceled.

Isolation, compute and the catalog

Each session id gets its own microVM, a small isolated virtual machine, and state sits in an ordinary in-memory dictionary. To test the boundary, the author ran ten sessions, each storing one codeword and recalling it. That took twenty invocations in 88.3 seconds, with zero cross-talk. The source notes that session ids must be at least 33 characters.

The billing tool server is the one agent pinned to customer-managed compute. A capacity provider, which declares a pool of machines, specifies ARM64 instances of types m7g.large and c7g.large with a 300-second idle timeout. The runtime references it at creation, so the instance choice lives in the deployment contract rather than a console setting.

The catalog is the Agent Registry. It was created with the AWS command line rather than the deployment stack, and it holds two records: the billing tool server and the legal specialist. A new record starts as a draft, gets submitted for approval, and only then is approved. Trying to jump straight from draft to approved was rejected. Search is semantic, matching on meaning, so a query for payment processing returned the record named billing as the first hit even though the two share no word. The registry can also be shared across accounts through AWS Resource Access Manager (RAM).

What to take from it, and the limits

The measurements come from one account in one region, run by the author. They show the pattern working, not how it behaves at scale or under load. The orchestrator's rule-based router also sidesteps the hardest part of real orchestration, which is a model deciding who should do what and checking the answers.

Still, the example makes the design choices concrete. Long jobs get accept-then-poll instead of a held-open connection. Specialists stay separate so teams can release on their own schedules. The catalog has an approval step, so what people find is what someone signed off on.