Phantom: an agent that keeps its own machine, and the Docker socket that comes with it

The problem is disposable context, and the fix is a machine that outlives the session

Most agent deployments end when the tab closes. The README puts it plainly: you open a chat, get an answer, close the tab, and the context is gone, so every session starts at day one. Phantom's answer is to give the agent a computer of its own rather than a thread in someone else's UI. It runs on Slack, exposes a web chat interface at /chat, has its own email address, and installs software on its own VM. The intended user is not someone who wants autocomplete in an editor. It is someone who wants a long-running process that accumulates state about a specific job and keeps working between conversations. The README is explicit that this is not a chatbot, and the examples it shows (a ClickHouse instance loaded with 28.7 million Hacker News rows, a Discord channel the agent built for itself after being asked whether it could) are the kind of work that only makes sense if the agent's environment survives across sessions. If your tasks are one-shot questions, the persistent machine is overhead with no payoff.

Memory in Qdrant, tools over MCP, and an evolution loop that judges its own output

Three mechanisms are visible in the supplied material. First, persistence: Qdrant starts alongside the agent for memory, and Ollama pulls an embedding model, so recall is vector search over stored interactions rather than a replayed transcript. Second, capability growth: the agent registers things it builds as MCP tools. The ClickHouse example ends with the agent registering its own REST API as an MCP tool so it could query the data in later sessions and so other agents could query it too. That is the self-evolution claim in concrete form, and it is narrower than the phrase suggests: the agent is adding tools to its own toolset, not rewriting its core. Third, model routing. The README describes a provider block in phantom.yaml and states that both the main agent and every evolution judge flow through the chosen provider. That detail matters because it means the component evaluating whether a change was an improvement runs on the same backend as the component proposing it. Whether that is a problem depends on how much you trust a single model to grade its own work. The README does not describe a second judge or an external check, so treat the evolution loop as self-assessed until you read the source.

Bringing it up: two curl commands, an .env file, and one YAML block

The documented Docker path is short. You fetch the compose file and the environment template, edit the environment file, and start the stack:

curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/docker-compose.user.yaml -o docker-compose.yaml curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/.env.example -o .env docker compose up -d

The README says to add ANTHROPIC_API_KEY, Slack tokens, and OWNER_SLACK_USER_ID to .env, and that RESEND_API_KEY enables email sending. Health is checked at http://localhost:3100/health, and with Slack configured the agent DMs you when it is ready. Provider switching is a block in phantom.yaml, with the API key supplied through an environment variable named by api_key_env:

model: claude-opus-4-7 provider: type: zai api_key_env: ZAI_API_KEY model_mappings: sonnet: glm-5.1

The README lists seven providers: Anthropic as the default, Z.AI, OpenRouter, Ollama, vLLM, LiteLLM, and any custom Anthropic Messages API compatible endpoint. It claims Z.AI's GLM-5.1 is roughly 15x cheaper than Claude Opus for comparable coding quality. That is the project's own claim, not a measured result, and the README offers no benchmark behind it. The provider reference lives at docs/providers.md.

The Docker socket is mounted on purpose, and the README says so

This is the constraint that should decide where you deploy. The compose file mounts /var/run/docker.sock into the Phantom container so the agent can spawn sibling containers, for example for sandboxed code execution. The README calls this an intentional architectural trade-off and states the consequence directly: the socket grants the container root-equivalent access to the Docker daemon, so a compromised Phantom process could create, modify, or destroy any container on the host. The stated mitigations are to run Phantom on a dedicated machine or VM rather than a personal workstation. There is no sandboxing layer described between the agent and the daemon. For a tool whose selling point is that it installs software and builds infrastructure without asking for permission, this is coherent: an agent that cannot reach the daemon cannot do the ClickHouse or Discord work shown in the README. But it also means the blast radius of a bad tool call, a prompt injection, or a malicious dependency is the host, not the container. The README's own wording is the right frame. This is a trade-off you accept deliberately, not a default you inherit.

Where Phantom is the wrong tool

Three cases stand out. If you need isolated multi-tenant execution, Phantom's model is one agent with broad host access, and nothing in the material describes per-tenant isolation. If you need a pinned, versioned artifact, the README badge shows version 0.20.2 and the repository returned no releases, so the documented install path pulls a compose file from the main branch rather than a tagged version. That means the file you fetch today is not guaranteed to match the file you fetch next month. If you need to run this on a laptop alongside your other work, the socket mount rules it out under the README's own guidance. There is also a quieter issue: the README's evidence for the self-evolution claim is three narrated stories with screenshots and GIFs. They are specific and they name numbers (28.7 million rows, 890,450 rows, 25 metrics), but they are the project's own accounts of its own instances. Nothing in the supplied material is an independent reproduction, and the test badge count is not a substitute for one. Read the evolution code before you rely on the loop.

The alternative: a stateless agent you host, versus a stateful agent that hosts itself

The closest comparison in the material is not another product but the pattern the README argues against: a hosted chat agent or an API-driven assistant that you call per task, where you supply context each time and nothing persists on the agent side. The difference is where state lives. In the stateless pattern, your application owns the database, the credentials, and the compute, and the model is a function you invoke. In Phantom's pattern, the agent owns a Qdrant instance, an Ollama embedding model, a set of MCP tools it registered itself, and the containers it spawned. You get continuity for free and you give up the ability to reason about the whole system from your own codebase. The second alternative is a self-hosted framework where you write the tools and the memory layer yourself, such as wiring the Claude Agent SDK or an MCP client directly. That keeps the Docker socket out of the picture entirely, at the cost of building the persistence and tool-registration layers that Phantom ships. The honest framing is that Phantom is a bet that the agent's autonomy is worth more than your control over its environment, and the socket mount is the price of that bet stated in plain text.

Maintenance cost, licence, and what the repository does not tell you

Phantom is Apache-2.0, which permits commercial use and modification and includes a patent grant, but it also means there is no warranty and no obligation on the maintainers to support your deployment. If you fork it, you take on the upgrade path yourself. The maintenance surface is larger than a typical library: a Qdrant instance, an Ollama model pull, a Docker socket dependency, whichever provider you configured, and the agent's own self-registered MCP tools, which accumulate over time and are not described as having a pruning or review step. The last push recorded is 2026-06-16 and the README shows 0.20.2, so this is active but pre-1.0. The material does not state a support policy, a deprecation policy for MCP tools the agent creates, or what happens to memory when you change embedding models. That last one is worth checking in docs/ before you commit, because swapping the Ollama embedding model after months of stored vectors is the kind of change that silently degrades recall rather than failing loudly.

Editorial conclusion

Phantom is for teams willing to give an agent a dedicated VM and accept that the container holds root-equivalent access to the Docker daemon, because the README says the socket is mounted on purpose so the agent can spawn sibling containers. It is not for anyone who wants to run this on a personal workstation, or who needs a stable release cadence: the README shows version 0.20.2 and the repository returned no releases. Before adopting, verify three things in your own copy of the repo: that docker-compose.yaml still mounts /var/run/docker.sock, that docs/providers.md documents the provider block you intend to use, and that the health endpoint at http://localhost:3100/health responds after docker compose up -d.

Official sources

1. ghostwright/phantom on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README