More agents make ownership harder

Local success can hide an unfinished commitment

In the 12 October publishing workflow, a merged source change closed a tracking issue while broader work remained. The executor had finished a legitimate local milestone. The shared task state made that look like the whole commitment. This was an observed mismatch between completion boundaries, not evidence that adding agents always makes a system worse.

A specialist can be right about its own work and still leave the institution with the wrong operating state. The problem grows when handoffs hide which definition of done they use. I therefore separate the owner of the outcome from the runtime that happens to execute the next action.

Authentication does not explain the whole delegation

The June 2025 MCP authorization specification covers HTTP transport access. The client names the target resource; the server validates that the token was issued for its audience. Those checks constrain where a credential can be used. They do not, by themselves, describe the business task that a retrieved paragraph is allowed to change.

A runtime acting through its own service identity and one acting on behalf of a person can both authenticate successfully. Their authority should not become indistinguishable in the work record. Keep the requester, executing identity, approved scope and reviewer separate. OAuth token exchange has its own vocabulary for delegation and impersonation in RFC 8693; it is not an automatic property of every MCP connection.

In my design, tool access and inference routing have different jobs. A shared tool gateway can mediate access while a separate model route chooses inference. Exercising one tool call does not prove the routing, delegation semantics or every runtime boundary worked. Those require their own tests.

Where a real boundary caught a bad proposal

On 12 October, a large issue-description read exceeded the output boundary of a tool response. The consumer failed to decode the complete description, then constructed a replacement with a missing value. Automatic approval review rejected the write because it could discard the original plan and receipts. No description was overwritten.

The retry retrieved bounded pieces at one issue revision, checked completeness, preserved the original text and compared the full destination after the guarded update. This is a case of an unchecked read contaminating a proposed effect, not a prompt-injection experiment. A separate reviewer caught this instance; it does not prove that review catches every malformed proposal.

The same architecture has to make refusals useful. A rejected effect needs a reason and a next actor; otherwise the boundary protects the record while abandoning the work. Review time, retry reads and recovery all consume attention. They belong in the operating cost of delegation.

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.