Framer AI AgentsDesign and publish professional sites with AI
Promoted
Mozaik
TypeScript runtime for concurrent AI agents
132 followers
TypeScript runtime for concurrent AI agents
132 followers
Mozaik enables agents to work independently and coordinate without blocking entire workflows.
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.
Dial
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.
Dial
@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.
Congrats on the launch. Self-organizing teams live or die on shared state design. We run a multi-agent system in production (Elixir GenServers, a similar concurrency model to what you are doing in TypeScript) and the pattern that saved us was a central coordinator owning durable memory that agents read and write through, rather than agents passing context peer to peer. It kills most duplicate work before it happens, and it gives you one place to audit why an agent decided anything. The event-reactive angle is the right call too, polling loops burn tokens doing nothing. Curious whether agent memory in Mozaik survives process restarts or lives and dies with the run.
Mozaik
@paul_crinigan Thank you a lot for the comment and for sharing your production experience. We are using Domain-Driven Design to tackle the complexity of agent collaboration.
At the moment, Mozaik provides ports for persisting participant context, so developers can store it in any infrastructure they choose: in-memory, files, a vector database, or another database. That means memory can survive process restarts if the developer connects a persistent implementation.
We are also experimenting with Mem0, but we have not integrated a default memory implementation yet. That is definitely something we plan to add.
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.