The coding agent is usually not the hard part of an agentic loop. It is everything around it: task selection, the sandbox, branch rules, review, permissions, and what happens when a run gets weird.
The loop itself is almost boring. Take a task from a queue, run it through a coding harness, validate, commit, then grab the next item. Basically a for loop with an agent inside.
Making that loop useful, and safe enough to leave running, is the real work. A few things I learned while building mine.
Keep the agents contained
I run the agents inside Docker containers, with Codex or OpenCode in headless mode. Not because Docker makes the agent smarter. It just keeps the environment boring and limits what the agent can touch.
It also makes failures less mysterious. I know what was installed and which files were available. I am not guessing what the agent found somewhere on my machine.
Implementation is not the last step
Once the code exists, the task is not done. I run a separate review agent after implementation. It either approves the change or sends it back with feedback.
Keeping those steps separate matters. The agent that wrote the code already made a bunch of assumptions. Asking it to review itself mostly gives those same assumptions another pass.
Interactive and headless modes need different rules
Take another look at AGENTS.md before putting it inside a loop. Instructions that work nicely in an interactive session can be wrong in headless mode.
An interactive agent can just stop and ask me something. A headless one cannot. It needs to know when to skip work, when to open a ticket, how to report a block, maybe when to give up entirely.
Same agent, different rules.
Use different loops for different jobs
I prefer small, specialized loops over one big loop doing everything. I have different ones for review and cleanup, plus e2e tests and security work.
They do not all end the same way. Some produce pull requests. Some only create tickets. A test loop might just report what broke. That is enough.
The predictable loops can move to cloud workflows. I do this for cleanup work. The workflow only picks up tasks with the right label, does its narrow job, and leaves everything else alone.
Design around branches and labels
Branching is part of the loop design, not something to decide later. Some tasks get one branch each. Related cleanup tasks might need to stay together on a shared branch.
If the loop does not know this upfront, you get conflicting changes. Or work that belongs together gets split across several PRs for no good reason.
And use labels a lot. Each loop should only see tasks carrying its label. That label is the boundary. Without it, sooner or later, the wrong loop picks up the wrong work.
The loop can stay simple. The system around it cannot be vague. Give the agent a narrow job, a controlled place to run, and a clear way out when the task does not fit.
What did I miss? If you are building similar loops, share what worked for you. Especially the ugly parts. Those are usually the useful ones.
Top comments (0)