A recent talk by IndyDevDan 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 have run a team of AI agents on a regulated fintech platform since mid-2026, and agents on a streaming platform too. The talk gave me names for something I had built step by step without names. This article maps each position to the real system, and it shows the one place where I stay in the loop on purpose.
The starting point: me at the terminal
At first, every piece of work started with me. I opened a terminal, gave an agent a ticket and read its log. Good agents did good work, but they stopped when I stopped. When I slept, the team slept.
The fix was not a better model. It was moving the start of each job away from me.
What starts the work now
Today, almost nothing waits for my prompt. These are the triggers:
| Trigger | What it starts |
|---|---|
| A message in a staff chat group | An intake agent reads it, checks it against past decisions and files a ticket or answers |
| A new ticket in the queue | The lead agent scopes it and gives it to a planner, which splits it into small briefed items for builder agents |
| An approved code change | The change merges, and a staging build follows |
| A clock: every 2 hours | A deploy gate runs the broad checks, builds and deploys staging, then runs smoke tests, sign-in scenarios and a layout check |
| A clock: nightly | The full test suite runs. A red result becomes a ticket for the next batch, not a hold on approved work |
| A clock: every 2 minutes | A usage watcher reads each account’s burn rate and holds new helper agents from 90% of the five-hour window |
None of these needs me. The agents run as long-lived lanes on a cloud server, not on my laptop. The chat webhook moved there after an outage: it once ran on my laptop, and every time the laptop slept, staff messages stopped arriving. On the server, the lanes survive a closed laptop lid and a weekend.
Near the loop: one gate, at production
The team works near the loop with one fixed gate: production. Agents decide everything in staging by themselves: test data, backfills, pipeline runs, recommended copy and tooling choices. They merge code after an independent reviewer agent approves the exact version that merges. They verify each staging build and close the tickets it carries.
I step in for two kinds of decision only:
- A production release. Agents prepare it and verify staging. I say go.
- A business decision. A change to money flows, identity checks, compliance rules or user roles.
That rule is written down, and it is strict in both directions. Agents must not ask me about staging. I had to say this more than once, because a careful agent tends to ask for approval out of habit. Each question that reaches me costs the team the time I take to read it, so a question about staging is a defect.
Out of the loop: the parts nobody watches
Some work runs with no gate at all:
- The nightly full test suite and the two-hour deploy gate.
- Clean-up checks. At each job end, a lane lists orphaned processes (a dev server or tunnel whose parent is gone) and stops its own orphans and any orphan older than 24 hours. This rule came after about 40 orphans built up on one machine, some of them 13 days old.
- Memory. Every new or compacted agent starts with the same rules and its next step from a shared knowledge store. I described it in The memory palace.
Long-running agents need memory more than short ones. An agent that runs for a week loses its context many times. Without a checkpoint and a startup routine, it starts each time as a stranger to its own work.
A small example from my own desk
The same pattern works for one person. To study for interviews, I built a pipeline that turns a script into a narrated video. It runs out of the loop:
- It writes each line with a text-to-speech model.
- It deletes and retries any clip that runs faster than a set speed, because a too-fast clip means the model skipped words.
- When a model reaches its daily quota, the next video moves to the next model, so each video keeps one voice.
- At the end, a second model transcribes each video, and a script compares the transcript with the script. A low match means a line was dropped or the narrator read an instruction aloud.
I read only the final report. The check exists because a narrator once read its own stage directions aloud. I caught that by ear. Now a script catches it.
Where out of the loop went wrong
Not every step out of the loop worked. I built a batch merge process to land approved changes in groups. When one change in a group failed, the whole group failed. On one day, 171 of 175 open changes had an approval, but only 3 of 9 batches had landed. I removed the batch process four days after it became the only way to merge. That story is in The merge train that landed 3 of 9.
Two scheduled agents also went dark on purpose. One run of a duplicate-code detector cost about 7.3 million tokens, and a gap detector would have cost about 1 million tokens per run, at 21 runs a week. Out of the loop does not mean free. A scheduled agent spends tokens every time it fires, whether it finds something or not.
How to measure it
The talk suggests one measure: the number of agents doing useful work for you right now. I agree, with one change. Count the useful work that finishes without your attention, and count the questions that reach you. The first number should go up. The second should go down to the decisions that are truly yours.
What I would tell a team starting with agents
- Move the trigger first. A ticket, a message or a clock should start each job, not you.
- Run agents where they survive you. A server, not a laptop.
- Write down your one gate. For a regulated product, mine is production. Everything before it belongs to the agents.
- Make a question about anything below the gate a defect. Agents learn to ask out of habit.
- Price every scheduled agent. Multiply the tokens per run by the runs per week before you turn it on.
- Check the checker. A loop that runs without you needs a final check that a script can run, not a human ear.
Want this kind of system in your team? Email [email protected].
