Sixteen reader agents went through five months of my transcripts, and the ten rules they produced each carry the count that forced it.
In short
For five months I ran a coding agent across three small businesses. In September I stopped adding to it and had sixteen reader agents go back through the transcripts instead. They read each window in full.
What came back contradicted the story I had been telling myself. So I wrote down ten changes, each with the count that forced it. The numbers are specific to my logs. The rules under them work with any agent from any vendor, because none of these failures were about the model.
1. One repository per prompt
Keep every prompt inside one codebase. When a single ask reaches across two, the housekeeping side wins.
In one five day window, asks touching a venture repo and a tooling repo together lost the same day contest on 3 of those 5 days. The tool audit ran. The business change waited.
Cross repo asks get decomposed, and the agent starts with the part it can finish cleanly, which is usually the config or the lint. Split the ask yourself, one repo each, and put the business one first. If you find yourself writing "and while you're in there", open a second prompt.
2. Never fan a prompt into parallel sessions
Run one session per subject.
Eight copies of one prompt produced 229 logged blocks holding 29 real turns of mine. Four sessions on one question produced four answers I reconciled by hand. Across the harness windows, the fan-out ratio ranged from about 1.3 up to nearly 18.
Parallelism feels like speed because the logs fill up. What you get is a reconciliation job that only you can do. If you want breadth, give one session a wider ask. If you want a second opinion, ask once, from a different model, and say it is a check on an existing answer.
3. No cron without a named consumer and a failure alarm
Before you schedule anything, name the person who reads the output and the signal that fires when it breaks.
Two of my scheduled jobs failed for six and seven days before anyone noticed. One failed 7 of its 8 runs. A posting job failed six days running. The noticing became the deliverable.
Agents make scheduling cheap, so you will schedule more than you can watch. Write the consumer into the job description: who opens this, and what decision changes because of it. Add one alarm that fires on absence, since a job that stops producing output looks exactly like a quiet week.
4. Write the definition of done before the first call
Say what will be true when the work is finished, before the agent touches anything.
My worst ratio of logged activity to real change sits under two phrasings: "fix everything" and "implement all". One of those windows closed with the honest line "no code moved".
A vague ask produces confident work on the easiest readable part of your request. The fix costs a sentence. Name the surface, name the observable state after the change, and say how you will check. If the definition cannot fail, it is not a definition.
5. Grade on sent, deployed, sold
Judge a session by what exists outside it.
My close-outs say DONE. The outcome columns for the same period say 0 sales, 0 placements and 0 funding across 12 venture windows. One live production change in 93 turns on one product. Three messages sent in 287 turns on another.
Every agent writes its own summary, and vocabulary is free. Take the grade out of the session: a URL, a timestamp, an order number, a reply from a person. A commit hash is an unanswered request until you can see the thing running.
6. Cap agent-directed work at one day a week
Work on the agent itself is work. Give it a slice and hold the slice.
Across a 25 day window, 61 per cent of my real turns were directed at the agent: its rules, its hooks, its measurement. In the same 25 days I made 95 business asks against 139 asks about rules and punishment.
Improving the tool feels like compounding, and it produces visible artifacts every hour, so it beats slower business work whenever the two meet in one day. Pick the day. Refuse tooling work inside any session that opened with a business ask, and hold it for the slot.
7. Correct the agent twice on one thing, then stop the session
A second correction on the same point means the lane is dead for today.
My record has the same ask returning six times on one widget, six times on one publishing question and three times on one table. None of those repeats ended with the thing working.
The third attempt rarely lands, because you are correcting inside a context that already holds two wrong ones. Close it. Start clean with what the failures taught you, or do that piece by hand. The repeat is information: the ask was ambiguous, or the task sits outside what this tool does well.
8. Ban the measurement-instead-of-fix trade by name
If you asked for a fix, a measurement is a refusal.
At least nine days in my record went that way. One day went to arguing about caching and latency while the outreach it was measuring had produced a single reply. Nine identical status probes ran in one window where 65 per cent of the logged lines were repeats. A week went to a detector that scored 0.61 and was retired, while zero of the images it was built for shipped.
The output looks rigorous, it arrives fast, and it answers a question you did have. That is why it needs a name. Say it in the prompt: I am asking for a change, and a number is not an acceptable answer. Then ask for the visible state after the change.
9. Kill any rule whose enforcement you have not watched fire
A rule you have never seen block anything is decoration.
One of my gates sat on disk and unwired for over a month while my own rules file said it was refusing my close-outs. Two readers found it independently by checking the config rather than the prose. Elsewhere a scheduled template kept being re-asked a month after the job behind it was retired.
Prose accumulates faster than enforcement. Past about a page, the agent starts inferring from the mass of rules instead of reading you, and every rule you add dilutes the ones that matter. Watch each control fire once on real input, print how often it fires wrongly, and delete the rest.
10. Read the machine share before quoting any usage number
Find out how much of your log is the tool talking to itself before you quote any figure from it.
In my five months, 59 per cent of the logged lines were machine generated: heartbeats, polling, auto continues, retries. One idle polling loop ran roughly 2,500 turns over six weeks and produced nothing. Two months of my log held zero human prompts at all. Every usage number I had used before that pass carried that freight, and a raw prompt count overstated my real input by a factor of 2.45.
Before you quote usage to justify a plan or a budget, split the log. The honest denominator is your own turns.
What I would keep
The building was fine. Three real things came out of those months and they hold up. The gap sits between a thing existing and a person outside the room using it, and nine of the ten rules above are versions of stopping one step short of that.
If you take one, take the fifth. Grade on what left the building. The rest follows from it.