The Architecture of Multi-Agent Systems: What Erlang, VS Code, and a Simpsons-Themed Loop Reveal

In 1986, Ericsson engineers shipped the BEAM virtual machine to run telephone switches. Each phone call became an isolated process with its own memory, its own lifecycle, and its own failure boundary. Processes communicated through message passing. Supervisors watched for crashes and restarted processes in clean state. The system handled millions of concurrent calls with five-nines uptime.

In 2026, the AI industry is rebuilding this exact architecture --- in Python.

Four things happened in February that make this observation worth more than a footnote.

The BEAM Parallel

George Guimaraes, a former principal engineer at Nubank (via the Plataformatec acqui-hire), published a detailed technical argument that every major Python agent framework is converging on patterns the BEAM solved decades ago.

The mapping is uncomfortably precise:

Langroid explicitly cites the Actor Framework as inspiration. Agents are “message transformers” that communicate through direct message passing. This is the Erlang actor model with different syntax.
AutoGen v0.4 was rebuilt by Microsoft as an “event-driven actor framework” with asynchronous message passing and runtime-managed lifecycles. They arrived at the actor model independently because the problem demands it.
LangGraph implements state machines with shared state through reducers --- a different path to the same orchestration problem.
CrewAI organizes agents through task output chaining and delegation.

Every framework takes a different route, but they converge on the same set of requirements: isolated agent state, message-based communication, workflow orchestration, and failure recovery. OTP --- Erlang’s Open Telecom Platform, formalized in 1998 --- had solutions for each of these as runtime primitives, not libraries.

The technical gap is real. BEAM processes are approximately 2KB each. You can spawn millions. Each has its own heap and garbage collector, and the scheduler preemptively switches between them every 4,000 reductions so no single process can starve others. Python’s asyncio gives you concurrency without isolation: all coroutines share memory, and one bad coroutine can corrupt state for everything else. Node.js has better concurrency but remains fundamentally single-threaded.

Guimaraes estimates you can get about 70% of BEAM capabilities in Python or TypeScript with enough engineering. The remaining 30% --- preemptive scheduling, per-process garbage collection, hot code swapping, true fault isolation --- requires runtime-level support. You cannot bolt these onto a language that was not designed for them.

The IDE Layer Catches Up

On February 4, Microsoft shipped VS Code v1.109, which transforms the editor into what amounts to a multi-agent control surface.

Three features matter architecturally:

Parallel subagents. Agents can spawn subtasks that run in parallel, each with its own dedicated context window. This is process isolation at the IDE level. The main agent’s context does not overflow because each subagent operates independently --- the same principle as BEAM’s per-process memory model.

MCP Apps. Servers can now push context updates dynamically into chat sessions. This shifts MCP from a pull model (agent calls tool) to a push model (server updates context), enabling richer feedback loops without manual polling.

Unified session management. Developers can run Claude, Codex, and Copilot side by side, switching between local and cloud-based agent sessions from a single interface. This is not just convenience --- it enables the kind of specialized agent teams that production systems require: a planning agent on one model, an implementation agent on another, a security scanner on a third.

The architectural signal is that VS Code is not adding AI features. It is adding concurrency primitives. Isolation, parallel execution, and session lifecycle management are the same problems BEAM solved for telephony, applied to developer tooling.

The Adversarial Feedback Loop

Joshua Samuel published the Grandpa Loop, a 13-agent orchestration architecture that takes a different approach to the reliability problem. Where BEAM uses supervision trees for fault recovery, the Grandpa Loop uses adversarial review for fault prevention.

The architecture assigns each agent a single responsibility with zero trust in the agent before it. The names come from The Simpsons, but the design patterns are serious:

Sideshow Bob reviews every specification before code is written. His job is adversarial: find the gaps, the ambiguities, the unstated assumptions. A rejected spec costs minutes. A bad spec that survives costs the entire build-test-deploy cycle.

Bart is the destructive tester whose job is not to confirm the build works, but to prove it does not.

Comic Book Guy walks through real user journeys against the live staging environment. He is the only agent that can block a commit based on usability, not just functional correctness. If the automated tests all pass but the UX is confusing, he emits ux.blocked and the pipeline reruns.

Grandpa watches the entire system. He tracks iteration counts, failure patterns, and cycle times. He makes one minimal change at a time and documents every adjustment with rationale.

The key design principle: “If you can’t prove it, it didn’t happen.” No agent can declare success without structured evidence. This is backpressure applied to the entire pipeline --- the same concept BEAM’s supervision trees implement at the process level, applied here at the workflow level.

The parallels to BEAM are structural:

Supervision trees restart crashed processes → Adversarial review prevents defective specs from entering the build pipeline
Per-process isolation → Single-responsibility agents with zero trust
Built-in distribution → Parallel test and documentation tracks

Samuel is honest about the tradeoffs. Thirteen agents means thirteen LLM calls minimum per iteration. For a one-line change, it is “like hiring an orchestra to play a doorbell.” The derivative loops (Bugfix: 4 agents, Deploy: 2 agents, UX Discovery: 2 agents) show the practical answer: use the right-sized subset for the task.

Strategy Matters More Than Capability

If multi-agent architecture is about how agents coordinate, Lars de Ridder’s Context Lens research shows why coordination strategy matters more than raw model capability.

He planted a bug in Express.js, gave the same prompt to four AI coding tools, and intercepted every API call. All four solved the bug. The difference was in how they used their context windows:

Tool	Mean Tokens	Strategy
Opus 4.6	27K	”The Detective” --- git log, targeted diff, 20 lines read, fix
Codex (GPT-5.3)	35K	”The Unix Hacker” --- parallel grep/sed, ignores git
Sonnet 4.5	50K	”The Student” --- reads entire test file, builds mental model
Gemini 2.5 Pro	258K	”The Professor” --- dumps 118K tokens of git history in one call

Same outcome. A 10x difference in resource consumption. Opus used 27K tokens because it identified the most efficient information source (git history) and took the most direct path. Gemini hoovered up entire file histories because it could.

De Ridder’s conclusion: “Context management, on the tool side, is basically nonexistent. The efficiency differences come entirely from investigation strategy, not from any deliberate attempt to manage the context window.”

This has direct implications for multi-agent architecture. When you run thirteen agents, context discipline becomes multiplicative. An agent that reads 20 lines instead of 500 saves not just tokens, but the cascading effect of polluted context on every subsequent decision. The Grandpa Loop’s principle of fresh context per iteration and the BEAM’s per-process memory isolation are both solving the same underlying problem: preventing context contamination from propagating through the system.

What This Means for Teams Building Agent Systems

The convergence across these four signals suggests a set of architectural principles:

Isolation is not optional. Whether through BEAM processes, VS Code subagent context windows, or single-responsibility agents with zero trust, every successful multi-agent architecture builds walls between agents. Shared state is the path to cascading failures.

Supervision beats defensive coding. BEAM’s “let it crash” philosophy and the Grandpa Loop’s adversarial review are two expressions of the same insight: you cannot anticipate every failure mode in a non-deterministic system. Build recovery mechanisms, not error handlers.

Context discipline is a multiplier. The 10x efficiency gap between Opus and Gemini on the same task demonstrates that strategy matters more than capability. This applies to individual agents and to multi-agent systems: the architecture that keeps each agent’s context minimal and focused will outperform the architecture that dumps everything into shared memory.

The architecture is not new. Erlang solved concurrent, fault-tolerant agent orchestration in 1986. VS Code is implementing isolation and parallelism at the IDE level. The Grandpa Loop demonstrates adversarial feedback loops at the workflow level. The patterns are the same. The stakes --- and the non-determinism of LLM outputs --- are what make 2026 different.

The uncomfortable truth from Guimaraes: you are not building something new. You are rebuilding telecom infrastructure in a language that was not designed for it. The question is whether you learn from the three decades of production experience that already exists, or spend the next three years rediscovering it.

Sources: George Guimaraes, VS Code v1.109 release, Joshua Samuel, Lars de Ridder. For questions about applying multi-agent governance to your engineering team: contact@victorinollc.com | www.victorinollc.com