Launching today
Mozaik
TypeScript runtime for self-organizing AI agents
70 followers
TypeScript runtime for self-organizing AI agents
70 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.
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.
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.
the agents actually talking to each other mid-task felt weirdly alive, like watching a small team figure things out on its own
Mozaik
@saniye0ike Exactly. We are not excluding agents from following a workflow and collaborating through it. Mozaik is simply a more abstract layer where the workflow does not have to be hardcoded manually and can emerge through agent communication at runtime.
Setup was fast and watching the agents hand off tasks without me prompting them felt surprisingly natural. The event-driven reactions remind me of having a small team that actually talks to each other.
Mozaik
@ufukamac8zz Yes, that was exactly our starting point: why shouldn’t agents behave more like humans?!