Two robotic arms mid-handoff of a glowing capsule-shaped object, which hangs unlit and shadowed in the narrow gap between their grippers

When Agents Call Agents, Who Owns the Outcome?

An agent built in Copilot Studio can now hand its work to another agent without a person in between. Microsoft calls this “connecting agents to other agents,” and it runs on two real, named protocols: MCP, generally available in Copilot Studio since May 2025, which lets an agent reach external tools and data; and A2A, an open standard originally built at Google and now hosted by the Linux Foundation, which lets one agent discover and hand a task to another. Microsoft has built both into Copilot Studio specifically, not just its general-purpose AI platform.

That is a real capability running today, not a forecast. It also means a question that used to have an easy answer no longer does: when an outcome is wrong, which agent is responsible for it?

What “Agents Call Agents” Actually Means Right Now

Here is what’s real and what isn’t, because the two get blurred easily.

Inside Dynamics 365 itself, named agents are still mostly solo acts. The Account Reconciliation Agent, for one, logs every exception for its own audit trail — but nothing in its documentation describes it invoking a separate named agent for, say, collections or approvals. The chaining Microsoft has actually shipped lives one layer up, in Copilot Studio’s orchestration surface: an agent built there can hand off to a child agent, another Copilot Studio agent, or any agent reachable over A2A, and Microsoft’s own rollout notes describe this expanding through 2026 to cover Microsoft Fabric data agents and agents built on the Microsoft 365 Agents SDK.

So the accurate claim is narrower and more interesting than “D365 agents talk to each other”: the infrastructure for one agent’s output to become another agent’s input is real and generally available, and it sits directly adjacent to the ERP data those agents act on. A finance or operations team building agents on this platform today can wire up a chain — one agent drafts, a second agent acts on the draft — without writing any custom integration to do it.

That point matters more than it looks. A chain like this used to require somebody to build it deliberately — custom middleware, a scheduled job, an integration ticket that went through a review of its own. Handoff being a platform feature rather than a bespoke build means a chain can now exist because it was easy to wire up on a Tuesday, not because anyone made a considered decision that this process should work that way. Ease of assembly and deliberateness of design have quietly come apart.

Each Handoff Is Locally Defensible

Two separate scanning gates each independently confirming their own component with a green light, while a single component sits in the gap between them outside both beams

Here is the part that makes this different from a single misbehaving agent.

Microsoft’s own guidance for autonomous agents is reasonably strong on paper: every agent should operate “within scoped permissions, explicit decision boundaries, and auditable processes,” with detailed logs of triggers received, decisions made, and actions taken. Build a chain correctly and every individual agent in it can satisfy all of that. Each one has a defined scope. Each one logs what it did. Each handoff can be reviewed in isolation and pass.

None of that logging says anything about the chain as a whole. A log that shows Agent One drafted a reconciling entry within its permissions, and a separate log that shows Agent Two posted it within its permissions, do not add up to a record of the combined decision — because the combined decision was never anyone’s unit of review. Each agent was evaluated as if it were the whole story. It wasn’t.

This is not a hypothetical gap invented for this piece. Diffused responsibility is a named, studied problem in AI ethics — Bleher and Braun’s 2022 paper on clinical decision-support systems describes it as arising whenever “multiple options and several agents can be considered for attributing responsibility,” and more recent legal scholarship on the EU AI Act makes the same point specifically about systems that “autonomously plan, invoke external tools, and execute multi-step action chains,” flagging traceability across those chains as a genuine compliance problem, not a solved one. The pattern shows up wherever a decision gets assembled from more than one actor’s contribution. An agent chain is simply the newest place it appears, and one where the actors move faster than the review built to catch them.

This Is Not the Governance Gap Already Written About

Two things this is not.

It is not the problem of one agent answering to two owners — finance and IT disagreeing about who is accountable for a single agent’s control status, which is a real and separate failure mode already documented at length. And it is not the problem of one agent acting with unclear authority across legal entities, another real and separate failure already worth its own piece. Both of those involve one agent and an ambiguity about who is responsible for it.

This is a different shape. Multiple agents, each individually accountable to somebody, contribute to one outcome, and the outcome itself has no equivalent owner. It is possible for every individual accountability question to have a clean answer and for the combined-outcome question to have none at all.

Where This Actually Breaks

A row of four robotic arms each holding an identical glowing component, progressing cleanly until the final one is cracked and a mismatched color, though every station looks correct

A concrete version, close to what the platform already permits: an agent reviews a batch of vendor invoices and drafts payment recommendations within its scope. It hands the recommendations to a second agent authorized to schedule payments. The second agent schedules a payment against a recommendation the first agent generated from data that turned out to be stale. Both agents behaved exactly as configured. Both logs are clean. The payment still went out wrong.

Ask the obvious question — who owns this outcome — and there is no wrong answer, which is the actual problem. The first agent’s owner can correctly say their agent only drafted a recommendation. The second agent’s owner can correctly say their agent only acted on an input it was configured to trust. Both statements are true, and the payment still happened.

A second version of the same shape shows up outside finance entirely. A triage agent classifies an inbound case as low-risk and routes it; a resolution agent, trusting that classification, closes it without the extra check reserved for higher-risk cases. If the classification was wrong, the resolution agent did exactly what it was built to do with the input it was given. The failure lives in the space between the two agents, which belongs to neither of their owners.

What a Chain Needs That a Single Agent’s Governance Doesn’t Supply

The fixes below assume chains keep shipping; they just need managing as chains, not as collections of individually well-behaved agents.

  • A map of the chain itself. Which agents feed which, in what order, for which business processes. Most organizations can describe what a single agent does. Far fewer can produce, on request, a diagram of which agent output currently feeds which agent’s input.
  • One named owner per chain, not per agent. The individual agent owners can stay exactly as they are. What is missing is a person accountable for the combined outcome specifically, distinct from anyone accountable for a single link in it.
  • A record that follows the outcome, not just the actor. An audit trail built agent-by-agent will show what each one did. It takes a deliberate design choice to also produce a record that reconstructs the full path a single outcome took across every agent that touched it.
  • A decided checkpoint, not an assumed one. Some chains are low-stakes enough to run end-to-end without a person. Others need a human decision point somewhere in the sequence — and which chains fall into which category is a decision that has to be made on purpose, because the platform will not make it for you.

Where the Case Against This Is Strongest

A real complication cuts against this, and it cuts hard: requiring a named owner and a human checkpoint for every chain would defeat much of the reason to build one. Chaining exists because a single agent handling an entire process end to end is often worse than several narrower agents, each good at one step, connected together — the same argument for specialization that applies to people. Insisting on a person in the loop at every handoff reintroduces the exact bottleneck agents were adopted to relieve.

The realistic position is not “review every chain” but “know which chains exist and have decided, for each one, whether they need a checkpoint” — a smaller commitment than it sounds, and one most organizations currently cannot make because the first item on the list above, the map, does not exist yet.

The Question to Ask About the Chain You Already Have

Pick one process where an agent’s output currently feeds another agent’s action, if such a thing exists in your environment yet. Ask who owns the combined outcome — not either individual agent, the outcome. If nobody has been asked that question specifically, that is the finding, and it is cheaper to have it now than after a chain like the one above produces a version of it with a number attached.

Single-agent accountability stops covering what is actually happening in a few distinct places by now — a gap between two governance systems, a gap across legal entities, and, increasingly, a gap between agents themselves. DAX Software Solutions works across all three. Get in touch if you want help mapping the chains you are already running.

Scroll to Top