{"slug": "five-whys-why-we-need-a-sophisticated-framework-for-agent-collaboration", "title": "Five Whys: Why We Need a Sophisticated Framework for Agent Collaboration", "summary": "The AI industry's multi-agent systems remain tightly coupled to their harnesses, preventing agent reuse across systems, according to an analysis applying the Five Whys technique. The bottleneck is not models but the SDKs, orchestration frameworks, and harnesses that encode rigid workflows, and the article calls for a sophisticated framework with public collaboration contracts to enable dynamic, event-driven agent collaboration.", "body_md": "Five Whys: Why We Need a Sophisticated Framework for Agent Collaboration\nThe AI industry is moving quickly, but our multi-agent systems are still built like tightly coupled applications.\nWe call them \nagent harnesses\n, 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.\nThe 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.\nTo understand the problem, let's apply the\n \nFive Whys\n.\n1. Why can't we reuse agents across systems?\nBecause most agents are not independent software components. They are implementations embedded inside a specific harness.\nTheir 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.\nThis is tight coupling disguised as agent collaboration.\nWe 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.\n2. Why are agents tightly coupled to their harnesses?\nBecause collaboration is usually encoded as a rigid sequence or graph of steps.\nOne 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.\nThe result is \nagentic waterfall\n: agents are stuck inside predefined chains, branches, and graphs.\nThese 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.\n3. Why do frameworks promote rigid orchestration?\nBecause they model multi-agent systems primarily as workflows rather than environments.\nA workflow asks:\nWhich step should execute next?\nA collaborative environment asks:\nWhat happened, who should care, and how should each participant react?\nThat is a fundamentally different mental model.\nTools 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.\nBut 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.\n4. Why don't we already have a public collaboration layer?\nBecause the missing concepts have not yet been carefully separated and designed.\nIn 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.\nThe result is often visible in the documentation: vague concepts, overlapping responsibilities, and branded terms such as “managed agents” that hide tightly coupled implementations underneath.\nInteroperability cannot be added as a small adapter at the end. It requires granular, explicit contracts for questions such as:\nHow does an agent discover other participants?\nWhich events is it allowed to observe?\nWhen should it react, and when should it remain silent?\nHow does it decide whom to contact?\nWhat state can it read or change?\nWhich tools is it permitted to use?\nCan its behavior change while the system is running?\nHow can humans or other agents pause, redirect, or stop it?\nHow can it join and leave without breaking the rest of the system?\nThese are framework-level concerns. Solving them requires more than another orchestration graph. It requires a sophisticated and carefully designed runtime for agent collaboration.\n5. Why does agent interoperability matter?\nBecause it will change both how we build software and how agents are distributed and monetized.\nMCP 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.\nImagine 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.\nYou 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.\nCompanies 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.\nAgents would become portable participants, not features trapped inside products.\nFrom orchestration to dynamic collaboration\nAt JigJoy, we are moving toward this vision with\n \nMozaik\n, our TypeScript runtime for concurrent AI agents.\nThe 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.\nWe are now moving closer to dynamic changes in agent behavior, richer participant awareness, and intelligent communication—with the ultimate goal of enabling agent interoperability.\nThis 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.\nThe 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.\nThe model layer is advancing quickly. Now the collaboration layer needs to catch up.\nGet on the bandwagon before it takes off—join our hackathon and start building concurrent AI agents today.\nbuild.jigjoy.ai\nMiodrag Vilotijević\nCo-founder @ JigJoy\nBuilding the future of agentic systems\nWith 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.\nNewsletter\nFor developers who want to learn how to build self-organizing agents.\nJoin our online hackathon\nJoin our online hackathon for building multi-agent systems.", "url": "https://wpnews.pro/news/five-whys-why-we-need-a-sophisticated-framework-for-agent-collaboration", "canonical_source": "https://mozaik.jigjoy.ai/blog/agent-interoperability-is-the-missing-layer", "published_at": "2026-08-27 10:00:00+00:00", "updated_at": "2026-08-27 11:19:34.627766+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure", "ai-research"], "entities": ["Claude Code", "Codex", "Cursor", "MCP"], "alternates": {"html": "https://wpnews.pro/news/five-whys-why-we-need-a-sophisticated-framework-for-agent-collaboration", "markdown": "https://wpnews.pro/news/five-whys-why-we-need-a-sophisticated-framework-for-agent-collaboration.md", "text": "https://wpnews.pro/news/five-whys-why-we-need-a-sophisticated-framework-for-agent-collaboration.txt", "jsonld": "https://wpnews.pro/news/five-whys-why-we-need-a-sophisticated-framework-for-agent-collaboration.jsonld"}}