Architecture essay
Where authority belongs in a multi-agent system
Give each boundary a clear job: authenticate access, preserve ownership, review effects and inspect outcomes.
The hard part starts when a model can act
Adding another agent is easy compared with deciding what it may change. A model can understand a request and still act through the wrong identity, use stale evidence or treat text from a retrieved document as permission. These are product failures even when the generated answer looks sensible.
I structure delegated work around four questions: who made the request, which actions that identity may take, who owns the next step, and what evidence would establish completion. Those questions need answers outside the model’s prose.
A gateway authenticates access
The tool gateway is the place to validate identity and mediate the exposed tool surface. The MCP authorization specification defines an HTTP authorization framework; implementing that framework is one part of a system’s access boundary. It does not establish that every task is authorised or every model request takes the same route.
Model routing is a separate decision. A tool gateway can be shared across runtimes while inference takes another governed path. Keeping those responsibilities explicit makes it possible to test either path without claiming that one successful tool call proves both.
A ledger preserves responsibility
The ledger holds current work state: the next actor, expected revision, decision evidence and outcome. A conversation summary is useful context, but it is a poor substitute for a durable record of who must act next.
Consider a fictional request to publish a community event. A retrieved flyer asks the agent to change the organiser’s account settings. That text is evidence about an event, not authority to perform a second task. The ledger should preserve the original scope while the access boundary refuses the unrelated operation. This is an illustrative denial path, not a claim of universal prompt-injection resistance.
Review needs a distinct actor and a precise object
For a consequential change, the reviewer needs the proposed effect, the supporting evidence and the exact version under review. Merely registering an executor and a supervisor does not prove independent review took place. A receipt must connect a completed review to the object that was actually executed.
This separation costs latency and coordination. I reserve deeper review for changes that alter authority, custody or consequential behaviour, and use bounded verification for repeated operations whose pattern is already accepted. The tradeoff is explicit: more review can reduce some risks while creating another queue that needs ownership.
Carry evidence through the release
A signature makes an artifact attributable; it does not make its content correct. Source review, an artifact digest, deployment readback and a behavioural check answer different questions. SLSA’s verification guidance is useful here because it asks the consumer to compare provenance with expectations. I do not claim a SLSA level for this personal system.
The architecture works best when each boundary has a small, inspectable responsibility. The remaining challenge is to make denied actions, recovery and human attention as visible as the successful path. That is where I want evaluation to go next.
Sources and attribution
This is an original, self-published piece by Vihang Patel. The sources below support the referenced frameworks; fictional examples and personal judgments are identified in the text.