Give everyone their own AI agent and the group gets a worse result

Give everyone their own AI agent and the group gets a worse result.

Recent experiments on AI agents working in shared settings point firmly in that direction, and it's a result I keep turning over. It cuts against an assumption built into most of the agent products I see being planned right now.

So I want to walk through what the experiments found, why the failures look so familiar, and what I think product teams should take from it.

What the experiments looked at

The setup was four everyday scenarios: a team splitting a limited compute budget, a clinic calendar, a group booking and a code merge queue. None of these is exotic. They're the kind of shared, slightly messy coordination problem that fills most working weeks.

In every one of them, the group did better when a single agent served everyone than when each person delegated to their own. The gap was roughly 10 to 45 percentage points. That isn't a rounding error you can tune away with a better prompt. It points at something structural about how the work was set up.

The failure modes will feel familiar

Anyone who has run a project will recognise what went wrong:

• Too little, too late. Agents were slow to act, and did less than the situation needed.
• Acting before reading. One agent committed to a shared booking before it had read every message from the others.
• Overriding each other. Some agents overrode other people's requests.
• Filling the gaps. When each agent could only see its own user's notes, it filled the gaps with things that weren't true.

Read that list again and swap "agent" for "colleague". It's a fair description of a project where everyone is busy, nobody owns the whole picture, and people act on partial information. Giving each person a capable assistant doesn't fix that. If anything, it lets each person push their own view further and faster.

The last point worries me most. An agent that can only see one person's notes still tries to produce an answer, and when the information isn't there it can fill the space with something plausible. In a shared setting, that invented detail can then become someone else's starting point.

One person, one assistant is the wrong default

Most agent roadmaps I see assume one person, one assistant, acting on their behalf. It's a neat model and easy to demo. Real life tends to be shared, though, with budgets, calendars, baskets and release cycles that all have more than one owner.

In fintech the stakes rise quickly, because a household's money or a firm's treasury rarely answers to a single person. A joint account, a family budget, a payment run that needs sign-off from two people: these are shared by design. An agent that acts confidently for one person in that setting can create a problem for everyone else with a stake in the same money. It's a big part of why we think carefully about agent design in our fintech work.

The fixes were about product design

The fixes varied by scenario. A lead agent helped in one, and a simple rule that blocked checkout until every message had been read helped in another.

Neither of those depends on a smarter model. One is a decision about who coordinates. The other is a guardrail that anyone who has designed a checkout flow would understand. To me that puts as much weight on product design as on model capability, and product design is where teams like ours spend our days.

What founders and product teams can take from this

If you're building agents into a product where more than one person has a stake, a few questions are worth asking early:

• Who owns the shared resource? List every budget, calendar, basket or queue your agent can touch, and who else depends on it.
• One coordinator or many? Decide whether a single agent should serve the group, or whether one agent should lead and the others defer to it.
• Can an agent act before it has the full picture? Block irreversible steps, like a booking or a payment, until every relevant message has been read.
• What happens when information is missing? Make "I don't know" an acceptable answer, and show users what the agent couldn't see.
• Are you testing with groups? Evaluate agents in multi-user scenarios, not only in one-person demos.

None of this needs to wait for better models. It's design work you can start with the tools available today, and it's the kind of problem our AI services team works on with clients.

Teaching agents to share

I keep wondering whether the next real leap for agents will come from teaching them how to share, and what that looks like when the thing being shared is money.

My guess is that the teams who get this right won't be the ones with the most capable agent. They'll be the ones who designed for the group from the start. If you're working through that question in your own product, we'd be glad to talk it through.