When adding a second AI agent to the business, who coordinates between them?

This week, Erez Gomonovsky, CEO and founder of BAND, wrote an opinion piece in CTech describing a strange phenomenon among developers most advanced in AI adoption: they have several code agents running in parallel — one plans, one writes, one tests — and yet a significant portion of their time is spent copying information between agents. The agents are improving, but the human is increasingly becoming a "router": passing context, deciding what goes where, keeping the different sessions synchronized.

This is not a phenomenon unique to software development. The same problem is starting to appear in exactly the same way in businesses adding autonomous AI tools in marketing, service, and operations. Each agent can perform more work on its own, but these systems act as isolated participants, not as a team. And as their number grows, the productivity bottleneck shifts from "performing the work" to "coordinating it." With one agent, it's barely noticeable. With five or ten, someone needs to decide which system needs which piece of information, transfer output from one agent to another, and restart a process when a session resets.

Why this is exactly where we see projects get stuck

This is not a theoretical point. This is exactly what we examine in every implementation project — and why. Gomonovsky writes this in terms of code, but his observation is accurately true for a small business adding an AI agent for customer service, a separate agent for lead management, and a third tool for meeting scheduling: if no one decides in advance how they talk to each other — who makes a decision, who only recommends, what happens when conflicting information arrives from two sources — the organization didn't get automation. It got a new category of manual coordination work, only this time the business owner didn't plan for it in advance and didn't price it in terms of time.

Gomonovsky's main point is sharp: the natural reaction is to build "orchestration" — defining a fixed process in advance, who goes first and what happens next. This works well when the path is predictable. But many of the tasks for which AI agents are desired are valuable precisely because the path is not known in advance. An agent planning a campaign might discover it needs help from a data analysis agent. A customer service agent might need a handoff to a billing agent. Once that happens, the problem starts to resemble team management more than task list automation.

What two Israeli CISOs say about the same problem, from a different angle

That very same week, two Chief Information Security Officers at Israeli companies spoke in CTech about the exact same problem, just from the risk management angle. Nir Mashal, CISO at Orca Security, said that the gap between the pace at which organizations adopt agentic AI and the maturity of its governance is "the biggest risk I see in the industry today — and it is only widening." Eli Hakimuv, CISO at Immunai, described a parallel phenomenon called "Shadow Workforce": employees connecting AI tools to company systems without anyone in security knowing, and every such connection is a new identity with real permissions that no one is supervising.

Both interviews talk about security, not operations — but the diagnosis is the same: the problem isn't that the technology doesn't work. The problem is that no one defined in advance who is responsible, what is permitted, and what happens when something goes wrong. Mashal described it this way: "My fear is not of a malicious model; my fear is thousands of well-intentioned agents, with permanent permissions and chained tools, without an owner." This is exactly the same pattern Gomonovsky describes among development teams — just with a framing of risk instead of productivity.

What this means in practice for a business just starting out

The natural tendency is to postpone this question until there are several agents in practice. This is exactly the mistake. As soon as there are two autonomous AI tools touching the same customer, the same data, or the same conversation — the question "who coordinates between them" is already relevant, even if it still looks like just two separate tools.

In practice, this means asking before adding a second tool, not after:

• Who owns each agent — who is the person responsible if it makes a mistake?
• What happens when conflicting information arrives from two tools simultaneously — who decides?
• Which decision must still go through a human, and which does not?

The last point is the most important, and also the most counter-intuitive: the solution is not to remove humans from the picture further, but to keep them exactly where they have real value — making a decision in an uncertain situation, approving a sensitive action, identifying when something is behaving unusually — and removing from them only the clerical work of manually passing context between systems that are not built to talk to each other.

The claim worth admitting

The easiest defense here is to claim that this is a problem for large companies only, not for a business with five employees. There is some truth to that: the fewer autonomous tools there are simultaneously, the less likely they are to collide. But that is exactly why this is the right time to define it — before there are three tools and not just one, and before the answer to "who is responsible if it goes wrong" is "we didn't check." This definition takes one hour of conversation at the start of a project. Fixing it after it's already stuck takes much longer.

This is exactly what we check before we write a single line of code in an implementation project: not just "what will the agent do," but "who is its owner, what happens when it encounters something unexpected, and exactly where must a human still be in the picture."