Intelai
What a Headless Agent Costs After the Demo
A persistent agent is cheap to start and expensive to supervise. Three costs the launch posts omit, and the controls that make them payable.
A pull request came back green at 11:47pm. I read the summary on my phone, in bed, and typed two words: request review.
Two weeks earlier I had installed an open-source project that runs a coding agent on a machine I control and lets me drive it from a chat app. By the second week it was not a demo. It held credentials to a mailbox and to the repositories I work in.
The pitch for this category is that the agent works while you sleep. That part is true, and it is the least interesting thing about it. What changes is not your output. What changes is that your accounts become an API for a process that keeps running after you close the laptop.
Headless means you created a new principal
An assistant waits. A headless agent persists. It has a loop, a queue, memory it wrote for itself, and a set of credentials you attached while you were in a good mood.
That last item is the one to sit with. The moment you hand an agent a token, you have created a new principal in your environment. It has a name, a scope, and a blast radius. Nobody rotates its keys. Nobody reviews its access at the end of the quarter. It lives in a config file beside the API keys you meant to clean up in March.
Once you see it as a principal rather than a feature, the design questions get easier. What is this thing allowed to touch. What does it leave behind. Who can turn it off at 3am when I cannot.
Most of the failures I have seen or caused were not model failures. They were provisioning failures. Somebody attached an admin token because the scoped one was annoying to set up, and the agent did exactly what an admin token permits.
The setup bill arrives before the value
I burned about $250 in tokens before the thing did work I would keep. Very little of that was reasoning. It was the agent learning my repository layout, my naming conventions, and which of my own scripts lie about their exit codes.
You pay that bill in public, one failed run at a time. A supervised assistant fails in front of you and you correct it in the same minute. An unsupervised agent fails at 2am, retries four variations of the same wrong idea, and bills you for all five.
The fix is not a better model. It is a smaller first job. Point it at a read-only copy. Give it one repository and no mail. Let it be useless for a week while you watch what it reaches for. The capability you want is not autonomy. It is a bounded agent that fails cheaply.
The supervision cost is the real one
The output is cheap to read. The record is not. A night's work can produce a dozen artifacts across mail, notes, and code, and the summary in the chat window will describe three of them. Reconstructing the rest is the job nobody budgeted for.
That is the trade, and it only works if the review gets cheaper over time. It gets cheaper when the record is specific: which tool ran, with what arguments, against which record, and what came back. It does not get cheaper when the record is a chat transcript and a spinner that said "tool call completed."
The output is the part you can see. The record is the part you can defend.
So I stopped judging runs by what they produced and started judging them by what they left behind. A run with a clean diff and a thin log is worse than a run that failed loudly and said where.
What I changed after the first month
Separate identity. One agent, one account, one set of scoped tokens. No shared logins with me, because a shared login erases the only question that matters after an incident: which principal did this.
A ceiling before a grant. Spend limits, repository limits, and a clock. An agent that can run for nine hours needs a reason to run for nine hours.
A log I own. Not the vendor console. A file on a machine I control, append-only, with the arguments and the result. If I cannot grep it, I do not have it.
An off switch that does not route through the agent. If the only way to stop the process is to ask the process, you have a suggestion box.
Staged capability. Reads first. Drafts second. Sends and writes third, and only after the first two have a month of boring behind them.
None of this makes an agent safe. It makes the failure legible, which is the most you get from any system you did not write.
The question to ask before the next install
Headless agents are real capability. I ship work from a phone now, and I am not going back to typing every command at a desk. The people selling this category are also right that the ceiling is high.
The ceiling is not the constraint. The constraint is that you are handing a stochastic process the keys to accounts that were built on the assumption that a human was holding them.
So ask the boring question first. When this run ends badly at 3am, what will I be able to show someone at 9am. If the answer is a chat window and a guess, the agent is not ready for the accounts you gave it.
You cannot supervise what you cannot reconstruct.