---
title: An enterprise in a box: persistent agent swarms on the BEAM, with their memory on Semurg
slug: enterprise-in-a-box-agent-swarms-on-the-beam
date: 2026-10-14
author: Semurg
section: thought-leadership
tags: [agents, beam, elixir, knowledge-graph, digital-twin, enterprise]
summary: A digital twin of the organisation, its systems in one knowledge graph, with thousands of long-lived agents working on it, each an isolated BEAM process with its own memory. What it takes, and how to build it on Semurg today.
status: published
covers: [route:POST /v1/mcp, mcp:memory_remember, mcp:memory_recall, mcp:memory_context, mcp:memory_relate]
---
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.

> Diagram eib: 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 it

## 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](/agents) 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](/develop) 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](/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.