Running two agents that both know your company

Yes, on one condition that has nothing to do with their number: their contexts must not overlap. And for them to genuinely cooperate, one of the two has to accept ceasing to be a colleague for the duration of the call.

The situation is already common and nobody decided on it. A company ends up with a generalist agent supplied by its office platform, a business agent installed by one team, sometimes a third that arrived with a tool. None of those choices is absurd taken separately, and the whole becomes absurd if the question of context was never asked.

Why “one agent, not twelve” does not forbid having two

We have written that one well-equipped agent beats twelve that do not talk to each other, and that position is often read as a rule about numbers. It is not, and clarifying it is where everything else starts.

What we hold against the twelve agents is not that they are twelve, it is that each claims to know your company. Twelve installations are twelve copies of your rules, your clients and your history, each ageing at its own speed. The bad number is not how many agents you have, it is how many places your context is copied to.

Reworded that way, the rule perfectly permits two agents, on the sole condition that their context domains are disjoint and the boundary is written down somewhere. An agent that knows your accounting entries and an agent that knows your consultants get in each other’s way no more than two employees in two departments.

Where the boundary runs, concretely

Not over tasks, which always overlap, but over facts. The question to ask for each category of information is one of ownership: which of the two agents may write this, and which has to go and ask?

Take a client of your consulting firm. Their billing address and outstanding balance belong to the financial domain. Their profile preferences, their history of rejections, the name of the person who actually decides, belong to the staffing domain. These are facts about the same entity, and they have two legitimate owners, which is perfectly workable as long as each knows which of the two governs what.

The exercise takes one meeting and it is done in writing. Three columns are enough: the category of fact, the owning agent, and what the other does when it needs it. That third column has only two acceptable answers, it asks or it goes without, and never it keeps a copy.

What happens when both know the same client

This is the one scenario to avoid absolutely, and it does not look like a failure.

The first agent learns in March that a client refuses profiles without security clearance. The second learns it in June, in a conversation where somebody qualified the rule. Three months later, both answer the same question with the same confidence and two different answers, and nothing in the system flags the gap. Whoever receives the wrong one has no reason to be suspicious, since the agent giving it to them is the one they use every day.

This failure mode is particularly unpleasant because it is silent, gradual, and gets worse precisely with use. The more the two agents work, the more facts they accumulate, and the higher the probability of an undetected disagreement. It is also why what an agent forgets matters as much as what it keeps: a memory that never purges is a memory that ends up contradicting another.

Talking to each other: what the protocols already allow

The technical part is the most advanced, and that is what misleads people. Making two agents converse is no longer a serious problem.

You invoke a precise capability with MCP, whose result shape you know in advance. You hand a goal to another agent with A2A, which chooses its own steps and can ask for clarification along the way, discovery happening through a card declaring what it can do. We set out that distinction in writing that your agent is going to subcontract to other agents, and it is the right frame for thinking about an integration stack that no longer contains only software.

On governance, the tooling is arriving too. Microsoft has made available a control plane bringing together the inventory of agents, their permissions, their behaviour and their cost in one place, which is exactly the inventory needed before writing anything. So the protocol and the registry exist. The problem is elsewhere.

The three questions the protocol does not settle

None is technical, and all of them arise on the day the chain produces a bad result.

Which memory governs? When agent A asks agent B what it knows about a client, and B answers something A believed otherwise, you need a rule written in advance. Without one, each agent keeps its version and you have just manufactured the divergence you meant to avoid, with an exchange protocol on top.

Which approval rule applies? This is the most common hole. An internal agent asks another to send a message to a client, and the outbound action gets executed without any human being asked, because each of the two considered the request to have come from inside. The rule that holds is that approval follows the action, never the agent: an outbound send is still an outbound send even when nobody typed anything.

Who answers? A called agent returns a decision, not an error, and it took that decision from information you will never see. When the result is wrong, responsibility is split between two vendors who have signed no contract with each other. That is also why applying the same governance to every agent is not enough: what has to be governed here is a chain, not units.

The rule we apply

It fits in one sentence and it resolves all three questions at once: to cooperate, one of the two agents stops being a colleague and becomes a consultant for the duration of the call.

Concretely, the called agent receives a question, returns an answer, and retains nothing from the exchange. It does not learn your client, it does not update its memory, it does not become a second holder of your context. It is paid by the question, like an outside expert, and that is precisely what makes it callable as often as you like.

The calling agent remains solely responsible. It holds the context, it decides what to do with the answer, it applies the approval line before anything goes out. The chain therefore has a single owner, which makes the question of accountability trivial instead of insoluble.

The counterpart is real and I would rather name it. A consultant that retains nothing costs more, because the context has to be given again on every call, and that context is rebilled each time. We accept that overhead, and it is a trade-off rather than an obvious choice.

Which leaves the question that governs all the others, whether these specialised agents have a future against generalists that improve on their own. We have answered it elsewhere, and the answer rests on what a model never transfers: the responsibility a product accepts to carry.