# Five Whys: Why We Need a Sophisticated Framework for Agent Collaboration > Source: > Published: 2026-08-27 10:00:00+00:00 Five Whys: Why We Need a Sophisticated Framework for Agent Collaboration The AI industry is moving quickly, but our multi-agent systems are still built like tightly coupled applications. We call them agent harnesses , but in most cases the model, tools, control flow, memory, permissions, and collaboration logic are intertwined inside one system. An agent built for one harness cannot simply join another. If we want a similar system elsewhere, we usually ask Claude Code, Codex, or another coding agent to hardcode a new version. The models are not the primary bottleneck. The real bottleneck sits in the middle: the SDKs, orchestration frameworks, and harnesses that determine how agents work together. To understand the problem, let's apply the Five Whys . 1. Why can't we reuse agents across systems? Because most agents are not independent software components. They are implementations embedded inside a specific harness. Their behavior depends on the harness's prompts, tools, memory format, workflow, state, and internal control flow. Removing an agent from that environment often means removing the assumptions that make it work. This is tight coupling disguised as agent collaboration. We can reuse models. We can reuse tools through protocols such as MCP. But we still cannot easily take a capable agent from one system, drop it into another team of agents, and let it collaborate safely. 2. Why are agents tightly coupled to their harnesses? Because collaboration is usually encoded as a rigid sequence or graph of steps. One agent completes its task, then another starts. A router decides which branch to follow. A supervisor calls a worker and waits for the result. Even when several agents run in parallel, they often rejoin at a blocking synchronization point before the workflow can continue. The result is agentic waterfall : agents are stuck inside predefined chains, branches, and graphs. These systems can be useful when the process is known in advance. But they are a poor foundation for open-ended collaboration. An autonomous agent should be able to observe what is happening, decide whether it can contribute, communicate with the right participant, and act without waiting for a central workflow to give it permission at every step. 3. Why do frameworks promote rigid orchestration? Because they model multi-agent systems primarily as workflows rather than environments. A workflow asks: Which step should execute next? A collaborative environment asks: What happened, who should care, and how should each participant react? That is a fundamentally different mental model. Tools such as Claude Code, Codex, and Cursor are beginning to expose more event-like behavior. This is an important signal: capable agents need to react to changing conditions instead of merely advancing through a fixed chain. But these products are still largely closed harnesses. Their internal collaboration models are not public contracts that other agents can implement. Developers can use the finished product, but they cannot freely bring its agents into another runtime or allow external agents to join it. 4. Why don't we already have a public collaboration layer? Because the missing concepts have not yet been carefully separated and designed. In many harnesses, event handling, agent identity, permissions, communication, runtime state, loop control, tool execution, and behavior are mixed together. The abstractions grow out of immediate product needs, sometimes through rapid, vibe-coded iteration, rather than from a deliberate model of dynamic agent collaboration. The result is often visible in the documentation: vague concepts, overlapping responsibilities, and branded terms such as “managed agents” that hide tightly coupled implementations underneath. Interoperability cannot be added as a small adapter at the end. It requires granular, explicit contracts for questions such as: How does an agent discover other participants? Which events is it allowed to observe? When should it react, and when should it remain silent? How does it decide whom to contact? What state can it read or change? Which tools is it permitted to use? Can its behavior change while the system is running? How can humans or other agents pause, redirect, or stop it? How can it join and leave without breaking the rest of the system? These are framework-level concerns. Solving them requires more than another orchestration graph. It requires a sophisticated and carefully designed runtime for agent collaboration. 5. Why does agent interoperability matter? Because it will change both how we build software and how agents are distributed and monetized. MCP made an important part of the agent stack reusable: external tools and context can be exposed through a common protocol. Agent interoperability is the next layer. It would allow an entire agent—with its expertise, behavior, permissions, and communication capabilities—to enter different systems and collaborate with other participants. Imagine that PostHog offered its own analytics agent. Instead of exposing only an API or toolset, it could provide an agent that understands analytics deeply, learns what your team is trying to achieve, monitors relevant events, and proactively contributes to decisions. You could add that agent to your system when needed and remove it when it no longer fits. You could replace it with an agent from another analytics provider without rebuilding your entire multi-agent architecture. Companies could rent specialized agents by the hour, per task, or through subscriptions. Developers could share and monetize the agents they build. Organizations could maintain their own trusted agents—with carefully scoped permissions—and deploy them into different collaborative environments. Agents would become portable participants, not features trapped inside products. From orchestration to dynamic collaboration At JigJoy, we are moving toward this vision with Mozaik , our TypeScript runtime for concurrent AI agents. The first preconditions are non-blocking execution and concurrency. In Mozaik, agents can be added to or removed from a running system dynamically. They work concurrently and react to semantic events and shared runtime state. They are aware of other participants and can decide when to communicate and with whom. We are now moving closer to dynamic changes in agent behavior, richer participant awareness, and intelligent communication—with the ultimate goal of enabling agent interoperability. This requires a new mental model for multi-agent systems. We need to stop treating agents as steps inside a workflow and start treating them as autonomous participants inside a shared environment. The next generation of agentic systems will not be built by hardcoding every collaboration path in advance. It will emerge from independent agents that can discover one another, communicate intelligently, coordinate safely, and leave without collapsing the system around them. The model layer is advancing quickly. Now the collaboration layer needs to catch up. Get on the bandwagon before it takes off—join our hackathon and start building concurrent AI agents today. build.jigjoy.ai Miodrag Vilotijević Co-founder @ JigJoy Building the future of agentic systems With tools and technology we already have, we can build much more valuable systems than most projects today. We can write software that is a pleasure to use and a pleasure to work on; software that doesn't box us in as it grows, but creates new opportunities and continues to add value for its owners. Newsletter For developers who want to learn how to build self-organizing agents. Join our online hackathon Join our online hackathon for building multi-agent systems.