I once watched an agent request move through a system exactly as designed. The ticket existed. The right service received it. The caller got an asynchronous acknowledgement.
It looked like success.
But the useful question was still unanswered: who was responsible for the meaning of the result? A Practical Architecture for Reliable Multi-Agent Systems starts with that gap between a moving request and an owned outcome.
That gap is easy to miss in multi-agent systems. Routing is visible and easy to test. Ownership is a design decision. If we confuse the two, a message path can quietly become a decision path.
This article focuses on keeping transport, semantic ownership, and authority separate. For the concrete endpoint and routing design behind those terms, see Building One Agent from Coordinated Roles in Codex.
A routed request proves less than it seems
Transport is the mechanical movement and recording of work. It can accept a request, persist a ticket, resume an endpoint, record a response, and create a callback.
Those jobs matter. None of them require the transport layer to understand the domain.
Suppose a request says, “Review this release candidate and publish it if it is safe.” A request runtime can deliver those words to a service. It may also prove which endpoint received them and when.
It cannot decide what “safe” means. It cannot judge whether the evidence is enough. It also cannot assume that the receiving service may publish anything.
The request moved. The meaning and permission did not move with it.
This is the distinction I use:
| Concern | Question it answers | What it must not imply |
|---|---|---|
| Transport | Did the request or response move and get recorded? | That the receiver owns the decision. |
| Semantic ownership | Who interprets the request, integrates evidence, and stands behind the answer? | That the owner may take every action mentioned in the prompt. |
| Authority boundary | What may this role decide or change? | That reachability creates permission. |
| Delivery | Did the approved result reach the intended requester or system? | That a stored response was actually seen or consumed. |
The terms are related, but they are not interchangeable. A reliable design gives each one an explicit home.
The semantic owner must be named before work spreads
A semantic owner is the role accountable for the meaning of the result. That owner interprets the request, chooses the work, weighs conflicting evidence, and authors the final answer.
It does not need to do every task itself.
The owner may ask a private specialist to review policy. It may launch a temporary worker to inspect files. It may consult another public owner about a separate dependency. Those responses are inputs, not automatic conclusions.
This matters because agents can produce plausible but incompatible answers. One worker may optimize for speed. Another may focus on safety. A third may find a missing test. Without one owner, the system has several outputs but no accountable result.
In the system I built, the public entry point mapped each admitted request to one owner. The entry point stayed intentionally mechanical. It did not load the domain history, choose specialists, or decide whether the requested product work was already complete.
That boundary kept the front desk from becoming a universal expert.
It also made duplicate handling more honest. Infrastructure could detect the same endpoint and request key. Only the owner could decide whether a similar request meant “reuse the prior answer,” “continue unfinished work,” or “run again with new evidence.”
Mechanical sameness is not always semantic sameness.
The same boundary applies to learning. A tooling or operations role may diagnose a failed path, but the semantic owner decides whether that diagnosis changes the next run, a role guide, a test, or the system design.
An asynchronous request needs more than an acknowledgement
The separation becomes clearer when work runs in the background.
Consider the release request again. The Runtime records it and the public entry point admits it for the release owner. The caller may receive an accepted_async acknowledgement and stop waiting. The owner interprets “safe,” uses focused help, and returns one integrated recommendation through an explicit callback. The public entry point then delivers it to the requester. A separately authorized actor may publish only after that decision.
Those are different claims. accepted_async means work was admitted. A specialist response means evidence returned. An owner-approved callback means the internal return worked. A delivery receipt means the requester received the result. An owner recommendation still does not grant publication authority.
In our case, explicit callbacks were necessary because a response did not automatically return to the component responsible for the next decision. Visible requester delivery was another obligation after that. When native delivery was unavailable, a governed relay could carry the owner’s exact message without rewriting its judgment. Done Is Not Delivered owns that final handoff in detail.
Authority belongs to a separate contract
A prompt can ask for almost anything. That does not mean the receiving role may do it. The owner may have authority to assess evidence and recommend a release decision while lacking authority to merge code, change production, or make an external commitment.
That is not a transport error. It is a separate authority contract working. The receiver can accept, narrow, request input, escalate, or reject the request. Authority Should Not Travel with the Prompt covers the practical design of those contracts, approval gates, and residual obligations.
Common shortcuts create unowned decisions
Most failures I have seen come from convenient shortcuts rather than dramatic technical errors.
The router starts answering domain questions
The public entry point already sees every request, so adding “small” decisions feels efficient. Over time, it gathers exceptions and becomes a hidden central owner.
Keep its admission rules narrow. Route exact known mappings. Send ambiguity to an accountable owner or ask for clarification.
The first worker response becomes the final answer
A worker finishes, so the system forwards its text directly. No accountable owner checks conflicts, missing evidence, or scope.
Require the semantic owner to consume worker returns and issue the final result. For a tiny task, the owner can answer directly.
Prompt wording becomes permission
A caller includes “publish,” “delete,” or “notify the customer,” and the receiver treats that wording as authorization.
Check authority at the receiving boundary. If permission is missing, return an assessment or request approval instead of acting.
An acknowledgement becomes completion
The system records accepted_async, closes the visible interaction, and never checks for an owner result or delivery receipt.
Track admission, owner completion, callback acceptance, and requester delivery as separate states.
Lifecycle tracking becomes domain management
A tracker notices that work is overdue and decides what the result should be. It now owns meaning without the context or mandate to do so.
Let lifecycle tracking identify open obligations and recovery needs. Keep domain judgment with the semantic owner.
The separation has real costs
This architecture adds tickets, role definitions, callbacks, delivery state, and recovery work. It also creates more interfaces that can drift.
I would not use it for every multi-step prompt.
If one agent owns a short request from start to finish, a direct call may be enough. A fixed workflow with one clear owner may only need a graph. The heavier design earns its keep when work crosses separate contexts, authority boundaries, or return paths.
Even then, separation does not guarantee a correct answer. A named owner can still misunderstand the request. Authority rules can be stale. A delivery receipt can prove a handoff without proving that the result was useful.
The design gives us clearer failure locations. It does not remove failure.
Design the return path with the request path
Before I add another route to a multi-agent system, I now ask four questions:
- Which component transports and records the request?
- Which role owns its meaning and final answer?
- What may that role decide or change?
- How will the owner-approved result reach the intended requester?
If any answer is “whichever agent receives the prompt,” the boundary is probably too loose.
A reliable request path is not merely an arrow between two boxes. It is a chain of distinct obligations. Transport moves the work. The semantic owner makes sense of it. Authority limits what may happen. Delivery closes the loop with the requester.
Keeping those jobs separate adds some machinery. In my experience, it also makes the system much easier to trust, test, and repair.