Blog / Thought leadership

An enterprise in a box: persistent agent swarms on the BEAM, with their memory on Semurg

14 October 2026 · Semurg · 4 min read · Markdown

agentsbeamelixirknowledge-graphdigital-twinenterprise

Most AI agents today are a loop in a script with a vector store attached. That is enough for one assistant. An organisation needs something else: many agents, each running for months rather than minutes, each with its own memory, all working on one shared picture of how the organisation actually works. This post describes that system, an enterprise in a box, and how it is built on Semurg.

The organisation's databases, object stores and documents flow into one knowledge graph on Semurg; many agents, each an isolated BEAM process, read and write that graph and call a model on the node or outside itYour databases, objectstores, documentsOne knowledge graph onSemurg: the digitaltwinThousands of agents,each a BEAM processA model: on the node,or one you chooseoutside itsynced inwrite memories, read the graphreasoncited factsThe organisation's databases, object stores and documents flow into one knowledge graph on Semurg; many agents, each an isolated BEAM process, read and write that graph and call a model on the node or outside itYour databases, objectstores, documentsOne knowledge graph onSemurg: the digitaltwinThousands of agents,each a BEAM processA model: on the node,or one you chooseoutside itsynced inwrite memories, read the graphreasoncited facts

The digital twin: the organisation as one graph

The first half is the data. Every system the organisation runs, its databases, its object stores, its document stores, is brought into one Semurg store and kept in step with it. People, customers, contracts, assets and decisions become entities with typed relations, and every fact is cited to the record or passage it came from. The ontology, the classes those entities fall into, builds itself from what is stored, so the model of the organisation grows as its data does. That graph is the digital twin: who owns what, which system holds which record, what changed and when, answerable in one query instead of one integration project per question.

The agents: one BEAM process each

The second half is the agents, and this is where the runtime matters. On the BEAM, the Erlang virtual machine that Semurg's engine is written for, an agent is a process: a few kilobytes of its own memory, its own mailbox, scheduled pre-emptively across every core of the machine. Three properties follow, and an organisation's agents need all three.

  • Isolated. A process shares nothing with its neighbours. An agent that crashes on a bad document takes down only itself, never the agent next to it.
  • Fault tolerant. Every agent runs under a supervisor. When one fails, the supervisor restarts it, with a ceiling on restarts so a persistent failure escalates instead of looping. The restarted agent reads its memory back from the graph and carries on, because what it knew was never only in its own process.
  • Massively concurrent. A BEAM node runs hundreds of thousands of processes. A swarm of thousands of agents, one per customer, per case, per asset, per running process, is an ordinary load, not a cluster of containers.

Each agent writes what it learns as memories, with the entities and relations it found, and reads the graph to decide what to do next. When it needs to reason, it calls a model: the embedding and retrieval models run on the Semurg node itself, and for the reasoning step most teams call a model of their choice outside it.

Memory on the same substrate

The agents' memory and the organisation's graph are the same store, on the same nodes the agents run beside. A memory one agent writes is a fact every other agent with access to that scope can read, cited to where it came from. Scopes keep agents and teams apart where they should be apart: one per agent, per team, or per end user. The store is append-only, so a crash, a restart or a whole node stopping loses nothing an agent was told it had stored.

Build it yourself, today

Everything above is available to any developer now. Write the swarm in Elixir, with Jido or with plain OTP supervisors, and give each agent a scope; every memory call goes to the node's memory routes or its MCP server. The complete Jido program on the agents page is the starting point: an action per memory call, run against a real node. Teams in other languages build the same swarm over MCP or HTTP, one connection per agent. The develop page lists every route and tool.

Or build it with us

For an organisation that wants the whole system, the sources synced, the graph and ontology built with its people, agents written for its own work, and agents running inside the node's own virtual machine, we do that as an engagement. See consulting; the node licences underneath are the same per-node licences everyone buys.

Said plainly

Semurg runs on Intel and AMD (x86_64) machines: Linux servers directly, Windows through WSL2 or Docker; a Mac version is coming. The node's own language model is slow on a processor today, so for an agent's reasoning step most teams use an external model; the node does memory, embeddings and retrieval. Which connectors exist for a given system is named in a scoping call, not promised here.

It's early: tell us where this falls short, in the comments wherever you found this post, or at semurg@semurg.org.

Related