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.

Today, developers drive that loop through runLoop, which emits events as it progresses through inference, function calls, model messages, and other states. That event stream is what the rest of the runtime can observe and react to.

It is not yet possible to write specifications that handle those transitions. The Specification design pattern is already part of the model, but as a foundation: it is what will later make loop handling declarative, so developers can compose rules for how the loop moves between states instead of 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

Developers pass an InterceptionHandler that intercepts a loop transition and can change how the loop behaves from that point.

This is not pause and resume. The handler does not suspend a running loop and continue it later. It acts at the transition itself: it can observe the move the loop is about to make and alter what happens next.

This still provides an abstraction for human-in-the-loop workflows, and it 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 at loop transitions, while the specification pattern behind the Agent Loop is the foundation for declarative execution flow in the future.

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:

1. 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.

2. 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.

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.