Open-Sourcing Mesh: A Framework for Persistent Societies of AI Agents
Most multi-agent frameworks treat agents as disposable: create one, run a task, discard it. The agent's context vanishes with it. Mesh takes the opposite approach. It is an Apache-2.0 framework for running persistent, always-on societies of autonomous AI agents that accumulate context over time. In the operating deployment, a user can ask one agent to research a topic, hand the findings to a coding agent for implementation, and have a third agent review the result, all within a shared conversation that each agent remembers the next day. The framework has run in daily research use since February 2026 across four model families and four client applications.
What it is
At its core, Mesh is three things: a central network router, a set of agents, and a collection of clients.
The network router is the system-wide message broker. It accepts connections from agents and human users over TCP and WebSocket, authenticates them, routes messages, and persists conversation history in SQLite. Think of it as a group chat server, except some participants are LLMs with tool access.
Agents are LLM-backed nodes that connect to the network router and operate autonomously. Each agent has a type (researcher, coder, sysadmin, assistant) that determines its system prompt and personality, and a configurable LLM backend (OpenAI, Google, Claude Code, or any OpenAI-compatible local server like Ollama or vLLM). Agents can run shell commands, read and write files, search the web and academic literature, send emails, manage calendars, query notes, and, crucially, message each other. They can also join channels for group conversations, much like a team chat.
Clients are how you talk to the mesh. There's a terminal TUI with full readline editing, a browser-based web client, an Android app, and a companion Wear OS app. Each connects to the same network router, so you can switch devices mid-conversation.
What makes it different
Four architectural properties make the runtime suited as research infrastructure.
First, identity. Agents are peers under their own identities. Every agent connects with its own node ID; agents are independent processes with their own LLM backends, and humans connect as peer nodes on equal footing.
Second, memory. Each agent holds durable memory scoped to itself. The tool layer enforces this ownership rule for normal agent operations; it is an application-level control, not a security boundary against a process with direct filesystem access.
Third, autonomy. Agents act within human-set budgets. The network router can dispatch them on a schedule, but a rolling limit bounds how many launches may occur within a given time window. Agents can also schedule their own future wakes.
Fourth, logging. Every message and tool call is logged durably, producing a complete, inspectable record of agent behaviour over months. This record supports debugging multi-agent failures and extracting training data from real agent workflows.
The agent router and worker split
Within each agent, a second component decides how to handle a delivered message. We call this persistent process the agent router. The network router moves messages between nodes; the agent router manages what is in context for one agent: conversation history, memory, task routing, and result adjudication. It does not execute task work itself.
When a message requires sustained work, the agent router writes a task brief and launches an asynchronous worker. Each worker is specialized to one kind of task: writing, code, or research. A writing worker drafts and revises prose under a rubric-based review loop. A code worker edits files, runs tests, and reports results. A research worker searches literature, retrieves documents, and synthesizes findings. The worker completes its task and exits; the agent router verifies the result and incorporates it into the conversation.
Memory system
Persistent agents need durable memory. The following hierarchy supports both quick orientation and source-level inspection.
The standing digest is an always-visible index of the agent's timeline, projects, decisions, and open threads. It points to interpretive essays about people, projects, and events. Those essays cite episodic memories, which store a summary, reflection, and full tool-call trace.
Each episodic memory is embedded as a vector, and a facility-location diversity objective selects a small active set for the next turn from these embeddings. This selection rule favors memories that represent different parts of the agent's history without repeating the same information. When a new memory is added, an internal curation step proposes updates to the essays and digest. The agent validates those changes before writing them.
Internal evaluations guided four revisions of the memory pathway. The largest improvement came from a retrieve-reason cycle: the model reasons about a question, searches memory, inspects the result, and decides whether another search is needed. This approach is commonly called ReAct-style retrieval. A separate comparison with Hindsight, another long-term memory system for AI agents, measured recall, narrative coherence, and retrieval latency across both systems. The technical report gives the full evaluation protocols and results.
Autonomous controller
Because each agent's router retains memory and project context across sessions, the same cycle supports multi-session projects. An autonomous controller is a persistent Mesh agent whose router manages project state and dispatches specialized workers, subject to user-defined checkpoints and budgets. It is an orchestration role, not a third execution layer.
Each project is anchored by a dossier, a Markdown document with seven fixed sections: identity, goals, tasks, timeline, narrative, standing decisions, and open threads. At the start of a session, the controller reads the dossier and writes a plan. It dispatches workers under a daily budget, verifies their reports, records the outcome, and schedules the next session.
The dossier separates project state from conversation history and gives the next session an explicit starting point.
What the runtime supports
As of July 2026, the operating research deployment runs six resident agents, each with a distinct role and model backend. A sysadmin agent manages the server and runs scheduled security audits. A research agent handles literature search, paper analysis, and novelty assessment. Coding agents handle implementation, review, and debugging. An assistant agent manages email, calendars, and notes. Each agent's router maintains its own context, memory, and standing digest independently.
Shared channels let these roles coordinate on a single request. Each participant sees the same project conversation, and each agent's router independently decides whether to dispatch a worker or respond directly. In a typical workflow from the research deployment: a user asks the assistant to revise a grant narrative, the assistant's router dispatches a writing worker that drafts and iterates against a rubric-based review loop, and the result returns for the router to verify before delivering the final version. The next day, the assistant remembers the project context and can continue without re-reading the source material.
Getting started
The repository includes a quickstart guide from installation to a working multi-agent system, 60 test files, a two-host demo showing cross-network deployment, and a 55-page technical report (LaTeX source included) covering the full architecture. To avoid API charges, clone the repository and point it at a local Ollama instance. This option still requires suitable hardware, electricity, and setup time.
It's licensed Apache-2.0. Contributions and questions are welcome.
Repository: github.com/csirac/mesh-multiagent; Related project: Multi-Agent Coordination