Mozaik: When Agents React to Events Instead of Following a Script
Mozaik is a TypeScript runtime for reactive agents. This guide explains when an event bus and shared context help, which operating risks they create and how to keep a small pilot under control.
One agent searches a repository, another writes a patch, and a third is meant to check the emerging result against architecture rules. In a conventional pipeline each role waits for the previous one. That is often exactly right: a clear sequence is easy to test, observe and stop. The harder case begins when several tasks genuinely run at once and their context changes while they work. A rigid order then creates either idle time or a tangle of exceptions.
Mozaik approaches that problem not as another prompt wrapper but as a TypeScript runtime for reactive agents. Participants can see a shared environment and react to messages, tool results, model streaming and error events. That is an interesting direction for engineering teams, but it is not permission to let agents loose without a plan. The benefit appears only when events, states and responsibility are designed as carefully as APIs.
The NotebookLM draft behind this guide had the right core: parallel agent work moves the bottleneck from writing to understanding and verification. The editorial version turns that into a practical question: when is a reactive bus more useful than a well-bounded workflow?
What Mozaik models differently
Mozaik describes itself as an open-source runtime for agents that communicate and coordinate at runtime. Rather than wiring every handoff in advance, participants can listen for events, notice other participants and share relevant context. Its documentation distinguishes plain messages, typed context objects and SemanticEvent fragments from live model streaming.
That distinction matters. A streaming fragment is not yet a durable fact. It can be useful for live feedback or telemetry, but it does not automatically belong in persistent model context. Only completed messages, tool results or deliberately condensed decisions should be stored as context. This is what keeps every token from turning into unmanageable memory.
By comparison, LangGraph is a better fit when a team wants to model state nodes, checkpoints and controlled resumption explicitly. A terminal agent such as Claude can handle a bounded coding task without a multi-agent runtime at all. Mozaik becomes interesting when several participants need to react to one working state and the order is not known in advance.
A sensible first use: review signals, not an agent swarm
A good pilot is not an automated software factory. It can start small: a research or coding agent reports that an interface, schema or dependency graph changed. A second participant checks only that change against a maintained rule. A third summarises open points for a human. Nobody merges code, writes tickets or triggers external actions.
The outcome is not an "AI colleague team" but an inspectable signal:
- An event records source, time, affected area and trigger.
- A check adds evidence, uncertainty and the assumption affected.
- A human owner decides whether it becomes a branch, a test, a question or no action.
This shape matches the wider lesson from agentic engineering: a patch may compile yet still break a contract between components. Augment describes its Intent Verifier as a check against a living specification before a pull request. That does not prove that every runtime becomes safe by default. It does show the right direction: testable expectations belong before fast execution, not only at its end.
Context needs ownership and durability
Reactive systems become unmanageable when nobody owns context. Mozaik exposes a ModelContext as an ordered collection of messages, tool results and model outputs. It can be stored and restored in another session. An in-memory repository is sufficient for a prototype; a real service needs deliberate persistence, access control and retention rules.
Answer four questions before saving anything long-term:
- Which events are transient telemetry and which are decision evidence?
- Which agent may read, extend or summarise a context?
- How long are tool outputs, errors and user content retained?
- How can a later run see that context is stale, compacted or replaced by a newer source?
This is not bureaucracy. Without these answers, a later run cannot explain why an agent adopted a particular assumption. Persistence helps only when provenance and expiry travel with it.
Observability: not every event is a metric
An event bus makes activity easy to see, not automatically easy to understand. Teams need a small shared vocabulary for runs: correlation or run ID, participant, trigger, tool call, result, error class and final human decision. They also need hard limits for retries and time.
The most useful early metric is not the number of agents running in parallel. Ask instead: how many events actually needed a receiver? How many were discarded or condensed? How many retries produced a useful result? How often did a person need to intervene? If those figures rise, the problem is not necessarily a weak model; the event boundary may simply be too broad.
A language such as Flint can help turn well-formed data into chart specifications across different backends. The responsibility remains with the team: a handsome chart cannot repair poor event data. Only consistent timestamps, failure classes and state transitions make a chart a diagnostic instrument rather than decoration.
Where Mozaik is not the first choice
Mozaik is young and intentionally designed for a different style of collaboration. That is a reason for a controlled test, not an uncritical platform decision. A single document workflow, a fixed approval chain or a deterministic batch usually benefits more from a simple job runner, queue and explicit steps. Teams that first want AI assistance inside their existing process can start with GitHub Copilot or a bounded coding agent.
Even "self-healing" error handling needs limits. A retry can absorb a temporary failure; it must not amplify a bad instruction indefinitely. Every automatic retry needs a ceiling, an error class and escalation to a person. A runtime can enable that discipline, but it cannot invent it for the team.
A four-week pilot with real stop criteria
Week 1: measure one bottleneck. Pick recurring work where two roles really must respond to one another, such as an architecture check after a tool output. Define success as less waiting or better traceability, not more agents.
Week 2: write the event contract. Document trigger, payload, receiver, owner, retention and stop rule for every relevant event. Everything else stays outside the bus.
Week 3: integrate read-only. The pilot may analyse, compare and prepare a review draft. Repository, ticketing and production write access stay off.
Week 4: compare with the simple workflow. Compare time to a useful review, error rate, cost, number of human interventions and explainable runs. If Mozaik shows no clear advantage, that is a valid outcome, not a failed pilot.
Conclusion: reactive does not mean uncontrolled
Mozaik offers interesting building blocks for systems where agents do not merely work one after another but react to ongoing signals and shared context. Its strength is the explicit modelling of messages, context items and streaming events. Its limit begins when teams confuse that openness with autonomy.
The right start remains small: one event contract, bounded context, a read-only pilot and a human who approves the consequence. When a team can explain after four weeks which event changed which state and why, fast agent work has become dependable engineering work.