Start With a Control Surface, Not a Prompt
The mistake in most overnight agent runs is treating autonomy as a longer conversation. A frontier model can stay useful for a while, but the transcript eventually becomes a junk drawer: stale assumptions, partial plans, failed attempts, hidden tool state, and soft commitments the model may or may not honor. The harness has to be the durable system. The model should be a worker inside it.
Design the harness around a small control surface: goal, phase, allowed tools, working directory, state pointer, budget, exit criteria, and evidence path. Everything else should live outside the active context. Keep the repo-level identity file lean: architecture invariants, routing pointers, hard constraints, and links to deeper playbooks. Do not paste the entire operating manual into every run. The strongest systems use identity as an index, not as a memory dump.
That control surface should be hostile to ambiguity. “Build the feature” is not a phase. “Implement the approved spec in worktree X, modify only packages A and B, run command Y, write proof to Z, stop on migration conflict” is a phase. The goal is not to make the model obedient by wording alone. The goal is to make the surrounding process narrow enough that disobedience is observable and recoverable.
Split Autonomy Into Phases
Once the harness owns the control surface, split the run into fresh-context phases. A useful default is research, spec, build, verify, review, retrospective. Research can be parallel and cheap. Spec should compress uncertainty into concrete acceptance criteria. Build is where expensive models earn their keep. Verify should be deterministic first and model-assisted second. Review should produce ranked findings, not broad commentary. Retrospective updates memory only when there is a repeatable lesson.
This is where frontier-token discipline matters. Use cheaper or less scarce models to inspect the codebase, draft the PRD, identify prior art, enumerate risks, and adversarially question the plan. Run a “grill me” pass before implementation: force the system to challenge scope, missing data, migration risk, testability, and hidden UX requirements. Only after the spec is coherent should the harness hand a precise implementation prompt to the frontier model.
Avoid monolithic loops that keep asking the same session to research, build, debug, remember, and self-review. Context carries emotional residue from failed attempts. Fresh sessions at phase boundaries reduce drift and make costs legible. The artifact passed forward should be a spec, patch, log, or verdict, not the whole reasoning trail.
Make Verification a State Machine
The hard boundary between a toy loop and an engineered loop is verification. Natural-language instructions like “make sure tests pass” are weak. A harness should advance state only after code-based gates pass: lint, typecheck, unit tests, integration tests, Playwright traces, migration dry-runs, security scans, or domain-specific probes. When possible, require proof of work: captured command output, test result hashes, screenshots, videos, coverage reports, or log excerpts written to a known path.
Model critique still helps, but it should sit behind deterministic evidence. A second model can review the patch against the spec, classify failures, or dedupe findings from parallel review agents. It should not be the sole judge of completion. If the build agent claims success but the harness cannot find the expected artifact, state does not advance.
Treat repeated failures as harness bugs. If agents keep editing forbidden directories, add a pre-tool hook that blocks those paths. If they keep forgetting a design invariant, promote it to a concise gotcha in persistent memory. If they keep claiming they ran browser tests, require a trace file or video. The point is not to write more pleading instructions. It is to turn failure modes into gates, hooks, and smaller state transitions.
Parallelize Only Across Isolated Boundaries
Parallelism is where long-loop systems get real leverage, but it also creates the easiest mess. Use parallel agents for independent analysis: quality review, security review, performance review, test-failure diagnosis, API inventory, migration risk. Have them return findings to the orchestrator, then dedupe and rank. Do not let several broad agents mutate the same tree unless your harness can isolate and reconcile their work.
For implementation parallelism, isolate aggressively: separate git worktrees, separate branches, branched databases, fixture copies, per-agent logs, and explicit ownership of files or packages. If the task touches shared contracts, serialize the contract decision first. Otherwise you get fast conflict generation, not fast delivery. The orchestrator should know which worker owns which scope and should reject patches that cross boundaries without an escalation state.
External state should live outside the transcript. A Postgres or Neon table, local SQLite database, or structured JSONL log can track task id, phase, model, budget, tool calls, artifacts, retries, and verdicts. That makes the run resumable after a crash and inspectable the next morning. It also lets you build dashboards for token spend and failure hotspots instead of reading thousands of lines of chat history.
Route Models Like Infrastructure
After phase and verification design are in place, model routing becomes a cost-control problem instead of guesswork. Use small models for classification, log summarization, failure bucketing, artifact indexing, and bounded review. Use stronger models for architecture synthesis, adversarial spec review, and high-risk implementation. Use the frontier model when the harness can give it a narrow mission and objective success criteria.
Keep skills small and curated. Large generated skill libraries rot and bloat context. The durable memory should contain hard-won gotchas: migration ordering rules, local test quirks, design-system constraints, forbidden APIs, deployment hazards, client data boundaries. Review this memory on a schedule. Identity changes slowly, skills change moderately, agents change quickly, and tool integrations change whenever APIs or model behavior shift.
A mature harness ends with a retrospective agent, but not one that rewrites the world. It reads logs, identifies repeated avoidable failures, proposes small memory or hook changes, and leaves an audit trail. That closes the loop: expensive model runs produce not only code, but improvements to the system that will run the next job. The central design rule is simple: spend frontier tokens only after the harness has made the work narrow, verifiable, resumable, and cheap to supervise.
Key takeaways
- Treat the harness as the durable system and the model as a replaceable worker inside it.
- Use fresh-context phases, passing artifacts forward instead of carrying the whole conversation.
- Advance state with deterministic gates and proof artifacts, not model claims.
- Parallelize research and review freely, but isolate implementation with worktrees, branches, databases, and file ownership.
- Route expensive models only to narrow, high-leverage phases after cheaper models have compressed uncertainty.
- Maintain small persistent gotchas, hooks, and retrospectives so every failure improves the next run.