IndyDevDan has a talk, Elite agentic engineers are leaving the loop, that sorts agent work into three positions. In the loop, you write each prompt and watch the agent. Near the loop, the agent starts on its own and you step in to approve, answer or correct. Out of the loop, a schedule or an event runs the work and you look at the results.
I built most of my agent setup step by step without ever naming these positions, so the talk was useful to me mostly as vocabulary. Below I map each position to what we actually run, and I point out the one place where I stay in the loop on purpose.
Getting myself out of the terminal
At first, every job started with me. I opened a terminal, gave an agent a task and watched its output. The agents did good work, but they could only work while I was there to start them.
A better model does not fix this problem. The fix is to change what starts each job. When an event or a schedule starts the work instead of a person, the work continues while that person is away.
In our setup, three kinds of events start work without me:
- A request from a team member becomes a task. An agent reads it and decides if it needs work or only an answer.
- A new task goes to a planning agent, which divides it into small parts for builder agents.
- When a reviewer approves a change, the change merges and a new test build starts.
Schedules start the rest of the work:
- A regular check builds the test environment and confirms that it works.
- A full test run happens every night. A failure becomes a new task, so it does not block work that is already finished.
- A usage check stops new agents from starting before we reach our account limits.
All of this runs on a server, not on my laptop. A laptop stops when you close it, but a server continues to run, so the work continues through nights and weekends.
The one gate I kept
The team works near the loop with a single fixed gate, and that gate is the release to production. Agents decide everything in the test environment by themselves, from test data to tooling choices. They merge code after an independent reviewer agent approves the exact version that merges. They check each test build and close the tasks it carries.
I step in for two things. One is a production release, where the agents prepare it and check the test environment and I say go. The other is a business decision, which means a change to what the product does or to the rules it follows.
This rule is written down, and it works in both directions. Agents must not ask me about the test environment. I had to say that more than once, because a careful agent asks for approval out of habit. Every question that reaches me costs the team the time I take to read it, so I treat a question about the test environment as a defect.
Some work has no gate at all. The nightly test run and the regular check just run. Clean-up checks run too: when a job ends, an agent looks for processes it left behind, such as a dev server whose parent process is gone, and stops them. This rule exists because forgotten processes pile up quietly on a shared machine.
Memory belongs here as well. Every new or compacted agent starts with the same rules and its next step, pulled from a shared knowledge store. I wrote about it in The memory palace. I think long-running agents need this more than short ones. An agent that runs for a week loses its context many times, and without a checkpoint and a startup routine it starts each time as a stranger to its own work.
A small version on my own desk
The same pattern works for one person. I post design shots of Happy Tally, my scoring app for events, to Dribbble, and the posting runs out of the loop. A scheduler starts it at 10:00 and 19:00, and it takes the next shot from a queue, fills in the title, description and tags through my signed-in browser, and publishes it. It posts at most one shot per run and skips a run that comes less than 6 hours after the last post. Before it publishes, it checks that the title and tags went in and that the shot isn’t hidden from my profile. If a check fails, it stops, leaves the draft open for me to look at and sends me a notification, and the next run tries again.
The gate is the same as at work, only smaller. A shot posts only after I mark it approved in the queue, so I decide what goes out and the schedule decides when.
Where I went too far out
Not every step out of the loop worked. I built a batch merge process to land approved changes in groups, and when one change in a group failed, the whole group failed. One day, 171 of 175 open changes had an approval, but only 3 of 9 batches had landed. I removed the process four days after it became the only way to merge. The full story is in The merge train that landed 3 of 9.
I also kept two scheduled agents off on purpose. One run of the first, a check for duplicated code, cost about 7.3 million tokens. The second, another scheduled check, would cost about 1 million tokens on every run, and it would run many times a week. Out of the loop isn’t free. A scheduled agent spends tokens every time it starts, whether it finds anything or not.
The talk suggests counting the agents doing useful work for you right now. I’d change that a little. I count the useful work that finishes without my attention, and I count the questions that reach me. The first number should go up. The second should shrink to the decisions that are really mine.
Want this kind of system in your team? Email hello@jeffkent.dev.
