Two Steps Away From Agent Interoperability

Two Steps Away From Agent Interoperability We are one step closer to enabling AI agents to be shared across projects. Just before our online hackathon this weekend, we launched a new version of Mozaik. This release introduces the core architectural concepts needed for agents to operate beyond the boundaries of a single hardcoded system: Agent Loop Interception Situation Handler Participant Manifest Shared Runtime State These are not merely framework features. Together, they form an architectural foundation for agent interoperability. Agent Loop We modeled the agent loop as a sequence of explicit states and used the Specification design pattern to control transitions between them. Developers can compose specifications that determine how the loop moves between inference, function calls, model messages, and other states. This makes advanced loop behavior extensible without hardcoding every possible flow into the agent. An agent that can be shared across projects cannot depend on one fixed execution loop. Its loop must be able to change according to the environment in which it operates. Interception An Interception can , continue, redirect, or stop an agent loop while it is running. This provides an abstraction for human-in-the-loop workflows, but it also enables agent governance: one or more agents can observe and influence the execution of another agent. Because interceptions are decoupled from the agent, each environment can introduce its own governance rules without modifying the agent itself. Situation Handler Situation Handlers define how an agent reacts to a specific combination of semantic events, event producers, and shared runtime state. Instead of embedding every possible reaction inside the agent, developers can attach behavior based on the situation in which the agent finds itself. This separation is essential for sharing agents. The agent provides its core capabilities, while each environment can define when and how those capabilities should be used. Participant Manifest A Participant Manifest describes an agent or another participant inside the collaborative environment: its identity, role, capabilities, and other information required for collaboration. When an agent enters a new environment, it must understand who else is present and what they can do. Without that information, agents may be technically connected while remaining isolated in practice. Participant Manifests provide the foundation for discovering and understanding collaborators at runtime. Shared Runtime State Concurrent agents need a common representation of what is happening in their environment. Shared Runtime State gives agents access to the state of the collaborative system and provides a foundation for coordination mechanisms such as ownership rules, mutexes, semaphores, resource allocation, and handoffs. It allows agents to work independently while still coordinating around shared goals and resources. The Three Pillars of Agent Interoperability Together, these concepts support the three architectural pillars required for agents to move between projects. Concurrency Agents must be able to operate independently without blocking one another. Shared Runtime State enables coordination among concurrent agents, while Interceptions allow humans or other agents to govern their execution without tightly coupling their loops. Awareness Agents must understand the environment they have entered. Participant Manifests describe the participants and their capabilities. Semantic events expose what is happening, while Situation Handlers allow agents to react when participants join or leave the environment or when runtime conditions change. Adaptivity Agents must be able to change their behavior based on the needs of a new environment. Situation Handlers decouple contextual behavior from the agent itself. Interceptions introduce environment-specific governance, while transition specifications allow the Agent Loop to change its execution flow. This means the same agent can behave differently across projects without being rewritten for each one. Mozaik Cloud as a Reflection of the Runtime Mozaik Cloud reflects these same architectural concepts and makes what happens inside a collaborative environment visible. Developers can inspect agents and other participants, semantic events, runtime state, Agent Loops, Situation Handlers, and Interceptions. The goal is not to introduce a separate monitoring vocabulary. What developers see in Mozaik Cloud should directly reflect the system they modeled in the framework. What Comes Next Developers can already build systems in which agents are aware of other participants and the runtime state. They can emit semantic events when agents join or leave an environment and use Situation Handlers to react to those events. However, this awareness is still implemented at the application level. For true plug-and-play agent interoperability, two capabilities must become native parts of the framework: Native participant and runtime awareness An agent entering a new environment should automatically discover its participants, their capabilities, the available resources, and the relevant collaboration context. Runtime generation and switching of Situation Handlers Understanding a new environment is not enough. The agent must be able to generate, select, and replace Situation Handlers dynamically as the participants, runtime state, and goals change. The first capability allows an agent to understand where it is. The second allows it to decide how to behave there. Once both become native, developers will no longer need to manually integrate the same agent into every new project. An agent will be able to enter a runtime, understand its collaboration context, and adapt its behavior accordingly. That is the foundation required for plug-and-play agents—and for sharing AI capabilities across projects instead of rebuilding them inside every application. 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.