Autonomous agents
Limits belong in code, not in the prompt
Published 28 Oct 2026 · Darko AI engineering
Every ceiling our agents run under is a number in the runner: openers per day, contacts per person, spend per day. The prompt is never the last line of defence.
The question every buyer asks about an autonomous agent is some version of “what stops it doing something stupid at three in the morning?” The answer that does not work is “we told it not to.” The answer that does is a set of limits the agent cannot see, cannot argue with, and cannot exceed.
Why prompts are not limits
A prompt is an instruction to a system whose job is to be persuaded by text. Anything that reaches the model, including the content it is reading on your behalf, is a candidate for changing its behaviour. A prompt that says “never send more than four messages a day” is a strong suggestion. It is not a cap.
A cap is a counter in the runner. When the counter reaches four the runner refuses the fifth action, whatever the model has decided, and writes the refusal to the log.
The limits we ship with every agent
- Per-day action ceilings. Openers, posts, sends, bookings: each class has its own daily number, enforced before the action is attempted.
- One-shot rules per target. One opener per person, ever. The state that enforces it lives in a store that outlives every run, so a restart cannot reset it.
- Spend ceilings. Model calls, compute and third-party credits each carry a daily cap. When it is hit the agent stops and says so. Our compute reaper polls two GPU markets every minute and kills anything older than its budget for the same reason.
- A refusal list. Targets, topics and actions the agent may never take, checked in code before the model is consulted.
- A kill switch the client owns. One flag, checked at the top of every loop.
What this looks like in practice
Mira, the autonomous X operator we run publicly, holds four opener messages a day, two quote posts a day, one opener per person for life, one booking link per conversation, and a permanent close state that no later run can reopen. Those are ceilings the system imposes on itself, and they are published as ceilings, not as results.
The failure we design against first is silent degradation: an agent that keeps running while quietly doing the wrong thing. Every gate fails closed, every run writes a log a person can read, and a stopped agent is a success state, not an incident.