swarmmesh

Shared context and memory for swarms of parallel AI agents, over a small protocol both Python and Node speak the same way.

Spin up ten coding agents on the same task and they cannot see what each other found. One agent rediscovers a bug another already fixed. Two agents overwrite the same file because neither knew the other touched it. SwarmMesh is a small server that sits alongside your existing agent framework and gives every agent process, in any language that can speak HTTP, a shared place to publish context and search memory.

It is not an orchestration framework. It does not schedule tasks, define agent roles, or route work between agents. Your existing framework (or your own code) keeps doing that. SwarmMesh only answers one question: how do independent agent processes read and write the same shared state.

pip install swarmmesh-cli # or npm install -g swarmmesh-cli

Either gives you aswarmmeshcommand on yourPATH.

This is a real terminal session, not a mockup: a Python-run mesh, a Node agent writing to it, and a Python agent reading back what the Node agent wrote. Two different languages, one shared mesh.

The number below is measured, not estimated. 50 sequentialPUT /v1/context/{namespace}/{key}requests against a local Python-run server averaged 0.8ms round trip each (40ms total for 50 requests) on the machine this README was written on. This isn't a rigorous benchmark, includescurl's own process-spawn overhead per request, and will vary by machine, but it's a real number from a real run, not a guess. Reproduce it yourself with:

for i in $(seq 1 50); do curl -s -o /dev/null -w "%{time_total}\n" \ -X PUT "http://127.0.0.1:8420/v1/context/bench/key$i" \ -H "Content-Type: application/json" -d "{\"value\":\"v$i\",\"agent_id\":\"bench\"}"; done

Both CLIs expose the same command tree. Flag names differ slightly between the two (Python uses Typer's--flag <value>style, Node uses commander's), but the commands and their behavior are identical. Output below is transcribed from running--helpon each built CLI.

The point of writing this down as a protocol instead of just shipping a library is that it means the two official CLIs aren't the only valid clients. A Python agent usingswarmmesh_cli.client.SwarmMeshClient, a Node agent using theSwarmMeshClientfromswarmmesh-cli, and a third agent written in a language with neither package can all register with the same mesh and see each other's context and memory, because they're all just calling the same documented HTTP endpoints and, optionally, subscribing to the same WebSocket event stream. Nothing about interop depends on a shared runtime, a shared process, or a shared filesystem.

There's no other project doing exactly what SwarmMesh does, so this isn't an apples-to-apples table. It's here to be honest about what two real, comparable multi-agent projects actually offer versus what SwarmMesh actually offers, checked directly against their READMEs and source, not assumed from their names. Both are older, larger, and more established than SwarmMesh, which has 0 GitHub stars and no known users yet.

The honest read: swarms has real orchestration depth and a large community that SwarmMesh doesn't try to replace. feynman is a polished end-user research tool, not infrastructure you'd embed elsewhere. SwarmMesh's actual claim is narrower than either: a small, documented protocol two languages already speak the same way. It's worth exactly that much, no more.

Multi-agent setups increasingly mean several agent processes working the same problem in parallel, sometimes in the same language, sometimes not, sometimes spawned by different tools entirely. Orchestration frameworks solve the "what should each agent do and in what order" problem. SwarmMesh solves a narrower, adjacent problem: once those agents are running, how do they tell each other what they've found without a human relaying messages between terminals or agents silently duplicating each other's work.

SwarmMesh is infrastructure, not a framework. It doesn't care what orchestrator spawned your agents, if any. It exposes a small HTTP + WebSocket surface for shared context (structured key-value state, like a run's current phase) and shared memory (free-text notes agents leave for each other, searchable by keyword). You point your agents at aswarmmesh serveprocess the same way you'd point them at a Redis instance, and they have a shared place to read and write.

Is this a replacement for LangGraph / CrewAI / AutoGen / <my orchestration framework>?No. SwarmMesh doesn't schedule agents, define workflows, or decide what happens next. It runs alongside whatever you use for that and gives the agents it spawns a shared context and memory layer. Point your orchestrator's agents at aswarmmesh serveprocess and keep using it for everything else.

Is the memory search semantic / embedding-based?No. It's Okapi BM25 keyword ranking, the same family of algorithm search engines have used for decades, computed locally over term frequency. It won't find memory entries that are conceptually related but share no vocabulary with your query. If you need that, theRankingBackendinterface is a documented extension point for wiring in your own embedding-based scorer. SwarmMesh doesn't ship one and won't silently call an embedding API on your behalf.

Does SwarmMesh persist data?Only if you ask it to.swarmmesh servedefaults to in-memory storage that's gone when the process exits. Pass--persist <path>for SQLite-backed storage that survives restarts.

Is it free to use commercially?Yes. SwarmMesh is MIT licensed, on both the Python and Node packages and the repository itself. Use it in a commercial product without asking permission or paying anything.

Local-first agent memory: a plain-Markdown Obsidian vault is the source of truth, with a rebuildable DuckDB index for hybrid BM25 + vector + graph recall.

Persistent memory and semantic search for AI coding assistants across sessions

Give your agent a memory: shared, cited, tenant-isolated knowledge-graph memory for any MCP host. Grounded answers from a local-first June endpoint — abstains rather than guesses.

Decentralized persistent memory for AI agents — encrypted vault storage built on Walrus and Sui.

Persistent memory for AI assistants and coding agents across ChatGPT, Claude, Cursor, and other MCP-compatible tools.

Your portable AI memory vault — memories, skills & configs, shared across every AI tool.

Local Work Model for AI agents that learns from real outcomes.

Adaptive MCP memory system for AI applications. Learns which retrieval strategies work for your data, scores results using cognitive science models, builds a knowledge graph automatically, and validates every parameter change against real query history before adopting it. Patent pending.

Auditable, self-improving knowledge & memory for AI agents over MCP — citation-enforced answers and a replayable why-trace, self-hosted on Postgres.