Launching today
Mozaik
TypeScript runtime for self-organizing AI agents
93 followers
TypeScript runtime for self-organizing AI agents
93 followers
Mozaik enables autonomous agent teams to work concurrently, react to events, communicate intelligently, and decide how collaboration should unfold during execution.
Letting the runtime decide collaboration instead of hardcoding a workflow graph is the interesting bet here — most agent frameworks make you draw the DAG up front. When agents self-organize at runtime, what stops two of them from looping or deadlocking on the same task, and is there an execution budget or supervisor that halts a run? And does the runtime state live in-process or in something external I can inspect and replay a run from?
Mozaik
@noctis06 That is exactly the challenge we are designing for. We plan to introduce a hierarchy flag so agents understand priority, authority, and who should resolve overlapping decisions, similar to how human teams work.
Agents are already fully asynchronous and non-blocking, so they can theoretically handle many concurrent processes. In practice, we still need to test extreme scenarios and define safeguards such as execution budgets, loop detection, and supervisor controls.
We run a lot of coding agents concurrently at my company and the thing I'd worry about here is cost, not just correctness. A fixed DAG means you can roughly predict how many LLM calls a workflow burns. Once agents are deciding at runtime whether and how to communicate, that overhead becomes a lot less predictable - a bad interaction pattern could quietly multiply your token spend without anyone noticing until the bill shows up. Is there any built-in visibility into inter-agent communication volume/cost, or is that left entirely to the developer to instrument themselves?
Mozaik
@galdayan Thank you a lot for this question. It helps us understand what is important for builders and what people are trying to achieve.
I completely understand your concern. We are exploring new possibilities, and for sure we will need to answer difficult questions around cost visibility and unpredictable communication overhead.
We are completely betting on agent autonomy, so we will probably explore concepts where agents are aware of the available budget and receive an additional layer of context about urgency, cost, and whether another interaction is worth it.
@miodrag_vilotijevic budget-aware agents is the right direction, but the part I'd want as a user is the visibility layer, not just the agents self-limiting. Even a per-run cost log I can inspect after the fact would let me trust the system without having to hope the agents made good calls in the moment. Curious if that's on the near-term roadmap or further out.
Mozaik
@galdayan I completely agree with you, and I think I get the distinction now: we cannot completely outsource everything to AI agents. Having humans in the loop, with clear visibility into what happened during a run, is an important part of building trust.
We are currently developing a concept we call Interception. It is intentionally abstract, giving users flexible ways to observe, inspect, pause, or control the system. A per-run cost and communication log fits naturally into that direction.
Mozaik being a TypeScript runtime for self-organizing AI agents makes me curious about the boundaries of the runtime. Is the main focus on agent coordination, task planning, memory/state, or giving developers a safer execution model for agents? Since it’s listed under Developer Tools and Engineering & Development, I’d be interested to know what a first integration looks like for an existing TS project.
Mozaik
@mia_qiao The main focus is agent coordination and the execution model around it. Mozaik gives TypeScript developers a runtime where agents are aware of each other, communicate through semantic events, and work asynchronously without a predefined workflow graph.
Planning, memory, and model providers can be plugged in, but Mozaik does not try to own the entire stack.
For an existing TypeScript project, the first integration is usually small: install the package, define a few agents as participants, connect them through a shared environment, and let them react to events using your existing tools and application logic.
Not having to draw the full graph up front makes sense.
One thing I'm not sure about though. When one agent fires an event and another one picks it up, how does the second agent know what the event actually means? Like is there some kind of schema they both agree on ahead of time, or is the LLM just reading the event name and figuring it out? Because I could see two agents both reacting to something called "data_ready" but one thinks it means raw data and the other thinks it's already cleaned.
Mozaik
@whetlan That is a great question. We built the runtime around the OpenResponses specification, where context is already structured into typed items such as UserMessageItem, ReasoningItem, FunctionCallItem, FunctionOutputItem, and ModelMessageItem.
Mozaik wraps those context items with the participant ID, so agents do not just receive an event name like data_ready. They receive structured context about who produced it, what they were doing, and the intention behind it. This gives other agents enough context to interpret the event more reliably instead of guessing from the name alone.
Pretty cool idea. How does it handle conflicts when two agents try to modify the same shared state?
Mozaik
@dhiraj_patel5 Another very good question - I’m taking note of problems like this.
Currently, Mozaik does not handle shared-state conflicts automatically, so developers need to implement that logic themselves. We will likely introduce concepts similar to mutexes or semaphores to coordinate access when multiple agents try to modify the same state.
A live visualizer showing each agent's current task, message queue, and decision rationale in real time would be huge. When something goes sideways, it is way easier to debug collaboration logic if you can see what each agent is thinking at the moment rather than digging through logs after the fact.
Mozaik
@cihanerany22p Yes, absolutely! We just need more time to develop this kind of feature, but we are definitely leaning in that direction. Real-time visibility into what each agent is doing, receiving, and deciding would make debugging autonomous agent teams much easier.
Self-organizing agents are interesting, but the practical test is whether a human can understand why work moved from one agent to another. I would make ownership, handoff reason, and stop conditions visible before optimizing for autonomy.
Mozaik
@krekeltronics Yes, over the next weeks and months we want to understand the right balance for humans: what needs to remain visible and controllable, and what can be left to agent autonomy.
We are modeling a concept called Interception, which gives users space to influence execution at important decision points. The idea is to let humans make high-level decisions without forcing them to micromanage every interaction between agents.
Control can also come from the runtime environment itself. For example, if you add a reviewer agent with the right tools, other agents can recognize when to delegate work to it.