More agents make ownership harder

The hard part starts when a model can act

Dividing a task among specialists can improve local work while making the overall result harder to own. That is a familiar organisation-design problem, now repeated at software speed. In my independent agent work, the important design question is which responsibility survives a handoff, rather than how many specialists can be added.

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.

When one agent is enough

A shared ledger and separate reviewer can be excessive for a short, reversible task with one clear owner. A single executor with a small tool surface may be easier to inspect. The case for separation grows when work outlives a session, crosses an authority boundary or needs a consequential change reviewed. Coordination has to earn its cost.

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.