Authority Should Not Travel with the Prompt

“Publish this if it is safe” looks like a simple request.

It is actually several requests hiding in one sentence. Someone must assess the evidence. Someone may recommend a decision. Someone may need to approve publication. Someone may have permission to make the change. If the system treats the prompt itself as permission, it can skip every one of those distinctions.

That is why I think of authority as a contract at the receiving boundary. A request says what the caller wants. The receiving role decides what it may actually do, what it must hand off, and what should return to the caller. A Practical Architecture for Reliable Multi-Agent Systems places that contract beside ownership and delivery.

This article builds on Transport Is Not Ownership. It explains why moving a message does not make the receiver responsible for its meaning. This one focuses on the practical rules that keep a request from becoming an accidental permission slip.

Start with an authority contract

Every role should have a plain answer to four questions:

The contract should be narrow enough to guide a real decision. “May handle releases” is not useful. “May assess the defined checks and return a recommendation; operator approval is required before publication” is useful.

This does not require a complex policy engine. It requires a clear service interface, role guidance, and a place to record the decision when work crosses an important boundary.

Ask for less than the system could do

Good authority design starts before the request reaches the receiver.

Give the role the objective, the source material or exact places to inspect, the relevant limits, and the decision you need back. Do not send a broad instruction that quietly bundles unrelated actions.

For example, a release owner may need to answer:

Assess whether the stated release checks are satisfied.
Return a recommendation, caveats, and any missing evidence.
Do not publish, merge, or change production.

That request gives the owner a useful job without assuming it can carry out the final external action.

Narrow requests improve more than security. They make work easier to review. A future reader can see what the role was asked to decide, what evidence it used, and what remained for another person or service.

The receiver chooses a safe disposition

The receiver should not have only two choices: do everything or refuse everything.

Safe narrowing is often the most useful option. It lets the system make progress without pretending that a partial answer is a completed action.

For a release request, the owner might return: “The stated checks pass, but the change still needs operator approval before publication.” That is not a failure. It is a clear boundary doing its job.

Keep public access separate from internal capability

Not every capable role should be directly callable.

A public entry point can accept a known kind of request and send it to the owner responsible for the domain. The owner may use private specialists for policy review, tooling diagnosis, or evidence analysis. Letting every caller invoke those specialists directly would bypass the owner that must reconcile their advice and check authority.

The public/private split is a routing design as much as an authority design. Transport Is Not Ownership covers the broader responsibility model. Here, the practical rule is simpler: a caller should reach the role that owns the decision, not whichever internal role seems most capable.

Approval gates should leave a useful trail

An approval gate is not just a pause button.

It should say what is being approved, who has the authority to approve it, what evidence supports the decision, and what action follows. If the requester has to decide, the system should return an owner-approved recommendation in a form they can actually use.

That last detail matters. A worker can write an analysis without the responsible owner accepting it. An owner can accept the analysis without the requester receiving it. Done Is Not Delivered explains why those are separate states.

Clear gates make later review much easier. Instead of asking, “Why did the system change this?” you can ask, “Which role recommended it, which role approved it, and what did the system record?”

Residual work should stay visible

Many agent requests end with a useful partial answer.

Perhaps the owner completed the assessment but needs a human approval. Perhaps one dependency is still missing. Perhaps another domain has to decide a connected question. Do not hide that remaining work inside a vague “done” state.

Return the completed part, name what remains, and keep the next owner or approval step visible. A lifecycle tracker can help keep that obligation from disappearing, but it should not decide the missing domain question itself.

This is one reason authority boundaries and delivery belong together. The system is not finished when an agent reaches the edge of its authority. It is finished when the right person receives a useful result and knows what decision remains.

Good boundaries add some friction on purpose

This design has a cost. More checks can mean another handoff, another request, or a slower answer. A narrow role may need context the caller did not provide. An approval gate can delay a straightforward change.

I still prefer that friction when the alternative is a prompt that silently turns into permission. The goal is not to stop agents from helping. It is to let them help in ways that are inspectable, reviewable, and proportionate to the action at stake.

Before a role acts, ask three questions:

1. What decision is this role actually being asked to make?
2. What authority does it have for that decision and any resulting action?
3. If it cannot complete the request, who owns the next useful step?

Those questions keep a convenient message path from becoming an unowned permission path.

If the controls feel heavier than the work, When Agent Architecture Is Too Much gives a practical test for stepping back to a simpler design.