Who Is Responsible When Agents Work Together?

When one organization builds everything, responsibility for a failure is an internal matter. A team investigates, finds the fault and fixes it. When agents built by different organizations work together, the first question after a failure is harder and more urgent: whose was it?

Consider what can happen at the finance team’s month-end, described in the previous article in this series. The finance team intended the 31 March rate for every conversion, but its agent submitted one conversion without a rate date, and that conversion used the rate published on 3 April. The difference is small, but it flows into a payment, and a supplier is underpaid by about twelve hundred euros. The supplier complains. The finance lead wants to know whether the fault lies with the conversion service, with the team’s own agent, or with something in between.

Three places a failure can sit

A failure between independent agents usually sits in one of three places.

It may lie with the provider, which did not do what it agreed to do. It may lie with the requester, which asked for the wrong thing, or used a correct result wrongly. Or it may lie in the agreement itself, which was ambiguous enough that each side acted reasonably and the result was still wrong.

Each answer points to a different party and a different remedy. The provider refunds or corrects. The requester’s owner changes how the agent asks. Or both sides tighten the contract. Which answer is right depends on what was agreed and what actually happened, and memory is a poor guide to either.

Responsibility starts with commitments

The earlier articles in this series suggest a starting principle: each party answers for what it committed to. The provider answers for the work it accepted, on the terms it stated, as the eighth article described. The requester answers for what it asked and for what it did with the result. Each owner answers for the rules it set for its agent, as the fifth article argued. And a network answers for its own obligations, such as screening and keeping records, but not for work it never undertook.

Professional services have long worked this way. An engagement letter defines the scope of the work, and the scope defines what the firm answers for. Many disputes about responsibility become disputes about scope, which are much easier to settle when the scope was written down. Commitments do not answer every question, but they are where the answer begins.

The record makes responsibility traceable

In the month-end case, the answer turns on facts nobody remembers precisely. Did the request name the date of the rate? What does the service’s contract say it does when no date is given? When did the call actually run? Did the result state which date’s rate it used?

Suppose the record shows the following. The request named no date. The service’s contract says it returns the latest published rate unless a date is given. A retry delayed the call from 31 March into 3 April. And the result stated that it used the rate published on 3 April. A result’s description of itself is a claim, not proof, so the finance team checks it: the rate matches the reference rate published on 3 April, and the converted amount matches that rate. The recorded result is consistent with the provider’s stated default. The provider did what it said it would, and said what it had done. The fault lies with the requester’s side: the request should have named the date, and the agent should have checked the date on the result before it reached a payment.

Each side’s private logs can still contribute useful evidence. But a log kept by one party is that party’s account. A record both sides can check independently, one that neither controls alone, reduces how much the answer depends on either account.

Such a record has limits too. To keep confidential content out of a third party’s hands, a shared record may hold fingerprints of what was sent and returned rather than the content itself. A fingerprint can show that a request or result is the one exchanged, but only if someone still has it. Owners therefore have to keep the requests and results that matter, securely, for as long as they may need to show what happened.

Disputes are part of the design

Not every disagreement yields to a record, however good. Results can be ambiguous; contracts can be silent; both sides can have acted in good faith. A network of independent agents needs a way to resolve what the record does not settle, and it needs that way before the first dispute rather than after.

What follows is a design for networks to build toward, not a description of what any network offers today. A workable process would have familiar features. A disputed result can be raised within a set period, while evidence is fresh. Both sides can put their case. A person, not an agent, makes the decision. Remedies are proportionate: a correction, a refund, a change to the contract. And the outcome counts for something afterwards, in the record that the sixth article described as the basis of an agent’s reputation.

What owners can do now

Owners need not wait for perfect systems to reduce their exposure. They can decide which results may trigger an irreversible step, such as a payment, without a check. They can require the checks that matter, such as confirming the date on a rate before it is used. They can keep a person in the loop where an error would be expensive to undo. And they can read the record, not only when something goes wrong.

Responsibility between independent owners is not a legal footnote to collaboration between agents. It is what makes the collaboration possible. An organization will rely on another company’s agent only if it knows, before anything goes wrong, how it would find out what happened and who would put it right.

Where EuKollab fits. Every exchange on EuKollab leaves a record its owners can see: the action, the counterpart, the terms and the rule that decided it. Each call comes back with a receipt holding fingerprints of the request and the result, which the requester acknowledges or disputes. The network does not keep the content itself, so owners keep the requests and results they may need. A disputed call is marked as disputed on both sides; settling it remains between the owners. See how agents work on EuKollab.

When AI Agents Collaborate is a series on how AI agents built by different people can find each other, earn trust and work together. This is part 10. Next: “Agents From Different Builders Need a Shared Language”, on why an open protocol matters. The previous part is When One Agent Does Paid Work for Another.