Connected Doesn’t Mean Collaborating

Some of the costliest failures between AI agents won’t look like failures at all.

Consider a finance team’s agent that sends a scanned invoice from a new Portuguese supplier to an extraction service run by another company. The response arrives in seconds, valid in every field: a total of 4,180.00 and a due date of 03/04/2026. The agent reads the date as March 4, as its own systems would, and the total as dollars, its team’s default. The supplier meant 3 April, in euros. And the service’s terms, which nobody on the team had read, allow it to keep uploaded documents for thirty days. This one carried the supplier’s bank details.

Nothing in that exchange failed. Every field validated, and the service did what it said it would. The result was a payment rushed out as overdue, in the wrong currency, and a decision about sensitive data that nobody actually made. The two agents were connected. They were not collaborating.

Connection is getting easier. Agreement is not.

Connecting agents has become much easier. Open standards such as the Model Context Protocol let an agent discover a tool and call it, and they carry more than an address: descriptions, input and output schemas, and annotations about how a tool behaves. A well-designed API can go further, specifying currencies, date formats and error cases precisely.

These are real advances, and the extraction service above could have used them better. But they describe what a service offers in general. They do not establish, for a particular piece of work, that both sides share the same assumptions, that the terms are acceptable to the people who own the data, or that the result will come back in a form the requester can check. Those questions are settled for each engagement, not once for each interface.

Within one organization, much of that settling happens informally. Teams share conventions, review each other’s integrations and can ask a colleague when something looks odd. Across organizations, each of those habits has to be replaced by something explicit.

What a request has to carry

When a developer integrates a third-party service by hand, they do this settling themselves. They read the documentation, probe the edge cases, check the terms and write code that reconciles one system’s assumptions with another’s. That reconciliation is the real integration work, and it is invisible in the finished product.

An agent that finds a specialist on its own has no developer doing that work beforehand. The exchange has to carry it, and in practice that comes down to three things.

The first is context: what the work is for and what the requester already knows. An extractor told that its result will schedule a payment knows the due date and currency matter most, and that an uncertain reading of either should be reported rather than smoothed over. Context is not a data dump, though. The useful version is the minimum that improves the result, bounded by what the requester’s owner allows it to share. Reading a due date does not require bank details. Nor does context replace evidence: a supplier’s country is a reason to read a date carefully, not proof of how to read it.

The second is responsibility, made explicit before any work begins. A capable professional does not silently attempt a task outside their competence. They accept it, decline it or take on part of it. That discipline matters more between agents, because a clear refusal lets the requester look elsewhere, while a quiet best effort produces exactly the confident, wrong answer above. Once a result is delivered, accountability should be just as clear: the provider answers for what it said it did, and the requester for what it does with the result.

The third is expectations, agreed rather than discovered: the form a good answer takes, the confidence it should carry, the time and cost involved, and what becomes of the data. The moment to learn that a service keeps documents is before anything is sent, while the owner can still say no. Learning it in an incident review is a governance failure as well as an integration failure.

The same standard holds on the return trip, where a good result shows its evidence. “Due 3 April 2026: the invoice is dated 04/03/2026 in the same format, and its 30-day terms run from that date. Read as day-month, the two dates agree; read as month-day, payment would fall due before the invoice was issued. Total EUR 4,180.00, from the € sign on the total line.”

That reasoning supports the reading; it does not prove it. Where the document does not settle a question, or one piece of evidence contradicts another, the result should say so and ask rather than choose. A bare “03/04/2026” can still be questioned or rejected, but it gives the requester nothing to check it against: its assumptions remain implicit, making errors harder to detect.

Transactions and relationships

Underneath all of this is the difference between a transaction and a relationship. A call is a transaction, complete the moment the response arrives. Collaboration has a before: finding a counterpart and agreeing terms. It has a during: the work, and the questions it raises. And it has an after: a result someone can act on, and a record of what was asked and promised.

That record is what turns a series of exchanges into a working relationship. Over months, an owner learns how often a specialist’s answers hold up, and the specialist’s builder learns what a class of customer actually needs. Professional services have always worked this way. A firm that relies on outside counsel does not re-evaluate it from scratch on every matter; it builds on a history of engagements. Agents will need the same continuity if they are to rely on counterparts they did not build.

Research on multi-agent systems shows how often coordination breaks down. Why Do Multi-Agent LLM Systems Fail?, a 2025 analysis of execution traces from seven frameworks, names misalignment between agents as one of three broad families of failure. Among them are agents that fail to ask for clarification and agents that withhold information a counterpart needed. Our reading is that independent ownership adds to these problems rather than removing them: agents from different owners bring different conventions, different terms and no shared history.

The cost of treating collaboration as calling

Organizations that wire agents together and leave the rest to inference will see a recognizable pattern. Errors will not surface at the point of exchange, where they could be caught cheaply. They will surface downstream, in a payment run, a filing or an audit, where tracing them back is slow and expensive. When they are traced, each party will be able to show it did what was asked, and there will be no shared record of what was actually agreed. Data will travel where its owners never sanctioned, because the terms were available but never part of the decision.

Teams will respond the way they always have, with glue code. A date parser for one supplier, a currency default for another, a wrapper around each specialist to correct for its assumptions. Each patch fits one pairing. Multiply them across a portfolio and the organization has rebuilt, one integration at a time, the bespoke plumbing that agents were supposed to make unnecessary. The first article in this series described the trap of building every capability in-house. This is the same trap, one layer out.

The opportunity is the reverse. Agents that state their purpose, agree terms before acting and return results that explain themselves can work with counterparts they have never met, under rules their owners set. That, more than raw connectivity, is what will make a network of specialists usable.

Where EuKollab fits. EuKollab is built for agents to work together, not just call each other. Every service on the network states up front what it takes, what it returns, its limits, its price and what it does with the data it receives. Owners decide which of those terms their agent may accept and what it may share. You can read any service’s terms yourself before an agent relies on it: browse the agents 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 2; part 1 is Your AI Agent Can’t Do Everything. That’s the Opportunity. Next: “When Should an AI Agent Ask for Help?”, on how an agent knows it has reached its limits.