DEV Community: Miodrag Vilotijević

How LLM Context Works: Messages, Reasoning, and Tool Calls

Miodrag Vilotijević — Wed, 21 Oct 2026 09:12:13 +0000

Over the past week, I’ve been building the Agent Glossary, collecting fundamental terms that explain how LLMs work and how their capabilities relate to the context items they consume and produce.

Let’s walk through these terms one by one.

Model

A model is a trained AI system that generates content from the context it receives. In agent systems, it consumes context items, such as instructions, user messages, and tool outputs, and produces new items, such as model answers and tool calls.

Most modern language models use the Transformer architecture. Their capabilities determine which context items they can consume and produce, and how those items are delivered:

Tool calling enables the model to produce tool call items containing a function name and arguments.
Reasoning enables the model to work through a problem before producing an answer or tool call. Providers may expose reasoning items or summaries. Some models offer reasoning effort settings to control how much computation they spend reasoning.
Streaming delivers generated context items incrementally, before the entire response is complete.
Structured output constrains the content of a model answer to a defined schema, such as a JSON structure.

Model usage distinguishes input tokens, representing the context processed, from output tokens, representing the content generated, including reasoning tokens where applicable. Provider API pricing is mainly based on the number of input and output tokens used, usually with separate rates for each.

Context

Context is the information available to a model during a generation, including instructions, messages, tool interactions, and reasoning state.

Context is composed of context items: system prompt, user prompt, tool call, tool call output, reasoning, and assistant message.

Reasoning models spend additional computation generating intermediate reasoning before answering or calling tools, making them useful for complex planning, coding, mathematics, and decisions involving multiple constraints; this can increase latency and token usage. Reasoning-capable APIs can return Reasoning items, while non-reasoning models do not produce these dedicated items; their exact representation depends on the provider.

Context represents working memory, while agent memory provides long-term storage, including episodic memory of past experiences.

Context Items

Context items are the individual pieces of information that make up a model's context.

Each provider has its own representation of these context items.

Some model providers support streaming, delivering context items incrementally as they are generated instead of waiting for the complete response.

This allows applications to display text as it arrives or react to events before the full response is available.

Context Window

The context window is the maximum number of tokens a model can process during generation, including input and output.

A token is a unit of text or other data processed by the model—not necessarily a whole word.

Input tokens — Information provided to the model, including instructions, messages, and tool interactions.

Output tokens — Tokens generated by the model, including reasoning tokens where applicable.

Input and output must fit within the context window; models may also have a separate output limit.

When the limit is exceeded, the system may truncate context, removing information to make room, or reject the request. Losing earlier instructions or details can cause the model to repeat actions, miss requirements, or produce inconsistent answers.

Tool Call

A tool call or function call is a directive issued by a large language model to execute a function with specific arguments, to obtain information or perform an action.

The developer tells the model which functions it can request by providing tool definitions. Each definition describes the function's name, purpose, and parameters, including what each parameter means.

The model returns the function name, concrete arguments, and a call ID identifying the call.

The client executes the tool locally or remotely. In the next inference request, the developer provides the tool call output item alongside the matching call ID, so the model can connect the result to the original call and continue reasoning, request more tools, or provide a final answer.

The model may request multiple function calls in one response or across successive requests to complete a task.

Tool calls are a key step toward agent autonomy, allowing agents to request actions such as using a computer, browsing the internet, or executing other available functions as needed to complete a task.

User Prompt

A user prompt or user message is input provided to a model by a user or an application. It can contain instructions, questions, text, images, or other supported content.

For example: “Summarize this document in three sentences.”

The word prompt often refers to the user prompt, but it can also mean the broader input sent to the model, including system instructions and conversation history.

System Prompt

A system prompt is additional context that describes how the agent should behave.

Some providers split this into a developer message and a system message. Others include only a system message.

Reasoning

Reasoning is a capability of reasoning models to work through a problem before producing an answer or requesting a tool call. It helps with tasks that require multiple steps, such as planning, coding, and solving complex problems.

During generation, these models may produce reasoning items alongside other context items. They contain reasoning content related to how the model approaches a problem and arrives at an answer or tool call. They are not necessarily a complete or faithful explanation of the model's internal process.

Depending on the model and provider, returned reasoning content may be exposed directly, summarized, or hidden entirely.

Some models support reasoning effort, a setting that controls how much effort the model spends reasoning. Higher effort may improve results on difficult tasks, but can increase response time and token usage.

Assistant Message

An assistant message or model answer is a context item containing the model's final response to the user. It may provide a result, explain something, or ask for clarification.

The model can produce an answer directly or after requesting tool calls and processing their results. Depending on the model, the answer may contain text, images, audio, or other supported content.

The answer becomes part of the conversation context and can be included in future requests so the model knows what it previously communicated.

That’s all for now. Next, I’ll expand the collection with agent-related terms, including loops, harnesses, memory, and sub-agents, before exploring more advanced patterns for agent collaboration.

The Agent Glossary is available here: https://www.miodragvilotijevic.com/agent-glossary

Learn advance techniques for building AI systems during this weekend

Miodrag Vilotijević — Wed, 02 Sep 2026 22:36:53 +0000

This Saturday, we’re kicking off our hackathon for building concurrent AI agents with Mozaik.

Whether you’re an experienced developer interested in highly scalable AI systems or you’re just starting to explore multi-agent development, join us.

We’ll share the most important things we’ve learned while building a TypeScript runtime for concurrent AI agents, including:

Reasoning vs. non-reasoning models
How model context is structured
Advanced agent-loop engineering techniques
Event-driven coordination between agents
Building agents that work concurrently without blocking one another

Our main partners daily.dev and Hyperskill bring valuable prizes for hackathon winners.
.

📅 Online Hackathon — September 5–6

🏆 Cash prizes

🥇 $500
🥈 $300
🥉 $200

🎁 Subscriptions

10× annual daily.dev Plus subscriptions
5× six-month Hyperskill Premium subscriptions
5× six-month Mozaik Cloud Premium subscriptions

🎓 And everyone who takes part gets a discount on our AI Engineering Bootcamp + a discount on Mozaik Cloud.

Free · online · come solo or bring a team.

Join the hackathon:

NTP Novi Sad Hackathon — Build agents that work together | JigJoy × NTP Novi Sad

Two days at Science and Technology Park Novi Sad, or online, 30–31 October 2026. Bring a team, build a system of AI agents on Mozaik, submit it by Saturday. $1,000 in cash prizes. Free to enter.

build.jigjoy.ai

Join the hackathon: https://build.jigjoy.ai/

Miodrag Vilotijević — Wed, 02 Sep 2026 20:33:52 +0000

Shifts focus from sequential to event-driven AI

Hadil Ben Abdallah

Aug 31

Mozaik Hackathon 2026: Build Concurrent Multi-Agent Systems and Compete for $1,000 in Cash Prizes

#ai #hackathon #agents #buildinpublic

14 min read

NTP Novi Sad Hackathon — Build agents that work together | JigJoy × NTP Novi Sad

Two days at Science and Technology Park Novi Sad, or online, 30–31 October 2026. Bring a team, build a system of AI agents on Mozaik, submit it by Saturday. $1,000 in cash prizes. Free to enter.

build.jigjoy.ai

We’re running an online hackathon for building concurrent AI agents — Sep 5–6

Miodrag Vilotijević — Sun, 23 Aug 2026 21:41:47 +0000

We’re joining forces with daily.dev and Hyperskill to organize the Hackathon for Building Concurrent AI Agents - September 5–6, 2026. 🚀

Most multi-agent systems today are still built around sequential workflows: one agent does its part, waits, hands work to another, and the whole system moves step by step.

We believe the next generation of agentic software will be built differently.

That’s why we created Mozaik - JigJoy’s open-source TypeScript framework for building concurrent AI agents.

And now we want to see what developers can build with it.

Build systems where multiple autonomous agents operate concurrently, react to events, share state, and coordinate without being locked into a predefined sequence.

🏆 Prizes

$1,000 cash prize pool

1st — $500
2nd — $300
3rd — $200

10× annual daily.dev Plus subscriptions
5× six-month Hyperskill Premium subscriptions
5× six-month Mozaik Cloud Premium subscriptions

The hackathon is online, worldwide, and free to enter.

Join solo or with a team.

If you’re building with AI agents, come challenge the sequential workflow model and show us what concurrent agents can do.

Build agents that don’t wait each other.

👉 Register:

NTP Novi Sad Hackathon — Build agents that work together | JigJoy × NTP Novi Sad

Two days at Science and Technology Park Novi Sad, or online, 30–31 October 2026. Bring a team, build a system of AI agents on Mozaik, submit it by Saturday. $1,000 in cash prizes. Free to enter.

build.jigjoy.ai

How Two Builders Reached Nearly One Million Developers on dailydev

Miodrag Vilotijević — Sun, 02 Aug 2026 21:45:18 +0000

Over the last 45 days, our content reached 932,700 developers and generated 6.2 million impressions on dailydev.

It also received:

25,500 clicks
1,300 bookmarks
1,000 upvotes
220 comments
109 shares
11 awards
A 98% upvote ratio

These numbers are exciting, but what matters more is what they revealed about this community.

Developers are not looking for another basic AI tutorial
The strongest response did not come from articles explaining how to call an LLM API or build another simple chatbot.

Developers responded to stories about pushing technology to its limits—or using it in ways most people have not considered yet.

Our best-performing articles explored:

Running coding agents in extreme parallelism
Applying rigorous architecture, Extreme Programming, and Domain-Driven Design to agent orchestration
Generating 808 unit tests in a single session and covering an entire application
Using streaming to inspect and intercept an agent’s reasoning during runtime
Building autonomous communication where agents are aware of one another and decide when and with whom to communicate—without predefined workflows
The last one is my favorite.

It is difficult to imagine a future in which intelligent agents remain trapped inside rigid workflow graphs, unable to adapt when their environment changes.

The common thread across all these articles is clear:

Developers want to see extreme applications of AI agents and unconventional ways of using LLMs.

That is the direction we will continue exploring.

dailydev gives builders a real chance to be heard
What makes dailydev special is not only its reach. It is the kind of people behind that reach.

This is a community of early adopters, curious engineers, independent thinkers, and builders who genuinely want to understand what comes next.

dailydev enabled two people who are deeply passionate about technology and the act of building to reach hundreds of thousands of developers through nothing more than our work, ideas, and vision.

At one point, our small publication even appeared as the number-one trending source, alongside—and above—established names such as Hacker News and Fireship.

That is difficult to imagine on most platforms.

Large audiences are usually reserved for large brands, established media companies, or people who already have distribution. dailydev gives independent builders an opportunity to earn that attention through the quality and originality of their work.

The first community that understood us

dailydev was the first community that truly accepted what we are building—and, perhaps more importantly, who we are as builders.

Tutorial: How to Build CLI Agent

Miodrag Vilotijević — Wed, 20 May 2026 08:37:14 +0000

Miodrag Vilotijević for JigJoy

May 19

Build Your Own CLI Agent: A Step-by-Step Guide

#typescript #ai #cli #mozaik

7 min read

Build Your Own CLI Agent: A Step-by-Step Guide

Miodrag Vilotijević — Tue, 19 May 2026 16:24:01 +0000

I love JavaScript. Even though I have learned several languages, JavaScript has become my first choice when building new projects. In this post I'll walk through a small terminal chat app where a language model can run shell commands for you — something you can actually run locally. At the end there's a GitHub template if you'd rather clone than copy.

Two libraries do most of the heavy lifting:

Ink draws the chat in the terminal — the input box, scrolling text, and key handling — using React so you are not building a TUI from scratch.
Mozaik connects the model, tool calls, and conversation memory. Think of it as the wiring between "the model said something," "a tool finished," and "show that in the UI," so your screen code does not have to know every detail of the API.

Ink is what the user sees; Mozaik is what coordinates the agent behind the scenes.

What we are building

One Node command that:

Shows a simple chat UI in the terminal.
Forwards what you type to a hosted language model.
Lets the model run terminal commands through a single tool (run_command) when it needs to inspect the machine or run a build.
Prints the model's replies (and optional "calling a tool…" hints) in that same UI — without pushing API calls into every component.

The goal is a clean split: the terminal view stays simple; the agent and tools stay in one place and are easier to test or swap later.

How the pieces fit together

Mozaik runs everything on a shared AgenticEnvironment: when the model speaks, asks for a tool, or a tool returns a result, every piece that has joined that environment can hear about it. For this CLI you mainly care about two kinds of participant:

Role	Typical base class	Responsibility
Agent	`BaseAgentParticipant`	Remembers the conversation, asks the model for the next step, and runs tools (like `run_command`) when the model asks for them.
Observer / UI bridge	`BaseObserverParticipant`	Listens for assistant text and tool activity from the agent and forwards it into Ink through small callbacks — so the screen updates when the model speaks or starts a tool, without owning the agent loop.

In this project, typing in Ink calls session.send, which hands your text to the agent. You could add other participant types later (for example streaming stdin), but a straight send-to-agent path keeps the tutorial easy to follow.

┌─────────────┐     session.send()      ┌──────────────────┐
│  Ink (app)  │ ──────────────────────► │  TerminalAgent   │
└─────────────┘                         │  (agent loop)    │
       ▲                                └────────┬─────────┘
       │ callbacks                            │ join()
       │                                        ▼
┌─────────────┐                         ┌──────────────────┐
│  UIUpdater  │ ◄── onExternal* ─────── │ AgenticEnvironment│
│  (observer) │                         └──────────────────┘
└─────────────┘

Step 1 — Bootstrap the runtime (`cli.tsx`)

The entry file is intentionally tiny: load environment variables, maybe print a one-line usage hint, then hand off to Ink with render(<App />). Keep agent logic out of here — only bootstrapping.

#!/usr/bin/env node
import React from "react";
import { render } from "ink";
import meow from "meow";
import dotenv from "dotenv";
import path from "node:path";
import { fileURLToPath } from "node:url";
import App from "./app.js";

const here = path.dirname(fileURLToPath(import.meta.url));
dotenv.config({
  quiet: true,
  path: [
    path.resolve(process.cwd(), ".env"),
    path.resolve(here, "..", "..", ".env"),
    path.resolve(here, "..", "..", "..", ".env"),
  ],
});

meow(
  `
    Usage
      $ your-cli

    Starts an interactive chat with the agent.
`,
  { importMeta: import.meta },
);

render(<App />);

Step 2 — Compose the session (`session.ts`)

This file is the "control room." You create the model, the conversation memory, the thing that runs tools, and the shared environment, then plug in your agent and your UI helper. Everything with awkward names (OpenAIInferenceRunner, ModelContext, and so on) lives here so the React side stays small. When you are done, the UI only needs one method: send(message), forwarded to the agent's onMessage.

import {
  AgenticEnvironment,
  Gpt54,
  ModelContext,
  OpenAIInferenceRunner,
  DefaultFunctionCallRunner,
} from "@mozaik-ai/core";
import { terminalTools } from "./terminal/tools.js";
import { TerminalAgent } from "./terminal/agent.js";
import { UIUpdater } from "./ui-updater.js";

export type AgentSession = {
  send: (message: string) => void;
};

export type AgentListeners = {
  onAssistantText: (text: string) => void;
  onFunctionCall?: (name: string) => void;
};

export function createAgentSession(listeners: AgentListeners): AgentSession {
  const functionCallRunner = new DefaultFunctionCallRunner([...terminalTools]);
  const inferenceRunner = new OpenAIInferenceRunner();

  const context = ModelContext.create("cli-agent");
  const model = new Gpt54();
  model.setTools([...terminalTools]);

  const environment = new AgenticEnvironment();
  const agent = new TerminalAgent(
    inferenceRunner,
    functionCallRunner,
    environment,
    context,
    model,
  );
  const uiUpdater = new UIUpdater(listeners);

  agent.join(environment);
  uiUpdater.join(environment);
  environment.start();

  return {
    send: (message: string) => agent.onMessage(message),
  };
}

Step 3 — The agent loop (`terminal/agent.ts`)

This is the heart of the app. When someone sends a message, you record it, let the model think, and if it wants to run a tool you run it and feed the result back — then the model gets another turn until it answers in plain language.

In practice:

On new user text → add to conversation and ask for the next model response.
When the model asks for a tool → remember the call is in flight, run it, store the outcome.
When every outstanding tool has finished → ask the model again so it can either reply or request another step.

There is no Ink or terminal drawing in this file — only memory and orchestration — so you can change the UI later without touching the agent.

import {
  BaseAgentParticipant,
  UserMessageItem,
  FunctionCallItem,
  AgenticEnvironment,
  ModelContext,
  GenerativeModel,
  InputStream,
  InferenceRunner,
  FunctionCallRunner,
  FunctionCallOutputItem,
  DeveloperMessageItem,
} from "@mozaik-ai/core";

const programmaticAgentInputStub: InputStream = {
  async *stream() {},
};

export class TerminalAgent extends BaseAgentParticipant {
  private pendingCalls = new Set<string>();

  constructor(
    inferenceRunner: InferenceRunner,
    functionCallRunner: FunctionCallRunner,
    private readonly environment: AgenticEnvironment,
    private readonly context: ModelContext,
    private readonly model: GenerativeModel,
  ) {
    super(programmaticAgentInputStub, inferenceRunner, functionCallRunner);
  }

  override onMessage(message: string): void {
    const developerMessage = DeveloperMessageItem.create(
      `You are a terminal agent. You can run commands in the terminal to help the user with their request.`,
    );

    this.context
      .addContextItem(developerMessage)
      .addContextItem(UserMessageItem.create(message));
    this.runInference(this.environment, this.context, this.model);
  }

  override onFunctionCall(item: FunctionCallItem) {
    this.pendingCalls.add(item.callId);
    this.context.addContextItem(item);
    this.executeFunctionCall(this.environment, item);
  }

  override onFunctionCallOutput(item: FunctionCallOutputItem) {
    this.context.addContextItem(item);
    this.pendingCalls.delete(item.callId);
    if (this.pendingCalls.size === 0) {
      this.runInference(this.environment, this.context, this.model);
    }
  }
}

Step 4 — Tools the model can use (`terminal/tools.ts`)

Tools are how you tell the model what it is allowed to do outside of chat text. Each tool has a name, a short description the model can read, argument shapes, and an invoke function that runs on your machine.

Here we expose one tool: run_command, which executes a shell command and returns output so the model can use it on its next turn.

import { Tool } from "@mozaik-ai/core";
import { Terminal } from "./terminal.js";

const terminal = new Terminal();

export const terminalTools: Tool[] = [
  {
    name: "run_command",
    description: "Run a command in the terminal.",
    parameters: {
      type: "object",
      properties: {
        command: {
          type: "string",
          description: "The command to run in the terminal.",
        },
        cwd: { type: "string", description: "The current working directory." },
      },
      required: ["command", "cwd"],
    },
    strict: true,
    type: "function",
    invoke: async (args: { command: string; cwd: string }) => {
      const result = await terminal.runCommand(args.command, args.cwd);
      return result;
    },
  },
];

Step 5 — Feed the terminal UI (`ui-updater.ts`)

The observer sits between Mozaik and Ink. When the agent produces text the user should see, this class forwards it through a callback; when a tool starts, it can add a small status line (for example "calling run_command").

You stay subscribed to external events so you hear what the agent is doing, not duplicate the agent's own work — one clear owner of the loop and one clear owner of the display.

import {
  Participant,
  FunctionCallItem,
  ModelMessageItem,
  BaseObserverParticipant,
} from "@mozaik-ai/core";

type Listeners = {
  onAssistantText: (text: string) => void;
  onFunctionCall?: (name: string) => void;
};

export class UIUpdater extends BaseObserverParticipant {
  constructor(private readonly listeners: Listeners) {
    super();
  }

  override onFunctionCall(item: FunctionCallItem) {
    this.listeners.onFunctionCall?.(item.toJSON()?.name ?? "tool");
  }

  override onExternalFunctionCall(
    _source: Participant,
    item: FunctionCallItem,
  ) {
    this.listeners.onFunctionCall?.(item.toJSON()?.name ?? "tool");
  }

  override onExternalModelMessage(_source: Participant, item: ModelMessageItem) {
    const text = item.content?.text ?? "";
    if (text) this.listeners.onAssistantText(text);
  }
}

Step 6 — Wire Ink (`app.tsx`)

The Ink layer holds chat history in normal React state, builds the session once so you do not reconnect on every render, and on submit appends the user message then calls session.send. Anything the observer hears arrives through the callbacks you passed in when creating the session.

import React, { useMemo, useRef, useState } from "react";
import { useApp } from "ink";
import { createAgentSession } from "./session.js";

type ChatMessage = {
  id: number;
  role: "user" | "assistant" | "system";
  content: string;
};

export default function App() {
  const { exit } = useApp();
  const [messages, setMessages] = useState<ChatMessage[]>([]);
  const nextId = useRef(0);

  const appendMessage = (role: ChatMessage["role"], content: string) => {
    setMessages((previous) => [
      ...previous,
      { id: nextId.current++, role, content },
    ]);
  };

  const session = useMemo(
    () =>
      createAgentSession({
        onAssistantText: (text: string) => {
          appendMessage("assistant", text);
        },
        onFunctionCall: (name: string) => {
          appendMessage("system", `calling tool: ${name}`);
        },
      }),
    [],
  );

  const handleSubmit = (value: string) => {
    const trimmed = value.trim();
    if (!trimmed) return;
    appendMessage("user", trimmed);
    session.send(trimmed);
  };

  // …render messages + <TextInput onSubmit={handleSubmit} /> …
}

Step 7 — Credentials and build

Put your API key in .env (the template expects OPENAI_API_KEY; check Mozaik if you change model or provider). Then install, build, and run the compiled CLI (or npm link if you want a global command).

cp .env.example .env
# add OPENAI_API_KEY=sk-...

npm install
npm run build
npm start

Starter repository

Prefer a working tree over copy-paste? There is a template repo with the same layout this article walks through — agent, observer, tools, and Ink UI already split into files.

Scaffold a fresh project without copying the template's full git history:

npx degit jigjoy-ai/cli-agent-starter my-cli-agent
cd my-cli-agent
git init
git add .
git commit -m "Initial commit"
npm install

Replace jigjoy-ai/cli-agent-starter with your fork or canonical URL if it moves; replace my-cli-agent with your package name. Then edit package.json (name, bin), tweak source/cli.tsx / source/app.tsx branding, and start adding participants and tools.

GitHub alternative: enable Template repository in the repo settings and use Use this template — you get a first commit snapshot with a clean history for a new repo.

Starter template: github.com/jigjoy-ai/cli-agent-starter

Where to go next

Add BaseHumanParticipant if you want stdin streaming as first-class InputStream input.
Add a second BaseAgentParticipant and use onExternal* handlers to log or aggregate multi-agent chatter.
Swap Gpt54 / runners for other models supported by Mozaik as the ecosystem grows.

You now have a concise path from "blank Node project" to Ink front end + Mozaik event bus + tool-running agent — with a degit-friendly repo to hit the ground running.

Learn more

Mozaik: github.com/jigjoy-ai/mozaik

Read the full article on JigJoy: jigjoy.ai/blog/build-your-own-cli-agent

Reactive Agents, Typed Event Handlers, and Agent Swarms: What's New in Mozaik

Miodrag Vilotijević — Tue, 19 May 2026 13:31:10 +0000

When we released Mozaik v3, we introduced an event-based architecture where participants emit, observe, and react to typed context items inside a shared agentic environment. Since then, the framework has kept moving — and the way we think and talk about it has moved with it.

This post is a tour of what's new. The headline shift is conceptual: Mozaik is now framed around reactive agents — collaborative agents that adapt to their environment and to each other in real time. Underneath that frame, the API has gotten smaller, clearer, and easier to read.

From Non-Blocking to Reactive

Mozaik agents have always been non-blocking. That's still true — capability methods stream events as they're produced, so a slow inference or tool call never holds up other participants. But "non-blocking" describes a property, not a way of thinking.

The way we now think about Mozaik agents is reactive: an agent declares which events it cares about and reacts to them as they arrive — messages from humans, function calls from its own model, reasoning traces from a peer agent, or tool outputs from somewhere else in the environment. Behavior emerges from how agents react, not from a central controller deciding whose turn it is.

A reactive agent is event-driven, collaborative, and adapts to its environment and to other agents in real time.

This shift in framing pays off in design. Once an agent is a thing that reacts, adding behavior to a system stops being about editing a pipeline and becomes about joining another participant.

Typed Event Handlers

The biggest API change since 3.0 is on the participant side. In the original release, a participant exposed a single intercept point: onContextItem(source, item). You looked at the item, decided whether it came from you or someone else, and branched accordingly.

That worked, but it pushed a lot of dispatch logic into every agent. So we replaced the single intercept with a set of typed handlers, one per event kind:

onMessage
onFunctionCall
onFunctionCallOutput
onReasoning
onModelMessage

Each handler defaults to a no-op in the base class, so a reactive agent only writes the ones it actually cares about. The result is shorter, more declarative code — a reactive agent reads like a list of "when this happens, I do that," not like a switch statement.

Here is a full reactive agent built on top of BaseAgentParticipant. It records incoming messages, runs inference, executes its own tool calls, and keeps its local context in sync with what the model produces — all by overriding the handlers it cares about:

// reactive-agent.ts
import {
  BaseAgentParticipant,
  UserMessageItem,
  FunctionCallItem,
  FunctionCallOutputItem,
  ReasoningItem,
  ModelMessageItem,
  AgenticEnvironment,
  ModelContext,
  GenerativeModel,
  InputStream,
  InferenceRunner,
  FunctionCallRunner,
} from "@mozaik-ai/core"

export class ReactiveAgent extends BaseAgentParticipant {
  constructor(
    inputSource: InputStream,
    inferenceRunner: InferenceRunner,
    functionCallRunner: FunctionCallRunner,
    private readonly environment: AgenticEnvironment,
    private readonly context: ModelContext,
    private readonly model: GenerativeModel,
  ) {
    super(inputSource, inferenceRunner, functionCallRunner)
  }

  // A message from a human (or any other participant) — record it and think.
  async onMessage(message: string): Promise<void> {
    this.context.addContextItem(UserMessageItem.create(message))
    this.runInference(this.environment, this.context, this.model)
  }

  // The agent just produced a function call — execute it.
  async onFunctionCall(item: FunctionCallItem): Promise<void> {
    this.context.addContextItem(item)
    this.executeFunctionCall(this.environment, item)
  }

  // The tool just produced an output — feed it back and run inference again.
  async onFunctionCallOutput(item: FunctionCallOutputItem): Promise<void> {
    this.context.addContextItem(item)
    this.runInference(this.environment, this.context, this.model)
  }

  // Keep the local context in sync with model-emitted reasoning and replies.
  async onReasoning(item: ReasoningItem): Promise<void> {
    this.context.addContextItem(item)
  }

  async onModelMessage(item: ModelMessageItem): Promise<void> {
    this.context.addContextItem(item)
  }
}

For comparison, the old style looked like this:

// Before: one handler, manual dispatch
async onContextItem(source: Participant, item: ContextItem): Promise<void> {
  if (source === this) return

  this.context.addContextItem(item)

  if (item instanceof UserMessageItem) {
    this.runInference(this.environment, this.context, this.model)
    return
  }

  if (item instanceof FunctionCallItem) {
    this.executeFunctionCall(this.environment, item)
    return
  }
}

The Self vs. External Split

For every typed handler, there are two variants: a self handler that fires when this participant emits the event, and an external handler (prefixed with onExternal) that fires when another participant emits it.

Self (your emissions)	External (everyone else)
`onFunctionCall`	`onExternalFunctionCall`
`onFunctionCallOutput`	`onExternalFunctionCallOutput`
`onReasoning`	`onExternalReasoning`
`onModelMessage`	`onExternalModelMessage`

The practical effect: a reactive agent can encode "act on my own outputs" separately from "observe others" — no more manual source === this checks.

Want to build a critic that reviews a peer agent's answers? Override onExternalModelMessage.
Want to feed your model's own tool calls back into a runner? Override onFunctionCall.

The two concerns stop bleeding into each other.

As a concrete example, here is a passive participant that only listens to external events. It does not run inference and does not execute tools — it just watches what other participants emit and logs it. Drop it into any environment and you have a live transcript:

// transcript-logger.ts
import {
  Participant,
  FunctionCallItem,
  FunctionCallOutputItem,
  ReasoningItem,
  ModelMessageItem,
} from "@mozaik-ai/core"

export class TranscriptLogger extends Participant {
  async onMessage(message: string): Promise<void> {
    console.log("[message]", message)
  }

  async onExternalFunctionCall(
    source: Participant,
    item: FunctionCallItem,
  ): Promise<void> {
    console.log(`[${source.constructor.name}] function_call`, item.toJSON())
  }

  async onExternalFunctionCallOutput(
    source: Participant,
    item: FunctionCallOutputItem,
  ): Promise<void> {
    console.log(
      `[${source.constructor.name}] function_call_output`,
      item.toJSON(),
    )
  }

  async onExternalReasoning(
    source: Participant,
    item: ReasoningItem,
  ): Promise<void> {
    console.log(`[${source.constructor.name}] reasoning`, item.toJSON())
  }

  async onExternalModelMessage(
    source: Participant,
    item: ModelMessageItem,
  ): Promise<void> {
    console.log(`[${source.constructor.name}] model_message`, item.toJSON())
  }
}

Plain Messages on the Bus

Conversational text used to flow through the same context-item pipeline as everything else. It worked, but it was heavier than it needed to be. Now there are two clean lanes:

Messages — plain strings, delivered via onMessage(message: string). Use them for what a human types, what one agent says to another, and any other free-form text.
ContextItems — typed model internals (function calls, function call outputs, reasoning items, model messages), delivered via their dedicated handlers.

The participant side mirrors this: the old InputItemSource has become InputStream, an async iterable of strings. Each yielded string fans out via onMessage to every other participant. Inference and tool runners still produce typed ContextItems, exactly as before.

The benefit is mostly clarity. When you read a reactive agent now, you can tell at a glance whether a handler is reacting to "someone said something" or to "the model produced a tool call."

import { InputStream } from "@mozaik-ai/core"

// Async iterable of plain strings — each yield becomes onMessage for peers.
async function* humanInput(): InputStream {
  yield "Add rate limiting to all API endpoints"
  yield "Focus on the NestJS backend first"
}

A Bigger Model Lineup

The default OpenAI provider now ships a wider model lineup. In addition to Gpt54, Gpt54Mini, and Gpt54Nano, there is now Gpt55. Same OpenAIResponses runtime, same OpenResponses-aligned types — pick the model that fits the job.

import { Gpt55, Gpt54Mini } from "@mozaik-ai/core"

// Heavier reasoning for planning; lighter model for review passes.
const planner = new Gpt55()
const reviewer = new Gpt54Mini()

From One Agent to a Swarm

The reactive frame really earns its keep when more than one agent shares an environment. We've started calling these collaborative groups agent swarms: a handful of focused reactive agents — planner, executors, reviewer, and observers — all joining one AgenticEnvironment and reacting to each other's events.

Agent swarms — multiple reactive agents collaborating in one agentic environment

The clearest production example is baro, a Claude agent orchestrator built on Mozaik. Ten specialized participants — planner, executors, reviewer, fixer, librarian, auditor, and more — work fully concurrently on the same goal, like a team collaborating in real time instead of a single agent doing everything alone.

Adding a new role to a swarm doesn't mean editing a central controller. It means writing one more reactive agent and join()ing it to the environment. Everything else keeps working.

import { AgenticEnvironment } from "@mozaik-ai/core"

const environment = new AgenticEnvironment()

planner.join(environment)
executor.join(environment)
critic.join(environment)
new TranscriptLogger().join(environment)

environment.start()

Composing Intelligence

Each of these changes is small on its own. Together, they shift Mozaik further toward what we wanted from the start: a framework where intelligent behavior is something you compose, not something you orchestrate.

Change	What it unlocks
Reactive agents	Behavior from event handlers, not a central `run()` loop
Typed handlers	Readable "when X, do Y" agents without dispatch boilerplate
Self vs. external	Critics, observers, and actors coexist without `source === this`
Plain messages	Conversational text separate from model-internal ContextItems
Agent swarms	Many focused agents on one bus — see baro

Reactive agents make the building block explicit. Typed handlers make each agent easier to read. The self vs. external split keeps intent obvious. Plain messages keep the conversational lane clean. And the swarm pattern shows what falls out the other side: groups of agents that adapt to their environment and to each other in real time.

Get started

npm install @mozaik-ai/core

Star on GitHub: github.com/jigjoy-ai/mozaik

Read the full article on JigJoy: jigjoy.ai/blog/mozaik-reactive-agents

A different way to orchestrate AI agents - worth a read.

Miodrag Vilotijević — Thu, 14 May 2026 20:56:06 +0000

Miodrag Vilotijević for JigJoy

May 5

Structured Context, Context Memory, Context Item Generators, and the Agentic Environment

#ai #agents #typescript #javascript

3 min read

Structured Context, Context Memory, Context Item Generators, and the Agentic Environment

Miodrag Vilotijević — Tue, 05 May 2026 14:43:29 +0000

Mozaik started as a multi-provider library. With version 3.0.0, we are evolving it into a full TypeScript framework for building non-blocking AI agents.

This release introduces an event-based architecture designed around inversion of control. Instead of forcing developers into rigid, sequential pipelines, Mozaik enables humans, agents, observers, and tools to collaborate inside a shared agentic environment. Participants can emit, observe, and react to typed context items in real time, making multi-agent orchestration more flexible, composable, and concurrent.

Structured Context

Mozaik 3 introduces a structured, multi-provider context model compatible with the OpenResponses specification.

Instead of treating prompts as plain strings, Mozaik models context as typed items, including:

SystemMessageItem
DeveloperMessageItem
UserMessageItem
FunctionCallItem
FunctionCallOutputItem
ReasoningItem
ModelMessageItem

These context items help developers provide clearer, more precise instructions to language models. For example, combining system, developer, and user messages gives the model a better-organized context than placing everything into a single user message.

This structure also makes model interactions easier to inspect, store, replay, and adapt across providers.

Context Memory

Mozaik now models context as an aggregate of ordered context items through ModelContext.

This gives developers a structured foundation for both short-term working memory and long-term persistence. The framework includes a repository interface, allowing context to be saved and retrieved through different storage backends.

Mozaik provides an in-memory implementation for working memory, while developers can implement their own repositories for file systems, databases, or other persistence layers.

This approach keeps memory explicit, portable, and provider-independent.

Context Item Generators

Mozaik 3 introduces asynchronous context item generators for key parts of the framework, including input handling, inference, and function call execution.

Instead of relying on blocking await chains, runners can produce context items over time through async iterables. This enables items to be generated and delivered in real time while giving developers control over when and how those streams are consumed.

Mozaik provides default implementations for function call execution and OpenAI inference. Developers can also create their own implementations, which is especially useful for testing, mocking runners, customizing tool execution, or adding support for additional model providers.

Agentic Environment

The main goal of Mozaik 3 is to enable AI agents to collaborate in a non-blocking way.

We believe that truly agentic systems should not be limited to sequential chains. In many real-world use cases, agents need to observe, react, and contribute concurrently.

To support this, Mozaik introduces the Participant abstraction and the AgenticEnvironment.

Participants join the same environment and react to typed context items as they arrive.

Participants, including humans and agents, join the same environment and subscribe to context items generated by other participants. When one participant emits a context item, other participants can observe it, react to it, ignore it, or use it to update their own internal context.

or example, a human can send a UserMessageItem into the environment. One or more agents can react by running inference, producing model messages, requesting function calls, or incorporating the new item into their own context. Other agents can observe those outputs and respond with their own contributions.

This enables agents to work in parallel and remain aware of what other participants are doing during inference.

Default Participants

To make multi-agent development faster, Mozaik 3 also includes default participant implementations:

BaseAgentParticipant
BaseHumanParticipant

These base classes provide common capabilities for generating, receiving, and reacting to context items, so developers can set up multi-agent systems with less boilerplate while still keeping full control over the architecture.

A Foundation for Multi-Agent Systems

Mozaik 3 moves beyond simple provider abstraction.

It introduces a framework-level architecture for building reactive, non-blocking, context-aware AI systems. By combining structured context, explicit memory, async context item generation, and a shared agentic environment, Mozaik gives developers the building blocks for more flexible and scalable multi-agent applications.

With version 3.0.0, Mozaik becomes a foundation for building agents that do not just run in sequence, but collaborate through shared context in real time.

Star on GitHub: https://github.com/jigjoy-ai/mozaik

My Story of Building a TypeScript Framework for Event-Driven AI Agents

Miodrag Vilotijević — Thu, 30 Apr 2026 08:11:58 +0000

While working on agentic systems my co-founder early on detected the core limitation of agentic systems. They are doing this sequentially, so AI agent need to wait other agent to start the work. And they are blocking in nature - if you are building agentic system you probably know that almost any SDK or library has agents with blocking run method (await).

So we decided to start addressing this problem and open up new possibilities - if we manage to make agents act more like humans: work autonomously, in parallel, interrupt, react to others and environment.

For me it was hard to structure this agent communication. At first it was hard to detect from where to start - but after days of reading white papers, documentation of LLM providers I found the clue.

It was OpenResponses documentation by OpenAI, Vercel, OpenRouter, Hugging Face - they unite to specify unified structure of context.

They describe all context items in depth - I will cover just the basic idea:

DeveloperMessage
SystemMessage
UserMessage
Reasoning
FunctionCall
FunctionCallOutput
ModelMessage

All those items are streamable using semantic events.

That was starting point for my framework.

Only after that I realized I need stronger foundation.

I started with building multi-provider library - but in order to go further and to decouple infrastructure for my code library I needed to create higher degree of abstraction than just mapping request to LLM providers.

So I turned this specification into objects - enabling easy population of context, persistence, and streaming.

Now I wanted to create interceptor while those context items generate in real-time.

My second decision was to model agent loop as state machine with following states:

user message received
inference pending
function call pending
model message received

Switching states based on probability of LLM response. I added hooks for each state so developers can write logic to control loop:

onUserMessage
beforeInference
afterInference
beforeFunctionCall
afterFunctionCall
onModelMessage

It was good progress - but it was still modeling runtime of a single agent.

After that I realized - to structure agent communication they probably need to share context items and semantic events. That was a mini insight I discovered down the road. But I soon realized that agent loop is just one concrete implementation of agent workflow with automated switching from one state to another.

I needed more abstract solution - where developers can write logic to control the agent’s stream of context items that are generating in real time.

So I removed agent loop abstraction. And came up with new idea. I will make agents and humans abstract - and model environment where they operate together. Participants subscribe to environment for listening context items. Every time new context item arrives - each participant will be notified so they can react on other participants work.

Also I introduced generators for:

FunctionCallRunner
InferenceRunner
InputStream

Participants need to provide those generators during initialization.

That was important decision - because with abstract generators which are isolated from communication we can easily mock LLM calls and test framework even before we send any real request.

And voilà - we created environment where agents can naturally connect and react on the stream of context items they are producing. Not sequential. Not blocking. But event-driven. More like how humans actually work.

That’s my story of building a TypeScript framework. I am excited to see what possibilities and challenges will emerge when using multiple agents at once.

Check it out:

jigjoy-ai / mozaik

Mozaik is a TypeScript runtime for building and sharing AI agents.

Mozaik

Mozaik is a TypeScript runtime for interoperable AI agents.

Agent Interoperability

Our main goal is to unlock agent interoperability across projects, so Mozaik is built around three core attributes:

Concurrency - Agents work independently without blocking one another.
Awareness - Agents understand other participants, events, and their shared environment.
Adaptivity - Agents change their behavior based on runtime state and emerging needs.

Together, these capabilities free AI agents from specific harnesses, allowing them to work across projects - so every newly created agent adds value to the entire ecosystem.

Installation

npm

npm install @mozaik-ai/core

yarn

yarn add @mozaik-ai/core

pnpm

pnpm add @mozaik-ai/core

API Key Configuration

Mozaik picks a provider from the model name you pass to runInference, and each provider's SDK reads its credential from the environment. Set the keys for the providers you use:

# .env
OPENAI_API_KEY=your-openai-key-here
ANTHROPIC_API_KEY=your-anthropic-key-here
GEMINI_API_KEY=your-gemini-key-here

DeepSeek models…

View on GitHub

I mapped the OpenResponses specification into domain objects to make context, context items, and streaming events explicit and usable across multiple providers - check it out.

Miodrag Vilotijević — Fri, 17 Apr 2026 08:38:28 +0000

Miodrag Vilotijević for JigJoy

Apr 16

Why Agent Frameworks End Up As SDK Wrappers - And How To Overcome It

#llm #ai #agents #javascript

4 min read

DEV Community: Miodrag Vilotijević

How LLM Context Works: Messages, Reasoning, and Tool Calls

Model

Context

Context Items

Context Window

Tool Call

User Prompt

System Prompt

Reasoning

Assistant Message

Learn advance techniques for building AI systems during this weekend

NTP Novi Sad Hackathon — Build agents that work together | JigJoy × NTP Novi Sad

Join the hackathon: https://build.jigjoy.ai/

Mozaik Hackathon 2026: Build Concurrent Multi-Agent Systems and Compete for $1,000 in Cash Prizes

NTP Novi Sad Hackathon — Build agents that work together | JigJoy × NTP Novi Sad

We’re running an online hackathon for building concurrent AI agents — Sep 5–6

NTP Novi Sad Hackathon — Build agents that work together | JigJoy × NTP Novi Sad

How Two Builders Reached Nearly One Million Developers on dailydev

Tutorial: How to Build CLI Agent

Build Your Own CLI Agent: A Step-by-Step Guide

Build Your Own CLI Agent: A Step-by-Step Guide

What we are building

How the pieces fit together

Step 1 — Bootstrap the runtime (cli.tsx)

Step 2 — Compose the session (session.ts)

Step 3 — The agent loop (terminal/agent.ts)

Step 4 — Tools the model can use (terminal/tools.ts)

Step 5 — Feed the terminal UI (ui-updater.ts)

Step 6 — Wire Ink (app.tsx)

Step 7 — Credentials and build

Starter repository

Where to go next

Learn more

Reactive Agents, Typed Event Handlers, and Agent Swarms: What's New in Mozaik

From Non-Blocking to Reactive

Typed Event Handlers

The Self vs. External Split

Plain Messages on the Bus

A Bigger Model Lineup

From One Agent to a Swarm

Composing Intelligence

Get started

A different way to orchestrate AI agents - worth a read.

Structured Context, Context Memory, Context Item Generators, and the Agentic Environment

Structured Context, Context Memory, Context Item Generators, and the Agentic Environment

Structured Context

Context Memory

Context Item Generators

Agentic Environment

Default Participants

A Foundation for Multi-Agent Systems

My Story of Building a TypeScript Framework for Event-Driven AI Agents

jigjoy-ai / mozaik

Mozaik is a TypeScript runtime for building and sharing AI agents.

Mozaik

Agent Interoperability

Installation

API Key Configuration

I mapped the OpenResponses specification into domain objects to make context, context items, and streaming events explicit and usable across multiple providers - check it out.

Why Agent Frameworks End Up As SDK Wrappers - And How To Overcome It

Step 1 — Bootstrap the runtime (`cli.tsx`)

Step 2 — Compose the session (`session.ts`)

Step 3 — The agent loop (`terminal/agent.ts`)

Step 4 — Tools the model can use (`terminal/tools.ts`)

Step 5 — Feed the terminal UI (`ui-updater.ts`)

Step 6 — Wire Ink (`app.tsx`)