The delegating organisation stays accountable. Handing a task to another agent over a protocol such as A2A does not move responsibility for the outcome, because the receiving agent owes nothing to the people the task affects. The delegating system must record what it asked for, what authority it granted, and what came back, before it acts on the result.
Delegation is not the same as integration
Calling a tool and delegating to another agent look similar from the outside: a request goes out, a response comes back. The difference is what sits behind the response. A tool, reached through something like MCP, exposes a named operation with a defined input and output shape. The tool contract is the thing you can reason about: what it does, what it refuses, what it logs.
An agent on the other end of a delegation is not a fixed operation. It interprets the task, applies its own judgement to ambiguous instructions, may call tools or other agents of its own, and can change its behaviour between one call and the next as its own system is updated. Protocols built for this, such as Agent2Agent, standardise how a task is described, how its progress is reported and how capabilities are discovered. They do not standardise who answers for the result, and they are not designed to.
A protocol describes the handshake, not the accountability
Reading the specifications for emerging agent protocols is a useful exercise precisely because of what they leave out. They define message formats, task lifecycles and capability cards. None of them define an owner for a delegated task, a review step before its output is used, or a record that survives the interaction. That is deliberate: a transport layer should not dictate governance, but it does mean an organisation adopting one of these protocols has to build the governance itself rather than assume the protocol supplies it.
This is the same gap that sits underneath tool access. Treating MCP as an integration layer rather than an authorisation layer applies equally to an agent-to-agent protocol: it moves a request efficiently, and it is silent on whether the request should have been made.
Authority has to travel with the task, not be assumed by the receiver
A delegated task should carry an explicit statement of what the receiving agent is permitted to do with it, not an implicit licence to use whatever tools it has. If an internal agent delegates a document-retrieval task to a partner organisation's agent, the request should name the records in scope, the purpose of the retrieval and an expiry, rather than trusting the other side to infer a sensible boundary.
This matters more, not less, once the receiving agent belongs to someone else. Identity and authority carried per call inside one organisation's systems do not automatically cross an organisational boundary, and a receiving agent has no way to apply a permission check it was never given the information to perform. Treat every delegated task as a scoped grant, written down at the point of delegation, rather than a favour asked in natural language.
Keep a record on both sides of the handoff
Neither party should rely on the other's log. The delegating agent should record the task it sent, the authority it granted, the response it received and what it did with that response. The receiving agent, if it is one you operate, should record the same from its side: what arrived, what it did, and what it returned. When the two records disagree, that disagreement is itself useful evidence rather than a problem to suppress.
This is the point an organisation adopting agent-to-agent protocols for the first time most often misses: it instruments its own agents for an audit trail, then treats a delegated call as a single opaque step in that trail instead of a boundary that needs its own entry on each side. What an audit trail needs to contain does not stop being true because the next hop is another agent rather than a database.
Decide where a person still needs to see the result
Some delegated tasks are safe to accept without review: a read-only lookup, a classification, a draft that a person reads before anything happens because of it. Others carry consequences that should not rest on one agent's assessment of another agent's output. A hypothetical procurement agent that delegates supplier verification to a partner's agent should not also let that partner's response authorise a payment; the verification result is evidence, and a decision step, human or policy-controlled, still has to act on it.
The Propose-Decide-Execute pattern used for governing agent skills extends naturally here. The delegated task produces a proposal, not a completed action. A separate decision evaluates that proposal, and a separate executor carries it out under its own authority. Delegation across agents is then one more source of evidence feeding a decision your own system still owns, rather than a shortcut around it.
Treat the other agent as an untrusted source until proven otherwise
An agent you did not build and cannot inspect should be treated the way you would treat any other external input: useful, but not trusted by default. Its output can be wrong, stale, or shaped by an update on its side that you were never told about. Validate what comes back against the shape you expected, refuse results that fall outside it, and set a timeout and a retry limit so a delegated task that never resolves does not leave your own workflow waiting indefinitely. Classify the failure, make the retry safe to repeat where it is safe at all, and hand anything unresolved to a person rather than guessing.
CodeDTX's enterprise AI governance framework and MCP integration work covers delegation across agent boundaries as part of the same control set as tool access and human approval. If your agents are starting to call agents you do not operate, talk to CodeDTX about where the accountability needs to sit before the first one goes live.
Frequently asked questions
Does adopting a standard protocol like A2A change who is accountable for a delegated task?
No. A standard protocol changes how the request is formatted and transported, which reduces integration work, but it has nothing to say about responsibility for the outcome. The organisation that delegated the task remains accountable for what it did with the result, in the same way that using a standard shipping label does not change who is liable for what is inside the parcel.
How is agent-to-agent delegation different from calling a tool through MCP?
A tool reached through MCP exposes a fixed operation with a defined input and output, so its behaviour is mostly stable and its boundary is written down in the tool contract. A delegated agent interprets the task itself, may use tools or agents of its own, and can change behaviour when its own system is updated. Delegation therefore needs the same authority and logging controls as a tool call, plus validation of a result whose producer you cannot fully predict.
Should a delegated agent's response ever trigger an action directly?
Only for actions with no meaningful consequence if the response is wrong, such as populating a draft a person will still review. Anything with a real effect, such as a payment, a record change or a message sent externally, should treat the delegated response as a proposal that a separate decision step evaluates, rather than as an instruction the receiving system executes on arrival.
What should the delegation record actually contain?
At minimum, the task sent, the scope of authority granted with it, the identity of both agents involved, the response received, a timestamp for each step and what the delegating system did with the result. Store this on the delegating side even when the other agent belongs to a different team or a different organisation, since you cannot assume their record will be available, complete, or kept for as long as you need it.
Who owns the risk when the other agent belongs to a different company?
The company that delegated the task still owns the consequence for its own customers, data and decisions, whatever the contract with the other party says about liability afterwards. Contractual terms allocate cost after something goes wrong; they do not stop the wrong outcome reaching your users first. Apply the same validation, scoping and decision step used for an internal agent, and treat an external relationship as a reason to keep your own record, not to relax it.
