The Missing Primitive: How BEAM Can Unlock Persistent Interactive Execution for AI Agents
For years, Unix has been a cornerstone of modern computing, providing a robust and reliable platform for developers to build their applications. However, this foundation was built on the assumption that interactions with the system are ephemeral, requiring a human presence attached to a terminal. This limitation has led to the development of workarounds like tmux, which simulate interactive sessions by buffering input in memory.
But what if we told you there's a better way? Enter BEAM, the Erlang virtual machine designed in the 1980s for telephone switches that need to run forever, handle millions of concurrent connections, and never go down. In this article, we'll explore how BEAM can provide a more suitable foundation for AI agents, one that treats persistent interactive execution as the default.
Let's take a closer look at the Unix limitations. When you log in, your shell inherits a controlling terminal, which becomes the session leader. Processes spawned by your shell inherit this terminal, and when it disconnects, the kernel sends SIGHUP to the session leader, killing all child processes. This is the default behavior of Unix systems.
The problem with this approach is that it assumes interactions are ephemeral, requiring a human presence attached to a terminal. There's no middle path; you're either an interactive process or a daemon. But what if we wanted a system that could maintain state and context between disconnections? What if we wanted processes to be able to interact with each other in a persistent manner?
That's where tmux comes in – a userspace workaround for the Unix limitation. By faking the existence of a persistent interactive session, tmux allows agents to run indefinitely without dying when the terminal disconnects. However, this hack only works because it's papering over a fundamental mismatch between what AI agents need and what Unix provides.
BEAM, on the other hand, was designed with a different approach in mind. It treats interactivity as just message passing – sending messages to processes from anywhere, without requiring a human presence attached to a terminal. This inversion of the traditional Unix model is key to unlocking persistent interactive execution for AI agents.
So, what does an agent shell built on BEAM look like? Each agent is a process that receives messages and sends responses. It has state – conversation history, current task, memory – which can be reconstructed when the process restarts. An "agent shell" might look like this:
- Each agent is a process (a GenServer in Elixir terms).
- It receives messages: user input, tool results, signals from other agents.
- It sends messages: output to display, requests to tools, coordination with other agents.
- The agent process runs indefinitely. It doesn't care if you're connected or not.
This is the key inversion of the traditional Unix model – treating interactivity as just message passing, rather than requiring a human presence attached to a terminal. Phoenix LiveView, Elixir's real-time web framework, already does most of this for web UIs. The pieces exist; they just haven't been composed for agent use cases yet.
Because we're building the infrastructure for AI agents on a foundation that assumes agents shouldn't exist. Every time you SSH into a server and start tmux to run Claude Code, you're working around a fifty-year-old assumption about what "interactive" means. The workarounds work, but they're friction – complexity – another thing to manage, another thing to break.
Someone is going to build the agent-native environment that treats persistent interactive execution as the default, not the exception. It might be built on BEAM. It might be something else. But it won't be built on the Unix interactive/daemon dichotomy, because that dichotomy doesn't have room for what agents actually are.
The computer science is already done. Erlang solved this in 1986. We just need to apply it to the agent problem – to build the shell that treats agents as first-class citizens instead of weird edge cases that need tmux to survive.