{"slug": "mozaik-hackathon-2026-build-concurrent-multi-agent-systems-and-compete-for-1000", "title": "Mozaik Hackathon 2026: Build Concurrent Multi-Agent Systems and Compete for $1,000 in Cash Prizes", "summary": "JigJoy, in partnership with daily.dev and Hyperskill, is hosting the Mozaik Hackathon 2026, a free online event focused on building concurrent multi-agent systems using the open-source TypeScript framework Mozaik. The hackathon, scheduled for September 5–6, 2026, offers $1,000 in cash prizes and aims to encourage developers to explore event-driven, reactive agent architectures beyond sequential workflows.", "body_md": "Building a **multi-agent system** sounds simple on a whiteboard. Give one agent a task, let another handle the next step, add a reviewer, connect a few tools, and you have an agentic workflow.\n\nIt gets more complicated when those agents need to operate at the same time.\n\nA sequential workflow can force agents into a fixed order: one finishes, another starts, and everyone downstream waits. That model is easy to reason about, but it can become restrictive as the system grows and agents need to react to new information independently.\n\n**Mozaik** takes a different architectural approach. It is an open-source TypeScript framework for building reactive agents inside an event-driven environment, where agents can work concurrently, respond to events, and coordinate without requiring a central workflow to define every interaction.\n\nAnd now there is a practical way to try this architecture.\n\n[JigJoy](https://jigjoy.ai/), together with [daily.dev](https://daily.dev/) and [Hyperskill](https://hyperskill.org?utm_source=jigjoy&utm_medium=devto&utm_campaign=jigjoy_hackathon), is organizing the **Mozaik Hackathon 2026**, a free online hackathon focused on building concurrent AI agents.\n\nBuilding more agents doesn't automatically make a multi-agent system better. The way those agents communicate, react, and depend on one another can have a bigger impact on how the system behaves as it grows.\n\n[Mozaik](https://mozaik.jigjoy.ai/) approaches this problem with an event-driven architecture designed around reactive, non-blocking agents. Agents join a shared `AgenticEnvironment`\n\n, receive events, and decide how to react to them.\n\nHere’s what makes the [Mozaik Hackathon 2026](https://build.jigjoy.ai/?ref=hadli) worth a look:\n\n`AgenticEnvironment`\n\n.`@mozaik-ai/core`\n\n.The hackathon takes place on **September 5–6, 2026**, with a livestream kickoff on September 4 and winners announced on September 13.\n\nIf you've been experimenting with AI agents, this is a chance to move past simple API orchestration and explore how concurrent multi-agent systems can be designed.\n\n`AgenticEnvironment`\n\n: A Shared Event-Driven LayerWhen developers first build a **multi-agent system**, a sequential workflow is often the easiest model to understand.\n\nImagine a research application with five specialized agents:\n\nThe workflow might look like this:\n\n```\nResearcher\n    ↓\nAnalyst\n    ↓\nCritic\n    ↓\nWriter\n    ↓\nReviewer\n```\n\nEach agent has a clear responsibility, and each stage can pass its output to the next one. For tasks where every step depends on the previous result, this approach makes sense.\n\nThe problem appears when agents **don't need to wait for each other**.\n\nSuppose the researcher finds three useful sources. The analyst could begin examining the first source while the researcher continues collecting information. A critic could inspect an early finding while the rest of the research is still underway. An observer could monitor the work continuously and react if something looks wrong.\n\nA fixed sequence makes those interactions harder to express because the workflow is built around **who runs next**, not around **which agent should react when something happens**.\n\nThat distinction is central to [Mozaik](https://mozaik.jigjoy.ai/).\n\n| Sequential multi-agent workflow | Mozaik's concurrent model |\n|---|---|\n| Agents follow an ordered execution path | Agents react to events as they arrive |\n| One stage commonly waits for another | Multiple agents can work concurrently |\n| Orchestration logic defines the workflow | Participants define their own reactions |\n| Adding an agent can require changes to the workflow | New participants can join the shared environment |\n| Long-running work can hold up downstream stages | Non-blocking inference allows other activity to continue |\n| Agents can become tightly connected to a specific workflow | Agents can operate more independently |\n\nThe goal isn't to make every AI workflow concurrent. Some tasks really have dependencies that require an order.\n\nMozaik is useful for the cases where multiple agents need to observe the same activity, react independently, and continue working while other agents are still processing.\n\nThat changes how you design the system.\n\nInstead of starting with a chain such as:\n\n```\nAgent A → Agent B → Agent C\n```\n\nyou can think about the system as a shared environment in which several participants respond to events:\n\n```\n                    ┌── Research Agent\n                    │\n                    ├── Planning Agent\n                    │\nEvent ──────────────┼── Coding Agent\n                    │\n                    ├── Review Agent\n                    │\n                    └── Observer\n```\n\nThe agents still have different responsibilities, but their relationship doesn't have to be encoded as one rigid pipeline.\n\nThis also affects **agent independence and reuse**. When an agent's behavior is based on the events it receives and the handlers it implements, that agent can be easier to move into another application or combine with a different set of participants.\n\nFor example, a review agent could be used to evaluate generated code in one application and research findings in another. The surrounding participants can change without requiring the reviewer to become part of a completely different orchestration chain.\n\nThat is an important part of Mozaik's approach: concurrency and interoperability are connected to the architecture itself.\n\nThe framework gives agents a shared environment where they can collaborate while allowing their individual behavior to remain separate.\n\nAnd that leads to the next question:\n\nhow does Mozaik make this possible under the hood?\n\nMozaik builds its **concurrent multi-agent architecture** around an `AgenticEnvironment`\n\n.\n\nThe environment is shared by humans, agents, observers, and tools. Each participant can emit events, while other participants can listen for the events relevant to their role and decide how to react.\n\nThose events can include plain-text messages, typed `ContextItem`\n\ns representing model interactions, and streaming `SemanticEvent<T>`\n\nchunks produced during inference.\n\nThe key architectural decision is that participants don't have to wait for a central scheduler to tell them what happens next.\n\nThey join the environment, register the handlers they care about, and react when relevant events arrive.\n\na name=\"agenticenvironment-a-shared-event-driven-layer\">\n\n`AgenticEnvironment`\n\n: A Shared Event-Driven Layer\nThe `AgenticEnvironment`\n\nacts as the communication layer between participants.\n\nA human can send a message into the environment. An agent can receive it through `onMessage()`\n\n. The agent can then start inference, which can produce reasoning, model messages, or function calls. Other participants can observe those events and decide whether they need to respond.\n\nThe flow looks more like this:\n\n```\nMessage\n   ↓\nAgent reacts\n   ↓\nrunInference()\n   ↓\nModel events\n   ├── Reasoning\n   ├── Function call\n   └── Model message\n          ↓\n    Other participants react\n```\n\nThere is no requirement that every participant complete its work before the environment can continue processing other events.\n\nThat matters because model inference is not instantaneous. A slow model call should not turn the entire multi-agent system into a waiting line.\n\nMozaik's `runInference()`\n\ncapability is designed to be non-blocking.\n\nA reactive agent can receive a message, add it to its `ModelContext`\n\n, and start inference:\n\n```\nasync onMessage(message: string): Promise<void> {\n  this.context.addContextItem(\n    UserMessageItem.create(message)\n  );\n\n  runInference({\n    model: \"gpt-5.5\",\n    context: this.context,\n    caller: this,\n    environment: this.environment\n  });\n}\n```\n\nThe important detail is what happens after `runInference()`\n\nis called: **the handler returns while the model continues running**.\n\nThe agent doesn't have to stay waiting for the inference result before the environment can handle other activity. The same participant can respond to another event, while other participants can continue processing their own events.\n\nWhen inference produces new `ContextItem`\n\ns, those items are sent back through the environment. The agent can react through handlers such as `onReasoning`\n\n, `onFunctionCall`\n\n, and `onModelMessage`\n\n, while other participants can observe corresponding external events.\n\nSo the underlying pattern becomes:\n\n```\nEvent\n  ↓\nReaction\n  ↓\nInference or tool call\n  ↓\nNew event\n  ↓\nAnother reaction\n```\n\nHere, Mozaik's **reactive agent architecture** differs from a workflow that simply executes one function after another. The system can keep responding as new information appears.\n\nMozaik also separates the participants from the overall application flow.\n\nThe base `BaseParticipant`\n\nclass provides the foundation for participants, while handlers such as `onMessage`\n\n, `onFunctionCall`\n\n, `onReasoning`\n\n, and `onModelMessage`\n\nallow each participant to implement only the behavior it needs.\n\nThat means a participant doesn't have to know the entire application.\n\nA planner can focus on planning.\n\nA researcher can focus on research.\n\nA critic can focus on evaluation.\n\nAn observer can monitor events.\n\nThey can all participate in the same `AgenticEnvironment`\n\nwithout requiring one central controller to contain every interaction between them.\n\nThis is also what makes the architecture useful for **reusable AI agents**. If an agent's behavior is defined around the events it understands and the actions it can perform, the same participant can potentially be introduced into another environment with a different combination of agents.\n\nAdding a critic, observer, or specialist can therefore become a matter of composing participants and defining their reactions, instead of redesigning one large workflow every time the system changes.\n\nFor developers building **AI agent orchestration systems**, that is a meaningful change in how the architecture can be structured: the environment provides the shared communication layer, while each participant owns its own behavior.\n\nAnd this is the kind of architecture the Mozaik Hackathon gives developers a chance to build themselves.\n\nMozaik is written in TypeScript and is available as the `@mozaik-ai/core`\n\npackage.\n\nFor a new project, installation starts with:\n\n```\nnpm install @mozaik-ai/core\n```\n\nYou can also install it with Yarn or pnpm:\n\n```\nyarn add @mozaik-ai/core\npnpm add @mozaik-ai/core\n```\n\nThe framework resolves the model provider from the model name passed to `runInference()`\n\n. Provider credentials are configured through environment variables, such as:\n\n```\nOPENAI_API_KEY=your-openai-key-here\nANTHROPIC_API_KEY=your-anthropic-key-here\nGEMINI_API_KEY=your-gemini-key-here\n```\n\nDeepSeek models can use the OpenAI-compatible chat-completions endpoint with `OPENAI_API_KEY`\n\nand `OPENAI_BASE_URL`\n\nconfigured for DeepSeek.\n\nFor TypeScript projects, Mozaik's documentation recommends a modern `moduleResolution`\n\nsetting, such as `bundler`\n\n, `node16`\n\n, or `nodenext`\n\nso package imports resolve cleanly.\n\nThe [Mozaik Hackathon](https://build.jigjoy.ai/?ref=hadli) is about giving developers the freedom to try out new things with AI agents that work together. It's a chance for them to build something real using Mozaik and see what they can create.\n\nIt is fully online and free to enter, and you do not need previous Mozaik experience.\n\nWhen you sign up, you get a bunch of helpful stuff like documents to read, a template to get started, and a quick intro to get you going before everything kicks off. Plus, the organizers will guide you through the process, so the weekend is not simply a contest where you are handed a framework and left alone with it.\n\nThe goal is also educational. You are expected to build something, but the process gives you a chance to understand what is happening underneath an AI agent system: how agents receive events, maintain context, call models and tools, react to outputs, and coordinate with other participants.\n\nThe hackathon is open to **developers anywhere in the world**.\n\nYou can enter on your own, and the organizers will help solo participants find teammates. You can also bring your own team. The website currently says that team-size limits will be announced soon.\n\nYou also do not need to arrive as a Mozaik expert. The event is designed to introduce the runtime to participants before the build weekend begins.\n\nThat makes the hackathon relevant to developers who already build AI applications as well as those who are just starting to explore **AI agents and multi-agent architecture**.\n\nThe main build happens over the weekend of **September 5–6, 2026**, but the event starts with an introduction on September 4 and ends with the winners' announcement on September 13.\n\nHere is the timeline currently provided by the organizers:\n\n| Date | Event | What happens |\n|---|---|---|\nSeptember 4, 2026 |\nLivestream kickoff | Introduction to Mozaik and the public release of the hackathon brief |\nSeptember 5–6, 2026 |\nBuild weekend | Participants build their concurrent multi-agent systems with Mozaik |\nSeptember 6, 2026 |\nSubmissions close | Submit your repository and short demo by the evening |\nSeptember 13, 2026 |\nWinners announced | The judging period ends and the winners are announced |\n\nYou do not need to travel anywhere, find a physical venue, or rearrange your weekend around an in-person event. You can build from wherever you are and communicate with the organizers and other participants through the event's online channels.\n\nOnce you understand the event-driven model, the interesting part starts: deciding what you want your multi-agent system to do.\n\nThe Mozaik Hackathon does not give developers a long list of predefined tracks. There is one open brief, and the core requirement is simple:\n\nbuild a working system where several agents run at the same time, share state, and coordinate with one another.\n\nThat leaves plenty of ideas for creativity.\n\nYou could build a research system where multiple agents investigate different parts of a problem simultaneously, with one agent checking the findings as they arrive. You could create a coding team where a planner, implementation agent, tester, and reviewer respond to changes as the project develops.\n\nYou could also go beyond familiar developer workflows. Think about customer-support agents that monitor conversations together, autonomous research teams that exchange findings, content systems where writers and fact-checkers react to new information, or monitoring agents that watch another agent's activity and step in when something needs attention.\n\nA project with five agents that only execute one after another won't demonstrate the concurrent-agent architecture as clearly. A smaller system with three agents that genuinely react to shared events and influence each other's work can demonstrate the architecture much better.\n\nThe best way to approach the project is to define these three things before writing the code:\n\n**What is the shared goal?**\n\nGive all participants a reason to collaborate.\n\n**What can each agent observe and react to?**\n\nThis is where Mozaik's event-driven model becomes important.\n\n**What happens when agents work at the same time?**\n\nYour architecture should make concurrency visible in the actual behavior of the application.\n\nThat last point matters because the hackathon is specifically looking for systems where concurrency is genuine, not a sequential pipeline presented as a multi-agent application.\n\nBuilding a multi-agent system from scratch forces you to understand things that can easily stay hidden when you work with higher-level abstractions.\n\nYou have to think about **agent state, events, context, model inference, tool calls, communication, reactions, and concurrency**. You start seeing an AI agent as an actual software component with inputs, behavior, state, and outputs.\n\nThat is exactly the kind of experience the Mozaik team wants participants to gain.\n\nHackathons are also useful because the learning does not happen in isolation.\n\nThe organizers plan to support participants through Discord, including announcements, team formation for people entering solo, and a place to ask questions throughout the weekend.\n\nIf you run into a problem with your architecture, need clarification about Mozaik, or simply want to discuss an approach with other builders, there is a shared space for it.\n\nAnd because the event is open-ended, you are not limited to reproducing one official demo. You get to make architectural decisions yourself and see what happens when you apply the concurrent-agent model to a problem you care about.\n\nThe hackathon offers **$1,000 in cash prizes**:\n\n| Place | Cash prize |\n|---|---|\n🥇 1st |\n$500 |\n🥈 2nd |\n$300 |\n🥉 3rd |\n$200 |\n\nThere are also additional prizes and discounts shown on the event page, including subscriptions from the event partners.\n\nBut for developers interested in AI engineering, the bigger prize is the opportunity to leave the weekend with a working **multi-agent application** and a clear understanding of how concurrent agents can be designed.\n\nThat is a useful project to have in your portfolio, especially as AI applications move beyond single-agent interactions toward systems where several specialized agents collaborate.\n\n[Register for the Mozaik Hackathon 🔥](https://build.jigjoy.ai/apply?ref=hadli)\n\n→ Mozaik is built around a concurrent, event-driven architecture where agents don't have to wait for one another in a fixed sequence. Agents can react to events independently, allowing multiple participants to work at the same time while remaining loosely coupled and reusable across different projects.\n\n→ No. The Mozaik hackathon is open to developers without prior Mozaik experience, and participants receive documentation, a starter template, and a primer before the event. The hackathon is also free and fully online, so you can participate without paying an entry fee or traveling.\n\n→ You'll build a working multi-agent system around an open brief, with the core requirement that multiple agents genuinely run concurrently and coordinate with one another. Possible directions include a research swarm, a self-reviewing codebase, a live operations room, or a system for parallel hypothesis testing.\n\n→ The Mozaik hackathon takes place online on September 5–6, 2026, and it is free to enter. The livestream kickoff is scheduled for September 4, while submissions close on the evening of September 6.\n\n→ The hackathon offers $1,000 in cash prizes: $500 for first place, $300 for second place, and $200 for third place. Additional prizes include daily.dev Plus subscriptions, Hyperskill Premium subscriptions, and Mozaik Cloud Premium subscriptions, while every participant receives discounts on Mozaik Cloud and Hyperskill Bootcamps.\n\nA lot of today's AI agent development still revolves around deciding what happens first, what happens next, and which agent receives the previous agent's output.\n\nThat approach works for many tasks. But as systems become more autonomous, there is another way to think about coordination:\n\n**Give agents an environment where they can observe events, react independently, and collaborate as the situation changes.**\n\nThat is the idea Mozaik is bringing to multi-agent development.\n\nIts event-driven architecture, non-blocking inference model, participant system, and shared environment give developers a foundation for experimenting with agents that can work concurrently without every interaction being hard-coded into one sequential workflow.\n\nThe Mozaik Hackathon is a chance to take that idea out of the documentation and build something with it.\n\nYou do not need to arrive with a finished architecture or years of multi-agent experience. You need a problem worth solving, a willingness to experiment, and an idea for how multiple agents can contribute to the same goal.\n\nIf you have been curious about what happens when AI agents can work together without waiting for each other at every step, September 5–6 is a good weekend to find out.\n\n| Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by\n|\n|\n|---|", "url": "https://wpnews.pro/news/mozaik-hackathon-2026-build-concurrent-multi-agent-systems-and-compete-for-1000", "canonical_source": "https://dev.to/hadil/mozaik-hackathon-2026-build-concurrent-multi-agent-systems-and-compete-for-1000-in-cash-prizes-5edn", "published_at": "2026-08-31 09:09:32+00:00", "updated_at": "2026-08-31 09:22:03.035226+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-startups"], "entities": ["JigJoy", "daily.dev", "Hyperskill", "Mozaik"], "alternates": {"html": "https://wpnews.pro/news/mozaik-hackathon-2026-build-concurrent-multi-agent-systems-and-compete-for-1000", "markdown": "https://wpnews.pro/news/mozaik-hackathon-2026-build-concurrent-multi-agent-systems-and-compete-for-1000.md", "text": "https://wpnews.pro/news/mozaik-hackathon-2026-build-concurrent-multi-agent-systems-and-compete-for-1000.txt", "jsonld": "https://wpnews.pro/news/mozaik-hackathon-2026-build-concurrent-multi-agent-systems-and-compete-for-1000.jsonld"}}