{"slug": "two-steps-away-from-agent-interoperability", "title": "Two Steps Away From Agent Interoperability", "summary": "Mozaik released a new version introducing core architectural concepts—Agent Loop, Interception, Situation Handler, Participant Manifest, and Shared Runtime State—to enable AI agents to operate across projects. The release models the agent loop with explicit states and the Specification design pattern, allowing developers to compose specifications for loop transitions. These features support the three pillars of agent interoperability: concurrency, awareness, and adaptivity.", "body_md": "Two Steps Away From Agent Interoperability\nWe are one step closer to enabling AI agents to be shared across projects.\nJust 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:\nAgent Loop\nInterception\nSituation Handler\nParticipant Manifest\nShared Runtime State\nThese are not merely framework features. Together, they form an architectural foundation for agent interoperability.\nAgent Loop\nWe modeled the agent loop as a sequence of explicit states and used the Specification design pattern to control transitions between them.\nDevelopers 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.\nAn 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.\nInterception\nAn Interception can pause, continue, redirect, or stop an agent loop while it is running.\nThis 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.\nBecause interceptions are decoupled from the agent, each environment can introduce its own governance rules without modifying the agent itself.\nSituation Handler\nSituation Handlers define how an agent reacts to a specific combination of semantic events, event producers, and shared runtime state.\nInstead of embedding every possible reaction inside the agent, developers can attach behavior based on the situation in which the agent finds itself.\nThis 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.\nParticipant Manifest\nA Participant Manifest describes an agent or another participant inside the collaborative environment: its identity, role, capabilities, and other information required for collaboration.\nWhen 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.\nParticipant Manifests provide the foundation for discovering and understanding collaborators at runtime.\nShared Runtime State\nConcurrent agents need a common representation of what is happening in their environment.\nShared 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.\nIt allows agents to work independently while still coordinating around shared goals and resources.\nThe Three Pillars of Agent Interoperability\nTogether, these concepts support the three architectural pillars required for agents to move between projects.\nConcurrency\nAgents must be able to operate independently without blocking one another.\nShared Runtime State enables coordination among concurrent agents, while Interceptions allow humans or other agents to govern their execution without tightly coupling their loops.\nAwareness\nAgents must understand the environment they have entered.\nParticipant 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.\nAdaptivity\nAgents must be able to change their behavior based on the needs of a new environment.\nSituation 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.\nThis means the same agent can behave differently across projects without being rewritten for each one.\nMozaik Cloud as a Reflection of the Runtime\nMozaik Cloud reflects these same architectural concepts and makes what happens inside a collaborative environment visible.\nDevelopers can inspect agents and other participants, semantic events, runtime state, Agent Loops, Situation Handlers, and Interceptions.\nThe 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.\nWhat Comes Next\nDevelopers 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.\nHowever, this awareness is still implemented at the application level.\nFor true plug-and-play agent interoperability, two capabilities must become native parts of the framework:\nNative participant and runtime awareness\nAn agent entering a new environment should automatically discover its participants, their capabilities, the available resources, and the relevant collaboration context.\nRuntime generation and switching of Situation Handlers\nUnderstanding 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.\nThe first capability allows an agent to understand where it is.\nThe second allows it to decide how to behave there.\nOnce 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.\nThat is the foundation required for plug-and-play agents—and for sharing AI capabilities across projects instead of rebuilding them inside every application.\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/two-steps-away-from-agent-interoperability", "canonical_source": "https://mozaik.jigjoy.ai/blog/two-steps-away-from-agent-interoperability", "published_at": "2026-09-03 11:53:25.068790+00:00", "updated_at": "2026-09-03 11:53:26.553835+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["Mozaik"], "alternates": {"html": "https://wpnews.pro/news/two-steps-away-from-agent-interoperability", "markdown": "https://wpnews.pro/news/two-steps-away-from-agent-interoperability.md", "text": "https://wpnews.pro/news/two-steps-away-from-agent-interoperability.txt", "jsonld": "https://wpnews.pro/news/two-steps-away-from-agent-interoperability.jsonld"}}