Why Your AI Coding Agents Fail After 20 Minutes (And How to Fix It)

The holy grail of AI-assisted dev work isn’t asking a model to write a single function. It’s launching an unsupervised, 8-hour background pipeline and coming back to fully validated, production-ready code.

People call this “Loop Engineering”—slapping an LLM inside an infinite loop and hoping it autocorrects its way to success.

Here’s the cold truth: Loop engineering alone doesn’t scale.

Even top-tier models running locally inside Colima can’t keep going indefinitely on their own. They hit context degradation, loop endlessly on edge cases, or lose the plot completely.

If you actually want long-running, autonomous execution, you don’t need a better prompt loop. You need Context Engineering.

Why long contexts won’t save you

Most developers handle long tasks with one of two flawed strategies:

• Relying on CLI/IDE harness compaction. When context fills up, harnesses silently compress the history. The problem? Compaction discards details. You might lose the exact edge-case requirement or the validation step needed to finish safely.
• Brute-forcing massive context windows. Beyond the high cost and latency, research (like the Lost in the Middle phenomenon) consistently proves models degrade as context grows.

The bottleneck: bigger context windows aren’t saving us anytime soon. The secret to long-running pipelines isn’t more memory—it’s controlled memory.

Step 1: outsource to single-task subagents

If you stop reading here, doing this one thing will improve your agent workflows by 90%:

Stop letting the root session do the heavy lifting.

Use your main LLM session strictly as a manager. Have it delegate work to specialized subagents with isolated context windows.

[Main Manager Session]
├── Task Agent (single-responsibility)
├── Adversarial Reviewer Agent
└── Fixer Agent

The adversarial pattern

Take a page from high-scale migration playbooks (like Jarred Sumner’s Rust migrations):

• Task agent — implements the feature or refactor.
• Adversarial agent — tries to break the implementation and find flaws.
• Fixer agent — takes the critique and resolves the failure.

For complex logic, force the pipeline to rerun the loop 2 or 3 times. Small, single-responsibility subagents don’t suffer from context compaction because their scope is microscopic.

Step 2: build a DAG harness (not a complex framework)

When subagents aren’t enough for massive jobs, you move from context engineering to graph engineering.

You don’t need heavyweight orchestration frameworks to build this. You need a simple Directed Acyclic Graph (DAG) workflow engine.

┌────────┐      ┌────────┐      ┌────────┐
│ Node A │ ───► │ Node B │ ───► │ Node C │
└────────┘      └────────┘      └────────┘
     │                               ▲
     └───────────────────────────────┘

The minimal schema is two pieces:

• Node — id, prompt, dependency_ids, exit_0_checks, and optionally workdir / timeout.
• Runner — validates graph sanity (unique IDs, no cycles), then executes ready nodes in parallel under a concurrency cap.

The 3 golden rules for unsupervised pipelines

Most open-source agent frameworks skip these three critical mechanics. Without them, your 8-hour run will fail.

1. Zero history pollution (context isolation)

Every node attempt gets a 100% fresh agent session. It only sees its prompt and the exact outputs of its dependencies. It never sees global pipeline history.

2. Disk-as-memory (resume-on-crash)

The file system is your source of truth. Write prompts, outputs, and validation state directly to disk (/run_dir). If a node passes, skip it on retry. If the harness crashes at hour 7, you resume at hour 7—not hour 0.

3. The harness is the judge (not the LLM)

Never ask the model if its code works. A node is marked complete only when external shell checks (unit tests, linters, types) return an exit 0. Period.

The takeaway

Why build this yourself instead of using off-the-shelf tools?

Because most current agent tools aren’t workflow engines. They try to be smart inside a single long-lived thread. Long-running automation requires dynamically partitioning large problems into atomic sub-graphs and executing them via a lightweight, deterministic runner.

Keep your runner boring, keep your context isolated, and put the model on a strict leash (wall-clock limits, spend caps, and containerized sandboxes).

That’s how you go from babying a chatbot to running 8-hour unsupervised builds that actually land cleanly.