Start With A Loop, Not A Wish
A coding agent is different from a chat assistant because it can act in your working environment. It can read files, edit code, run terminal commands, inspect test output, and sometimes call connected services through tools. A loop gives that agent a narrow job to repeat until the result is good enough to stop.
The central idea is simple: do not ask the agent to “improve the app.” Ask it to run a cycle. A useful first loop has five parts: a trigger, execution steps, verification, a stopping condition, and a short memory log. For example: “When I type this command, inspect the failing tests, make one focused fix, run the relevant tests again, stop when they pass or after three attempts, then write what changed to `agent-log.md`.”
Good first loops are repeatable and checkable. Fixing lint errors, reducing page load time below a number, updating docs after code changes, or clearing a known class of test failures are better candidates than “make the design nicer.” Subjective work can be looped later, but only when you define a judge, rubric, or score that tells the agent whether it is done.
Choose The Trigger And Tools
Once the loop has a bounded job, decide how it starts. The simplest trigger is manual: you type a command or paste a goal into Claude Code, Codex, Cursor, or another agent. Later, the trigger might be a pull request, a schedule, a production error, or an analytics threshold. Start manually because you can watch the first runs and see where the instructions are vague.
Tools are the agent’s hands. In a coding setup, tools usually include file search, file editing, shell commands, test runners, linters, Git, and sometimes browser automation. MCP, or Model Context Protocol, is a standard way to connect agents to outside tools and data sources, such as issue trackers, monitoring systems, docs, or databases. You do not need MCP for your first loop, but the concept matters: a loop can only verify and act on what its tools can reach.
Write the execution steps like a small procedure, not a motivational prompt. For a test-fix loop: read the failure, identify the smallest likely cause, edit only relevant files, run the narrowest test, broaden to the full suite if narrow tests pass, and report the diff. This keeps the agent from wandering into unrelated refactors.
Make Verification The Boss
The stopping condition is what turns an agent from a talkative helper into a controlled worker. The strongest loops use deterministic verification: tests pass, lint returns zero errors, benchmark time is under 50 ms, CI is green, or no high-priority monitoring issue remains open. The agent can run the check, read the result, and decide whether to continue.
Some goals are not fully deterministic. Architecture cleanup, documentation quality, or “make this simpler” may need an LLM-as-judge step. That means a second review prompt, skill, or sub-agent scores the result against specific criteria: duplication reduced, public API unchanged, tests added, explanation clear, no speculative abstractions. Treat this as less reliable than tests. Add a maximum iteration count and require human approval before larger changes.
A sub-agent is a separate agent instance given a smaller role. In your first loop, use one only if it makes verification cleaner. The main agent can implement a fix while a reviewer sub-agent checks whether the fix matches the goal. This separation helps because the writer and reviewer are not following the exact same mental path. Still, sub-agents spend more tokens and can create noise, so keep them focused.
Add Memory Without Building A Database
Loops get wasteful when each run rediscovers the same facts. A short markdown memory file is enough for a first version. Have the agent read it at the start and append to it at the end. Keep entries compact: date, trigger, files touched, verification command, result, failed attempts, and any rule learned for next time.
For example, a memory note might say: “`npm test -- auth` is the fastest check for login failures. Do not run the full suite until that passes. Previous failure came from stale mock time.” That kind of note prevents repeated exploration and gives the next run context. Context is the information the model can currently see, including your prompt, open files, logs, tool output, and memory. Since context space is limited, memory should be factual and short.
Avoid turning memory into a junk drawer. Do not log every thought or full terminal output. Log decisions that would change the next run. If the loop starts repeating failed fixes, the memory should say what already failed so the agent tries a different path or stops for human input.
Run In Training Mode First
Before you let a loop work unattended, run it in training mode. That means the agent pauses at each stage: after reading context, before editing, before running broad commands, and before declaring success. You are not doing this forever. You are checking whether the loop’s procedure, tools, verification, and stop rules are precise enough.
Set hard limits. A beginner-friendly loop might allow three edit attempts, one narrow verification command per attempt, one broad verification at the end, and no dependency changes without approval. Watch token use as well. Long loops can burn time and money when verification is fuzzy, tools are blocked, or the agent keeps trying variants of the same bad idea.
Your first agent loop should feel almost boring. Trigger it, let it execute a known procedure, verify with a command or rubric, stop cleanly, and write a useful memory note. Once that works, you can move the trigger from manual to scheduled, add MCP-connected data, or split review into sub-agents. The point is not autonomy for its own sake. The point is a repeatable cycle that improves a real task without losing the thread.
Key takeaways
- Build the loop around one repeatable task with an objective definition of done.
- Use manual triggers first, then graduate to schedules, pull requests, or monitoring events.
- Give the agent tools and a procedure, but let verification decide whether it continues or stops.
- Use sub-agents sparingly, mainly for focused review or scoring roles.
- Keep memory in a short markdown log that records facts useful to the next run.
- Limit iterations and require approval when the loop becomes subjective, expensive, or broad.