From Fixed Agent Workflows to Intelligent Communication

Most multi-agent systems begin with the same assumption: developers must define the workflow before execution starts.

We decide which agent runs first, which agent receives its output, when a handoff happens, and what should happen next. We model the expected path through the system and connect agents using a graph.

This works while everything follows the happy path.

The problem begins when an agent fails, produces an unexpected result, needs information we did not anticipate, or discovers that another agent is better suited to continue the task. Because communication was defined in advance, the system has limited room to adapt. Recovery usually means adding more branches, conditions, retries, and fallback nodes to the workflow.

As the system becomes more capable, the workflow becomes more complicated.

Parallel Agents Are Still Often Isolated

Running agents in parallel does not automatically solve this problem.

Many systems allow a main agent to create several subagents and assign tasks to them. Those subagents may execute at the same time, but they are usually unaware of one another and unaware of what is happening in the broader environment.

The main agent sends work, waits for the results, and decides what happens next.

This is parallel execution inside a sequential coordination model.

The agents are still isolated. They cannot decide to exchange information, ask another agent for help, delegate part of their work, or react when something important happens elsewhere in the system.

It is difficult to imagine a future where intelligent agents must always follow fixed steps written by developers. Real environments change during execution. New information appears. Tasks become more complicated than expected. Some approaches fail, while others become possible.

Agents need to react to those changes instead of waiting for developers to predict every possible path.

Building an Event-Driven Multi-Agent Runtime

We built Mozaik as an event-driven multi-agent runtime.

Instead of moving agents through predefined workflow nodes, participants publish meaningful events into a shared communication environment. Other participants receive those events according to their subscriptions and decide how to react.

This separates communication from behavior.

The runtime is responsible for delivering information to the right participants. Each participant is responsible for interpreting that information and deciding what to do next.

An agent may update its context, call a tool, ask another agent for help, delegate a task, or publish a new event. That new event may cause other participants to react, creating collaboration dynamically during execution.

The workflow is no longer completely designed in advance. It emerges from events, context, and the decisions made by the agents.

Intelligent Communication Through Tool Calling

Event-driven communication gives agents a way to react to what is happening. The next step we are developing is intelligent communication through tool calling.

Each agent has information about the other participants in the environment and the capabilities they expose. An agent can use that information to decide:

• whether communication is needed
• which participant should receive the message
• what information should be shared
• which task should be delegated
• when another agent is better suited to continue the work

For example, a research agent may discover that part of its task requires legal interpretation. Instead of following a predefined handoff, it can identify a legal agent based on its capabilities and delegate that part of the task during execution.

The developer still defines the agents, their capabilities, and the boundaries within which they operate. But the developer does not need to model every possible interaction between them.

This is what we mean by intelligent communication: agents decide when to communicate and with whom based on the current task and the state of the environment.

Using Domain-Driven Design to Model the Runtime

Agent communication is a complex domain.

Terms such as agent, message, event, workflow, context, delegation, and environment are often used loosely. When those concepts are not clearly separated, implementation details quickly become mixed with domain behavior.

We are using Domain-Driven Design to build a clearer model of this space.

The goal is not only to create better class names. The goal is to understand the responsibilities inside the runtime and develop a language that helps us reason about agent collaboration.

The following concepts represent the model we are actively developing. They may change as we learn more and continue implementing the system.

The Environment and Its Participants

Agentic Environment

An agentic environment is the complete runtime environment in which participants exist and interact.

It includes participants, channels, subscriptions, semantic events, reactions, context, and interception.

An agentic environment is broader than a communication channel. A channel enables interaction, while the environment represents the whole world in which that interaction happens.

The agentic environment is currently an architectural and domain concept. It does not necessarily need to be represented by one large class in the code. Its technical expression may remain distributed across several smaller concepts.

Channel

A channel is a communication space within the agentic environment.

Participants join and leave a channel, publish semantic events, and receive events according to subscriptions. The channel manages membership, routing, and delivery.

It does not decide how a participant should behave after receiving an event.

Participant

A participant is an entity that exists within a channel and can publish or receive semantic events.

Concrete participant types currently include:

• Agent — an autonomous, model-driven participant.
• Human — a participant controlled through human input.
• Observer — a participant that monitors activity without directly participating in the collaboration.

Treating all of them as participants gives the runtime a common model for agents, people, and system-level observers.

Participant Manifest

A participant manifest is the public contract a participant exposes to the environment.

It describes the participant's identity and capabilities so other participants can understand what it represents and what it can do.

For an agent, the manifest may allow other agents to discover that it can review code, search documents, analyze legal rules, or perform another specialized task.

Internal tools, models, prompts, and implementation details remain private.

How Information Moves Through the Environment

Semantic Event

A semantic event is a fact published into a channel.

It states that something meaningful happened, identifies its producer, and carries the relevant data.

Examples could include:

• a participant joined the environment
• a task was completed
• new information was discovered
• an execution failed
• human approval was provided
• another participant requested help

Participants may interpret and react to the same event differently.

Subscription

A subscription is a routing rule that determines which participant receives which semantic events.

A subscription usually connects:

• an event type
• a producer
• a consumer

Subscriptions define the communication topology, but they do not define participant behavior.

They answer the question:

Who should receive this event?

The participant's reaction answers a different question:

What should happen after the event is received?

Interception

Interception is a mechanism that observes or controls an event while it moves through the environment.

An interception may inspect, enrich, reject, pause, or cancel event processing before or after delivery.

This creates a place for cross-cutting runtime behavior such as:

• tracing and logging
• human approval
• safety policies
• authorization
• event validation
• early cancellation
• execution monitoring

Interception allows these concerns to exist without placing them inside every participant.

How Participants Understand and React

Participation Event Map

A participation event map describes how a participant handles the event types it receives.

It connects semantic event types with the appropriate context projections and reactions for that participant.

This may remain primarily a technical TypeScript contract rather than becoming a first-class domain concept. Its role is to make the relationship between events, payloads, and participant behavior explicit and type-safe.

Context Projection

A context projection converts a received semantic event into a context item appropriate for a particular participant.

The same event may have different meaning or relevance for different participants.

For example, a completed research task may provide detailed evidence to a writing agent, while an observer may only need a short execution summary.

A context projection translates a shared environmental fact into participant-local information.

Context Item

A context item is information stored in a participant's local model context.

Context items represent what that participant currently knows and may influence future inference and decision-making.

Semantic events belong to the shared environment. Context items belong to an individual participant.

This distinction allows every participant to maintain its own view of what is happening.

Reaction

A reaction is participant behavior executed after a subscribed event is received.

A reaction may:

• update local context
• run model inference
• invoke a tool
• make a decision
• contact another participant
• delegate a task
• publish a new semantic event

The channel decides whether the event is delivered. The participant decides how to react.

The Runtime Flow

The complete flow currently looks like this:

1. A participant publishes a semantic event.
2. The channel applies the relevant interceptions.
3. Subscriptions determine which participants receive the event.
4. Each recipient projects the event into its local context.
5. The participant executes the appropriate reaction.
6. That reaction may publish new events or communicate with another participant.

This creates a continuous event-driven loop.

Collaboration does not need to be represented as one fixed graph. It can emerge during execution from the events that occur, the context each participant holds, and the decisions agents make.

From Workflow Orchestration to Self-Organizing Agents

Developers should still define goals, capabilities, constraints, and safety boundaries. Self-organization does not mean removing control.

It means moving away from the requirement to model every interaction and handoff before execution begins.

We believe future agentic systems will need to understand what is happening around them, communicate when necessary, delegate based on capabilities, and recover when reality diverges from the expected path.

Intelligent agents need more than predefined workflows.

They need an environment in which communication and coordination can emerge at runtime.

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.