19 Give agents bounded responsibilities

“Implement acquisition” is a goal with a surprisingly large surface area. An agent might change storage, replace the networking library, alter error handling, add retries, and update the interface. Each action can sound helpful. Together they can outrun the authority and review capacity of the person who delegated the work.

A bounded responsibility joins an outcome to a permitted area of action. It gives the worker enough room to solve the assigned problem while identifying choices that belong elsewhere. The boundary must be understandable to the worker and enforceable where enforcement is warranted. A sentence asking the agent to be careful does not isolate its edits or prevent a release.

A handoff is a working contract

Consider the acquisition adapter after the publication contract has been established. Its handoff could be:

Task: Supply a checked candidate to the existing publication interface for the selected local resource.

Inputs: The selected identity, source location, expected integrity evidence, the publication contract at the agreed base, and the consumer acceptance examples.

Owned changes: The acquisition adapter and its focused tests. Shared status types are read-only until a proposed contract change is accepted by their owner.

Required behavior: Acquisition failure leaves the active version unchanged. A retry must not silently select different content. Successful transfer alone must not emit the consumer's available state.

Evidence to return: The resulting revision or patch, the focused check results, one failed-acquisition observation, and any assumptions that remain untested.

Escalation: Report an unsupported source identity, an inadequate publication contract, or a required change outside the write set. Explain the smallest decision needed and continue independent work where possible.

Integration: The integration owner reviews and applies the accepted proposal. The worker does not publish a release.

The handoff is short enough to revisit. Its restriction on shared types does not forbid noticing a design problem. It tells the worker how to make that problem visible without silently taking ownership of somebody else's decision.

An overly narrow assignment can fail too. “Change only line 42” may force a patch at the symptom when the defect belongs to a different owner. Bounded authority should permit diagnosis and a proposed scope change. It should not reward compliance with an inadequate edit location.

Separate four kinds of ownership

Task ownership answers who is responsible for reaching a result. Write permission answers what that worker may mutate. Integration ownership answers who combines the work with current authority. Acceptance ownership answers who decides that the result satisfies the intended need.

These roles can belong to one person in a small change. They still answer different questions. An implementation agent may own its task while having no authority to approve a change in user-visible behavior. A reviewer may have broad read access while remaining unable to modify the candidate. A release owner may accept a verified change without having written it.

The separation becomes useful when work stops unexpectedly. If the caller disconnects, does the task disappear, pause, or continue? Which resources remain held? Where can a replacement worker learn the current status? Tying every answer to the lifetime of one conversation creates avoidable uncertainty.

At Passeur revision 71bcac5a, task admission creates a task-owned cancellation controller rather than reusing the caller's signal. The inspected lifecycle tests distinguish a disconnected submitter or cancelled wait from cancellation of the worker. They also check a finite worker-plus-queue capacity. These are concrete source and test assertions; this book's research did not execute them. Task admission, lifecycle tests.

That distinction does not imply that every task should continue unattended. The appropriate policy depends on the authority originally granted, the resources in use, and the ability to observe or stop the work. The useful lesson is to make continued execution a deliberate contract rather than a side effect of a lost connection.

Make reporting part of useful work

A worker should report a finding when it changes a decision, not only when the task is over. Suppose the adapter discovers that the requested resource consists of two files. Waiting until the final report to mention this leaves the interface and tests developing against a false single-file assumption. An early update can be brief: what was found, which assumption it affects, and which work can continue.

The opposite failure is a stream of routine narration that consumes the coordinator's attention. Reports should carry information someone can act on: a conflict, a completed usable part, a needed decision, a failed acceptance check, or a material change in scope. The coordinator remains responsible for translating those findings into a coherent account for the requester.

A final response of “done” is inadequate when the task contract asked for a patch and evidence. A long explanation without a retrievable result is inadequate too. Return the work in a form that another person can inspect, including failure and uncertainty. Reviewability is a property of the deliverable.

Test whether the boundary is real

Give a worker the sample handoff and then introduce three situations: an unrelated file needs cleanup, a shared type seems wrong, and the source returns content with an unexpected identity. Ask what the worker would change, report, or refuse to infer.

The observable outcome is not a perfect recitation of permissions. It is that the worker can continue useful authorized work, identify the decision owner, and avoid converting convenience into authority. If every surprise blocks the whole task, loosen the boundary around diagnosis. If every surprise justifies broader edits, tighten the distinction between proposing and deciding.