The bottleneck in agent-heavy engineering is operations, not prompting.
The most capable coding agent you can hire today is a brilliant engineer with total amnesia. It has read more code than everyone I have ever worked with combined, holds an entire codebase in its head at once, and forgets all of it the moment the session ends. Every morning it shows up having never met you.
Most advice about working with agents is about prompting, as if the right incantation would fix this. It will not, because the problem is not that the agent misunderstands you. The problem is that nothing it understands survives the day. The bottleneck is not prompting. It is operations.
I run coding agents in three places: a personal operations repo where agents keep my notes, records, and plans in order, a few long-running side projects, and the internal AI initiative I started at Fastned, where my day job is leading engineering teams. Fastned builds fast-charging stations for electric cars. My teams there look after the roaming systems behind 80 to 90 percent of last year’s EUR 122.4 million in revenue, on a network that holds 99.9 percent charging uptime. So I do not get to treat “the agent sounded confident” as a quality bar.
What follows is the operating model that emerged from running these fleets, told mostly through the personal repo, because it is the one where I can share the details.
An agent session is a stateless process. If you have run stateless services in production, you already know what to do with one: keep the state somewhere durable and let the process be disposable. For agents, somewhere durable means plain files in a git repo.
My personal repo has a fixed set of root files, each with exactly one job. One holds the live state of every open track. One holds the session log. One defines how the agent and I work together. One is the manual for the system itself. The root set never grows; anything new goes into a work directory. And I, the human, write files in exactly one place: a drop zone called raw, where I throw transcripts, PDFs, and half-formed notes. Every other file in the repo is written by agents.
Two rules make this hold up. Living state belongs in files, never in an agent’s memory features; memory gets only durable facts and pointers to files. And everything is git-versioned, one commit per session, history never rewritten. When something goes wrong, and it does, git blame works on your operations the same way it works on your code.
A fresh session starts by reading a fixed chain of files: who we are to each other, where things stand, and the first hundred lines of the log. Not the whole log. The first hundred lines, which by construction hold the last three sessions.
Caps are what make the budget real. The state file stays under about sixty lines. A log entry gets at most thirty. When the log passes five hundred lines, it rolls into an archive. None of these numbers is sacred; the discipline is.
I added the log cap after the very first session, when the agent read the log unbounded and burned a real slice of its context window on history it did not need. Context is the one resource an agent cannot get more of mid-session, and an agent left alone will cheerfully spend all of it on reading.
Any task the fleet repeats deterministically gets encoded as an executable checklist the agent invokes, never re-improvised.
The session-close ritual runs most often: log entry, state rewrite, one improvement to the system, commit with a message in a fixed format. In that order, no skipping. There are similar written rituals for processing the drop zone, for handing work between agents, for the weekly review, and for verifying the system itself. The full toolkit across the repo and the side projects is about fifty of these installed skills, covering everything from browsing and QA to shipping and design review.
If this sounds like bureaucracy, consider who the bureaucracy is for. A checklist annoys a human because the human remembers the steps. The agent does not, and it executes a written ritual perfectly every time, which is more than I can say for myself and commit messages.
When an agent’s run on a track ends, it writes a handoff file with fixed sections: where things stand, deadlines, next actions, open questions for me, and gotchas. The next agent on that track reads the handoff first and archives it immediately, so a handoff is consumed exactly once.
The gotchas section is where this earns its keep. One real handoff in my repo contains the line “Do not repeat the wrong version”, about a piece of history the previous agent had summarized wrong until I corrected it. The correction now travels with the work. No future agent has to make that mistake to learn from it.
Handoffs also cover the case where the fleet is genuinely a fleet. One day two sessions ran in parallel on different tracks in the same repo, and one session’s closing commit swept in files the other had just produced. The only reason this was a footnote instead of a mess is that the log recorded it explicitly, so every later session knew whose work was where. The failure mode of parallel agents is not conflict; git handles conflict. It is silence.
This is the discipline I would push hardest on any team adopting agents.
Every time the system files change in a way that matters, I run a cold-boot test. Spawn a completely fresh agent whose prompt contains nothing but “read the entry file and follow the protocol”. Ask it six questions: what is the current state, what happened recently, what has failed before, what are the rules, and so on. Grade the answers against the ground-truth files.
The pass criteria are engineering-grade, not vibes. Answers must match specific files. An invented failure is an automatic fail. The agent gets at most eight file reads to answer everything. A single hallucinated file name anywhere fails the run.
The first real run passed: six answers out of six matched ground truth, zero invented file names, eight reads.
The rule that makes this a system rather than a party trick: when a cold boot fails, you fix the files, never the agent. No coaching, no hints, no extra context in the prompt. Fix the files and re-run until it passes. Documentation has quietly become the kind of thing you can test, and the test is an agent.
I said I only write into the drop zone. The other half of that contract is what agents do with what lands there. Everything gets processed: the useful content extracted to wherever it belongs, the source archived verbatim, the extraction logged.
The interesting rule is the contradiction rule. If a new drop contradicts something the files already claim, the agent flags it to me instead of silently overwriting either version. I once dropped in an old PDF of my resume, and the agent came back with three consistency flags where the PDF disagreed with ground truth already in the repo. It did not merge and hope. It behaved like an auditor, which is exactly what you want from the thing that maintains your records.
The agent’s working persona is written down and versioned like everything else. Mine is configured to challenge on sight: open with the verdict, bring the strongest counterargument once at full strength, and then, once a decision is settled, execute it at full speed without relitigating.
Decisions are one-line DECIDED entries in the log, each with its why. Reopening one costs a single line of new evidence; no new evidence, no reopening. Dissent gets logged even when it loses. There is a line in my log recording the agent’s disagreement with a decision I made anyway. I find that line oddly reassuring.
One more piece of configuration that surprises people: “never open with praise” is written down explicitly. Flattery from an agent is worthless, and unless you say so in a file, you will get a lot of it.
The session log has a mandatory failures-and-corrections section, and it has never once been empty.
Two failure classes show up again and again. The first is stale confidence: an agent asserting a fact about a fast-moving ecosystem that a release from a few weeks earlier had already made false. It was caught only because checking claims against live sources is part of the ritual, not an act of suspicion. The second is confident misreading of history: an agent summarizing how something actually went, plausibly and wrongly, until I corrected it. The fix in both cases was the same. The correction went into the files, so no future agent starts from the same wrong place.
The system also improves on a rule rather than a whim: no session ends without one small improvement to the system itself, recorded on its own log line, and skipping requires logging the reason. In practice, that clause means skipping does not happen. A visible debt list lives in the system manual, and sessions burn it down item by item.
Engineering teams are about to run tens of these stateless processes in parallel, whether they have an operating model or not. The individual agents will keep getting smarter, and it will help less than people expect, because a team of brilliant amnesiacs does not become an organization by getting more brilliant. It becomes an organization the way organizations always have: files, protocols, rituals, handoffs, and someone willing to test whether the whole thing still boots.