Every unstructured, context-free prompt you send to an agent is a token cost you're paying to re-establish state. The agent starts cold every single time. It guesses what your project is, re-reads files it's already seen, and makes confident decisions with incomplete information.
Multiply that across a team, across a day, across a full codebase. That's your AI spend right now.
This is exactly the kind of waste ELI was built to catch. When you have no visibility into which agents are running what, how often, and with how much context, your costs don't compound productively. They just compound. Loop engineering is how you fix the architecture. Visibility is how you stay in control of what that architecture is actually spending.
A loop needs five things and one place to hold state. Here's each one and why it exists.
1. Automations
An automation is a prompt on a schedule. You define what the agent should look for, how often, and where it runs. Findings surface to you. Empty runs archive themselves.
Practical uses out of the box:
- Daily CI failure summaries
- Issue triage on new tickets
- Bug detection on recent commits
- Release notes generation
In Claude Code you get /loop for recurring runs, cron for scheduling, and GitHub Actions if you want it running after you close the laptop. There's also /goal, which keeps going until a condition you define is actually true, with a separate model checking completion so the agent that did the work isn't the one grading it.
You stop going to check. Findings come to you.
2. Worktrees
Run more than one agent at a time without worktrees and files start colliding immediately. Two agents writing to the same file is the same problem as two engineers committing to the same lines without talking first.
A git worktree gives each agent its own working directory on its own branch. They share repo history but cannot touch each other's checkout. Claude Code has git worktree, a --worktree flag, and isolation: worktree for subagents.
This is what makes parallelism actually work instead of creating a mess you spend the afternoon untangling.
3. Skills
A skill is a folder with a SKILL.md inside. It holds your project conventions, build steps, the "we never do it this way because of that one production incident." Written once, read by the agent on every run.
Without skills, the loop re-derives your entire codebase from scratch every single cycle. That's wasted tokens and compounding inaccuracy. With skills:
- The agent starts informed instead of guessing
- Context stops being re-purchased on every run
- Your costs become more predictable over time
Skills are one of the highest-leverage things you can invest an hour in. They pay for themselves fast.
4. Connectors
A loop that can only see the filesystem is a limited loop. MCP-based connectors let your agent:
- Read your issue tracker
- Query your database
- Hit a staging API
- Post to Slack
- Open a PR
Both Claude Code and Codex speak MCP, so connectors built for one mostly work in the other. This is the difference between an agent that tells you what it would do and a loop that actually does it. Updates the ticket, opens the PR, pings the channel when CI is green. By itself.
5. Subagents
The agent that wrote the code is not the right agent to check whether the code is good. It's too close to its own output.
A subagent with different instructions, sometimes a different model entirely, reviews the first agent's work. The standard split:
- One agent explores
- One agent implements
- One agent verifies against the spec
You define these in .codex/agents/ as TOML files or as agent teams in .claude/agents/. Your security reviewer can be a large, high-effort model. Your explorer can be something fast and cheap. You spend tokens where a second opinion earns its keep, and nowhere else.
Memory
A markdown file. A Linear board. Anything outside the conversation that holds what's done and what's next.
The agent forgets between runs. The repo doesn't. This is how the loop tomorrow picks up where today stopped without re-doing work or re-buying context you already paid for.
What this looks like running
An automation fires every morning. It calls a triage skill that reads yesterday's CI failures, open issues, and recent commits, then writes findings to a state file.
For each finding worth acting on, the loop opens an isolated worktree and sends a subagent to draft the fix. A second subagent reviews that draft against project skills and existing tests. Connectors open the PR and update the ticket. Anything the loop cannot handle lands in a triage inbox for you.
You designed it once. You did not prompt any of those individual steps. The loop runs, the context is persistent, and your token spend is predictable because the scope of each run is defined upfront. That last point is what most teams miss when their AI costs start surprising them.
What to watch out for
Token costs can spiral fast if your loops are not scoped properly. A loop running unattended is also a loop making mistakes unattended. Quality does not improve automatically. It requires a verifier subagent you actually trust, and it requires you reviewing what ships.
