Three departments use the same account-research agent. One team changes its shared instructions for a special customer, and another team receives a misleading brief a week later. The service owner says the agent ran correctly, the requester says they used the approved tool, and the editor says the exception was obvious in the original conversation.

Shared agents need responsibility for changes as well as tasks. Separate the person who accepts a result, the owner of the reusable method, and the operator of the service, and make the method version each task used discoverable.

The MCP enterprise discussion raises downstream attribution concerns. The organizational counterpart is deciding which human decision each identifier represents: asking for work, changing a method, approving an action, or operating the connection.

Define three kinds of ownership#

The task owner defines the request and accepts the output for its intended use.
The method owner decides which instructions and retained knowledge future tasks rely on.
The service owner keeps the runtime and connections working within the agreed operating scope.

During a pilot these can be the same person; write the roles down anyway. When a second team joins, the shared method changes independently of the service, and consequences reach people absent from the original discussion.

An agent's name identifies a tool or process and does not answer "who owns this?" Accountability requires people with authority to change the relevant conditions and a clear route for resolving disagreement.

Event	Primary decision owner	Evidence needed
Request is ambiguous	Task owner	Intended result and scope
Shared instructions change	Method owner	Version, rationale, and regression examples
Connection fails	Service owner	Error, affected path, and recovery action
External action needs consent	Authorized approver	Exact proposed action
Result is unsuitable	Task owner with relevant method owner	Output, source inputs, and correction

Work through a shared exception#

A customer has a one-time concession on payment terms, and a team member tells the agent to use those terms for that account. The correction has to stay tied to the account and its effective period; promoting it into a general account-review instruction would change other teams’ work.

The method owner reviews the proposed reuse, narrows its scope, and tests it against an ordinary account. The original correction stays as history and a separate current rule is published, so no successful improvisation silently becomes company policy.

When another team reports a bad brief, reconstruct the inputs and method version before assigning blame. The requester supplied the wrong account, the source changed, or the shared rule was too broad; the owner best placed to repair the cause leads the correction.

Make changes proportionate#

Classify changes by their effect on future work: formatting needs a simple review, while changes to target selection, commercial recommendations, permission assumptions, or external actions need representative tests and the appropriate business authority.

Let teams keep local variations when their work differs: a central method provides common source handling and evidence requirements, and a team-specific method handles its accepted output. Forcing every exception into the shared default makes it harder to understand and easier to misuse.

Define how a team opts out of a problematic version: fall back to a previous tested method or the manual process, with action controls still in place so the opt-out creates no unowned shadow agent.

Resolve disputes with the completed task#

A review asks what the task was to accomplish, which evidence it used, what changed, and which decision made the result unsuitable. Do not judge responsibility from the last person who clicked a button; a correct click can rely on a flawed shared method.

Retain a short correction record connecting the failure to the repair and the next test. If a fix changes one output, say so; if it changes future behavior, record the scope and owner. That lets one team’s expensive lesson reach another team without becoming an unsupported universal rule.

The budget ownership article separates financial roles, agent identity covers the operator view, and company knowledge explains the reuse path.