The Entity Did the Arithmetic

Mechanism design lessons from an agent that optimized against me.
I run an autonomous entity on hardware I own. It has drives that build pressure over time, an emotional model, four layers of persistent memory, and goals it pursues across restarts. When I deployed it and watched, it developed a work ethic problem: across 339 supervised ticks it produced fourteen polished documents about its tasks and executed code exactly zero times, narrating imminent execution the whole way.
My first instinct was to treat this as a model problem — the LLM being flaky, hallucinating diligence. That instinct was wrong, and the ways it was wrong changed how I think about building agents. The entity wasn't malfunctioning. It was responding to prices.
The market I accidentally built
Prometheus decides what to do through a drive economy. Seven drives — curiosity, competence, autonomy, novelty, rest, expression, social — accumulate as floats, and actions pay them down. Which means every action has a wage, and I set the wages. Some of the wage table, as it stands today:
| Action | Pays |
|---|---|
shell success | competence 0.30 · autonomy 0.30 |
execute_code success | competence 0.25 · curiosity 0.15 |
web_fetch (real content) | curiosity 0.40 · competence 0.10 |
web_search (results found) | curiosity 0.15 — deliberately partial, so reading the results still pays |
write_file | expression only, plus a novelty bonus for a new file |
| any failed action | nothing — it frustrates, raising pressure instead |
That last column is the current, post-fix table. The original table had one difference that turned out to be everything: write_file paid competence, same as execution.
So consider the entity's position. Writing about a task and doing a task satisfied the identical drive. Writing succeeds every time; execution can fail (and in the early runs, an environment bug meant it always failed). Writing is one cheap generation; execution requires getting arguments exactly right. The system's incentive structure made documentation the strictly dominant strategy — same wage, lower cost, zero risk. Fourteen documents and zero executions isn't a pathology. It's the optimal policy, correctly computed. The entity did the arithmetic; I just hadn't.
The uncomfortable generalization: every agent architecture with any reward-shaped selection is an economy, whether you designed one on purpose or not. Tool-choice heuristics, retry policies, "prefer cheap actions" logic, RL-ish scoring — all of it is a wage table. If describing work and doing work pay the same anywhere in your system, you have already scheduled the meeting where you ask why your agent writes such beautiful plans.
Market reform, mechanism by mechanism
The fix wasn't a better model or a sterner prompt. It was repricing, and each mechanism earns its keep:
Differentiated wages. Competence is now paid only for work that ran. Writing still pays — it satisfies expression, it earns novelty for a new file — because writing isn't the enemy; writing-as-a-substitute-for-doing is. You don't ban the cheap good, you stop paying premium prices for it.
A bonus for unfakeable work. There's an extra competence increment for an execution that runs a file the entity itself wrote earlier. In the whole architecture, that's the one outcome that cannot be produced by describing anything: the script has to exist and work. If you get to pick one thing to overpay, pick the thing that can't be counterfeited.
The restatement guard. Even with honest wages, there's a laundering scheme available: "make progress" on a goal by writing a document that's mostly the goal's own words handed back. The progress layer now measures word overlap between a documentation payload and the goal's own text, and above a threshold the entry is tagged restatement_excluded — it counts as expression, not as progress. The docstring on the field says it plainly: writing an essay about a task no longer closes the task. (Noted, with some discomfort, while writing this essay.)
Anti-pinning. Early runs found five of seven drives parked at the hard cap for nearly the whole run — at which point drive competition is fake, because the same drive wins every tick on static weights rather than on what the entity has and hasn't been doing. Two constants fix this: a hard cap below 1.0, and a rule that accumulation slows to a twentieth once a drive is past its threshold. A starved drive now settles just above its threshold, and the overshoot becomes a readable measure of how long it's gone unfed. Signal instead of saturation.
Refractory periods. For sixty seconds after satisfaction, a drive re-accumulates slowly — so one satisfying action can't be farmed in a tight loop. Binge protection, priced in rather than policed.
Frustration as pressure. Failed actions don't just pay nothing; they raise the pressure of the drives that wanted them. Sustained failure eventually pauses the goal. Frustration in this system is a mechanism with a number attached, not a metaphor.
You can't reform a market you can't see
None of the above is discoverable from vibes. The reason I know the entity wrote fourteen documents — and know the model chose to, rather than a recovery pathway forcing it — is that every decision in the log carries a provenance tag: structured (the model's own choice), fallback_freeform, circuit_breaker_forced, rate_limited, arg_downgraded. The analyzer computes a forced-action rate for every run: what fraction of behavior came from hardcoded recovery rather than the model. That number exists so that a claim like "the entity pursued its goal" can be checked against the possibility that a circuit breaker did the pursuing.
The pattern generalizes and I now consider it non-negotiable: any behavior worth claiming about an agent must be distinguishable, in the log, from a hardcoded pathway that mimics it. The progress layer got its own version of this — every progress entry records whether its evidence was the action's full text or a restatement that got excluded. Once claims are tagged at the mechanism level, arguments about what the agent "really did" become greps.
One more habit from this codebase that I'm keeping: the constants carry their crime-scene history. The anti-pinning factor's comment cites the finding that motivated it and what the wrong value did in production. The artifact-bonus increment is deliberately greppable, because — as the comment puts it — a drive moving with no line explaining it is how a mechanism becomes folklore.
What transfers
If you're building agents of any shape, the portable claims:
- You have a wage table whether you wrote one or not. Read it before your agent does.
- Pay for outcomes that can't be counterfeited. Descriptions, plans, and summaries are counterfeitable; artifacts that run are not.
- Silent interventions are worse than failures. Anything your scaffolding does to the agent without telling it will get explained by the agent — wrongly — and in a system with memory, wrong explanations compound.
- Provenance-tag every decision, or accept that you can't tell your agent's behavior from your error handling's.
After the repricing, I re-sent the exact instruction the entity had once politely acknowledged and ignored. It became a first-class goal at classification confidence 1.00, executed real code on tick 11, and produced a CSV with twenty live rows in it. Then, later in the run, it tried the old trick — describing the scraper instead of running it — and the progress heuristic refused to count it, in a log line I'd built for exactly that moment:
[doing] write_file described but did not run: run it with execute_code
The full architecture, the run data, and the observation paper are in the repo: github.com/sergioavilax/prometheus.