Back to blog
·by Patrick Hofmann

The Lever Was Never in the Prompt

There was no button to delete an agent. To get rid of one I had to log in as root and blow away a home directory. The day I built a destroy button with a danger zone was the day I admitted: managing many agents isn't a prompting problem anymore.

OpenApeAI AgentsToolingInfrastructureBuilding in Public

There was no button to delete an agent.

To get rid of one, I logged in as root, found the home directory and cleared it away. At /var/openape/homes/ that worked without an admin password, before that it was a small ritual. In both cases: no button, no confirmation, no list something disappears from. Just me, a shell and the hope that I hit the right directory.

I actually wanted to sharpen an agent's system prompt. What I built was a destroy button with a danger zone.

How it was before

An agent was a system prompt. There was a SOUL.md — a persona file clamped as a hidden default in front of every system prompt — and that was the entire management surface. When an agent misbehaved, I tweaked the text. More behavior, sharper tone, an additional rule. That's the mental model from the time when there was one agent: the agent is the intelligence, so working on the agent is working on the prompt.

On /agents they stood as a flat list. One entry per agent, no grouping, no hint of which Nest each runs on. As long as there were two, three, that was fine. A list with three rows needs no structure.

One became several

At some point it wasn't three anymore. And at that point every question starts being a different one.

Which agent runs where? — irrelevant before, now a flat list that groups nothing. How do I get rid of one? — before a root login, now a root login I don't want to do ten times. How do I give a new agent a sensible persona without typing the SOUL.md text field from my head every time? — no problem before, because there was one agent and it had its prompt. Now: every spawn begins with an empty text field.

None of these questions is a prompt question. They're all questions about how I survey, create and get rid of a growing set of similar things. That's the problem a fleet has, not the one a model has.

Why I built a destroy button

The obvious reflex with an agent that doesn't do what it should is: better prompt. More context, clearer instruction, one more rule. That works for one agent.

With several, the bottleneck isn't that an individual agent is too dumb. The bottleneck is that I have no overview of which ones exist, no safe way to remove one, and no fast way to set one up with a usable persona. A better prompt solves none of that. Those are ops and UI gaps, and you close those with ops and UI.

So I first built what hurt the most: a danger zone on the agent detail page with a destroy button that removes the agent from the UI instead of from a root shell — and that degrades cleanly on old headless agents instead of crashing. The rest followed from it: the /agents list grouped by Nest instead of a flat enumeration, system-prompt presets in the spawn dialog instead of an empty text field, SOUL.md merged into the system_prompt instead of maintaining two places, a tool picker per agent.

Nothing of that makes an individual agent smarter. All of it makes a fleet manageable.

What happened under the UI

The UI was only the visible half. Underneath, the Nest stack went from HTTP API over a file-based intent layer to a pure registry watcher: the Nest reads the agents.json the CLI writes, no more contract than that is needed. UNIX permissions on the intents/ directory replace the bearer-token check. That too is no prompt — it's plumbing that makes a fleet load-bearing.

What fell away

The belief that working on the prompt means working on the agent.

As long as there was one agent, that was approximately true. The prompt was the only knob, so every improvement was a prompt improvement. What fell away is the assumption that this scales. With a fleet, the work that matters is almost never the prompt: it's the overview, safe deletion, fast spawn, the persona presets, the per-agent tool scope. The knobs all moved out of the model and into the management around it.

Closing

I wanted to sharpen a system prompt and built a destroy button. That sounds like scope creep, but it's the opposite — it's the moment the actual problem became visible. The problem was never that an agent needs a better prompt. The problem was that one became several and I was still working with the tools for one.

The lever for a single agent sits in the prompt. The lever for many doesn't sit there — and it never did, I just never had enough agents to notice.