How to Run AI Agents Day to Day: An Operator's Routine

Getting agents to work is the first problem. The second one arrives a few weeks later and is less interesting to talk about: you now have several of them running, they produce a great deal, and somebody has to decide what to ask for, check what comes back and release it. That somebody is you.

This is an article about that second problem. It is for builders who already have agents doing real work and want a routine for running them. It is about the shape of the day more than any one tool. The ideas come from my book The Operator’s Handbook, written for one person running a fleet of agents, though most of it holds for a small team too.

The limit is your attention, not the agents

The first thing agents give you is volume. Ask for ten variations and you get ten. Start five threads before lunch and you will have five sets of results by teatime. It feels like progress, and it is a poor guide to whether you are getting anywhere.

Started is a cost. Finished is a result.

With agents, the number of things you could have running at once is effectively unlimited. The constraint is you, because each thread eventually needs your attention: to brief it, unblock it, review its output and decide what happens next. Your attention has a ceiling, and the ceiling is much lower than the number of threads you could run. The working rule is short: run as many threads as you can review, and not one more.

Two habits keep you under the ceiling.

The first is a single list of everything in flight. An operator can have a client project, two internal tools, a draft, a research question and a migration that has been ninety per cent done for three weeks. Without one place that lists all of it, the operation cannot be seen whole, and what cannot be seen whole cannot be steered.

The second is to give each thread exactly one outcome. Not one outcome and a few related tidy-ups, and not two outcomes that happen to touch the same files. It is the most effective rule for keeping parallel agent work reviewable, and it is broken constantly, usually with the best intentions.

Give the day a shape

A day of agent work without a shape turns into reacting to whichever thread finished last. Three fixed points are enough to prevent that.

The morning review. This is the twenty minutes that decide whether the rest of the day goes anywhere. It is not catching up and it is not checking messages. It is a small, structured act of triage that takes everything that has accumulated since yesterday's close and narrows it down to the handful of outcomes you will pursue today.

Three outcomes. Pick three for the day. Not three tasks, not thirty, and not one. Three outcomes, each something that will be visibly finished by the close: shipped, sent, decided or published. The constraint is useful precisely because it feels too small.

A finish and a close. Every session should end with the same small ritual: verify, ship, note, stop. It takes five minutes, and it is the difference between a session that finished and a session that merely ended because you ran out of time. Then the last twenty minutes of the day are for the close, which most operators skip because it feels optional. The close is not about today. It is about tomorrow's morning review, and about the evening that sits between them.

Write briefs you can check

A brief is the document that turns your intention into an agent's work. It can be a single sentence or a page, but in every case it does the same job: it says what you want, what the agent needs to know, what it must not do and how you will judge the result. When the brief is good, the work tends to be good. When the brief is poor, the work is often impressively, confidently poor.

If you change only one habit, change this one: write the definition of done before you write the task. Not after, as an afterthought, and not implicitly, assuming the agent will know. First.

A quick test before starting anything is three questions. What do we want? Why now? How will I know? They take about a minute to answer, and work that fails them tends to consume hours before anyone notices it was never worth doing. The third question matters most. If you cannot say how you would know the work is right, you are not ready to ask for it.

Review on evidence

Agents are reassuring. They tell you the work is complete, the tests pass, the edge cases are handled and the change is ready for review. Most of the time they are right. But reassurance is not evidence, and an operator who accepts one in place of the other will, sooner or later, ship something that was not what it claimed to be.

The plainest form of this is the summary.

The summary is the story. The diff is what happened.

Agent summaries are clear, well organised, confident and easy to read. They are also written by the party that did the work, with all the natural tendency that implies to emphasise what went well and pass lightly over what did not. Read the summary, by all means. But read the diff first.

Be a little wary of passing checks as well. Green is good news, and most of the time it means what it seems to mean. It means the checks passed. It does not mean the checks were right.

None of this requires reviewing everything at full depth. Some changes are trivial and some are dangerous, and treating them all the same either wastes your time on the trivial or skimps on the dangerous. Order your checks by cost, cheapest first, and stop as soon as you have enough confidence for the risk involved.

Release small, and keep a way back

The most reliable release discipline is also the simplest: ship small, ship often. Small changes, each one reviewed and released on its own, in a steady stream. Agents make this easier than ever, and they also make the opposite mistake easier than ever, so it is worth being deliberate about.

Small releases only work if you can reverse them.

If you cannot undo it, you did not release it. You committed to it.

An operation that can roll back in a minute can afford to ship boldly. One that cannot has to ship nervously, slowly and rarely. Rollback is not an emergency procedure. It should be designed in, tested and kept working.

The same thinking sorts your decisions. Some are two-way doors: trying a new layout, picking a tool for a trial, choosing which project to work on this week. Others are one-way: deleting data, signing a contract, publishing something to a large audience. Move quickly through the first kind and slow down for the second.

When something does go wrong, write an incident note. Not a formal post-mortem, just a short, structured note that captures what happened, why, and what will change. It takes fifteen minutes. And for anything you do more than once, such as deploying a project, restoring a backup or rotating a credential, keep a written procedure. The person who will need it is you, months from now, having forgotten every detail.

What to take from this

• Count finished outcomes, not started threads.
• Run only as many threads as you can properly review.
• Keep one list of everything in flight, and give each thread one outcome.
• Start the day with a twenty-minute review and choose three outcomes.
• End every session the same way: verify, ship, note, stop.
• Write the definition of done before the task.
• Read the diff before the summary, and ask for evidence in place of reassurance.
• Ship small, keep rollback working, and write a short note after every incident.

What agents cannot do is decide what is worth doing, what good looks like, and whether the result is good enough to carry your name. If you want the full routine, The Operator’s Handbook: Running a one-person machine with AI agents, day by day covers the daily rhythm, briefs, memory, the project register, review and release in 100 chapters, each with a labelled diagram. It is a 314-page PDF and costs £9 on Gumroad: https://matsiems.com/books/the-operators-handbook.