Exiting Agent Babysitting: Code Enforces Correctness, Humans Guard Only the Highest-Cost Gates

Engineers who use AI agents often share a familiar experience: you adopt an agent to share the workload, but end up watching over its shoulder like a proctor. Step away for a few minutes, and it might spin in a loop of trial and error, touch configuration files it shouldn't have modified, or report complete success while tests are silently failing.

This situation is often called "agent babysitting." A common assumption is that models simply aren't smart enough yet, and that future model upgrades will let us walk away entirely. But recent engineering postmortems point in a different direction: we end up babysitting not because models are fundamentally weak, but because the surrounding system is only half-built. Many setups rely on a single linear loop (Loop) without topology or flow management (Graph), or draw up workflow diagrams without objective, fail-capable checks.

In Agent Harness Is the Operating System Layer of the AI Era and The Core of an Agent Loop: Trigger Conditions, Stop Conditions, and Verification Criteria, I wrote about environment and loop design for single agents. Bringing multi-agent systems into everyday engineering requires pulling humans out of routine inspection: let deterministic code manage correctness, and keep humans at the gates where undo costs are highest.

Loops Govern Unit Correctness: Checks Must Precede Work and Be Capable of Failing

To help an agent get things right without someone hovering over it, the foundational piece is the loop. As Hanako (@hanakoxbt) framed it, a Loop is essentially a closed state machine: produce → check → correct → repeat until green. Many systems falter at the very first step because they lack genuine checks.

A common pitfall is having another model review the output, which often turns into two LLMs simply agreeing with each other. Another is assuming that no error output implies success, though an absence of errors rarely guarantees logical correctness. In a loop without explicit failure criteria, mistakes repeat until the context window or token budget runs dry. Useful checks generally need to meet two standards:

1. Programmatically decidable: Exit codes are 0, type checks pass, diffs stay strictly within declared files, and claims in reports cite verifiable environment sources.
2. Capable of genuine failure: A check is only as strong as the weakest evidence it accepts. Saying "looks good" costs nothing; a check that can never fail provides no real signal.

Even when unit loops work cleanly, Loops only ensure a single unit turns green—they do not govern the broader architecture or trajectory. If a task is decomposed along the wrong seams, or if independent subtasks are chained together unnecessarily, every node may pass locally while the system as a whole remains slow and produces malformed output. That kind of failure lives outside the individual unit and cannot be resolved by fine-tuning the Loop.

Graphs Govern Topology and Flow: Write Lessons into Structure, Not Prompt Admonitions

The piece that manages macro-level coordination is the Graph. Living between nodes, Graphs handle task splitting, parallel dispatch, deterministic code transformations, and convergence gates. In practice, a few structural habits help keep Graphs reliable:

First, keep node types separated. Steps that do not require model reasoning—regex extraction, format conversion, field filtering, and code builds—are best implemented as deterministic code nodes without paying model inference costs. Worker nodes handling reasoning should each have isolated contexts, preventing shared context windows from degrading into cross-talk and uniform consensus.

Second, distinguish between two feedback edges. Systems generally benefit from two return paths: a short edge that feeds current errors back into the active unit for local retries, and a long edge that extracts structured constraints when a slice repeatedly fails or exposes faulty assumptions, writing those constraints back into upstream task templates or splitting rules. Rollbacks should remain scoped to the affected unit; resetting an entire batch risks discarding work that has already been verified.

Third, write lessons into the structure of the failing layer, not into prompt admonitions. When an agent accidentally modifies a database migrations directory, the typical reaction is to add bold reminders in the prompt telling it not to touch migrations. But as m4lka (@m4lkxx) points out, wishes are not walls; in his seven-layer framework, Yarchi (@undefinedKi) similarly emphasizes that instructions are wishes while permission boundaries are guardrails. Lunar's (@LunarResearcher) complementary approach is sinking instructions down into checks and policies. Because a model will eventually violate prompts again due to attention drift, the real fix is removing write permissions to that directory directly at the tool gateway and sandbox layer, turning the lesson into a structural constraint.

Tier Gates by Undo Cost: Humans Stand Only at Irreversible Endpoints

Stepping back from babysitting does not mean letting go of control. It means organizing approvals around undo cost and blast radius, rather than relying on self-reported confidence:

• Low cost / reversible actions: Editing a single file, running local tests, generating drafts. These can be rolled back quickly through version control and should generally be automated.
• Medium cost / localized impact: Refactoring shared utilities, updating dependencies, opening PRs. These should require deterministic test passes and compliant traces, moving into a queue for review.
• High cost / irreversible actions: Running database migrations, deleting remote data, sending external communications, executing financial operations. Lanes like these should remain closed to automatic approval by default. Regardless of how high a model rates its own output, the final trigger belongs to a human with operational responsibility.

Supporting these checks and gates requires structured evaluation (Evals). Starting with an LLM judge scoring outputs from 1 to 5 and shipping once scores hit 95% often misses edge cases in production. anshul (@luhsnaa) outlined a practical progression:

1. Read roughly 100 raw traces to understand real failure modes firsthand;
2. Prune minor failures that don't alter system decisions, since everyday noise rarely justifies a dedicated eval;
3. Binarize primary failure patterns into code-level pass/fail assertions;
4. Curate reference datasets, separating a capability set (which explores boundaries and can tolerate a ~70% pass rate) from a regression set (which guards against regressions and should remain near 100%);
5. Introduce automated judges later in the sequence, validating their accuracy using True Positive Rates (TPR) and True Negative Rates (TNR). For tasks that must succeed reliably every time, evaluate consecutive passes with pass^k rather than relying on an occasional pass@1.

My Own Small-Scale Version

While maintaining perryOS day-to-day, I have settled on a few specific habits:

• The main agent handles decomposition and acceptance: It focuses on task decomposition, dispatching to workers, merging changes, and final verification, without writing business code directly, preventing its context window from filling with implementation minutiae.
• Sub-agents do not touch version history: Worker agents do not run git add or git commit. Committing to version history is a higher-cost gate guarded centrally at the outer layer by the main agent, leaving sub-agents to only modify files in the working tree.
• Verify with system evidence, not by watching the process: Acceptance relies on reading git diff to confirm the blast radius is bounded, and running a full test suite, type check, and lint pass during integration. Compiler and test exit codes are much more trustworthy than self-reports.
• Watch out for false completion: Seeing a terminal state show "done" doesn't immediately mean the task is finished—it might just be an idle pause waiting on a tool call. Inspect the final output to confirm the objective was actually delivered before stepping in.

What I'm Still Unsure About

Separating loops, graphs, and irreversible gates is conceptually straightforward, but a few questions remain in production:

First is judging reversibility boundaries. Software carries many implicit dependencies. A minor CSS or markup edit might alter state recalculations or increase API polling frequency, triggering rate limits under load. Deciding how deeply automated checks must inspect changes to catch subtle side effects without over-blocking remains challenging.

Second is balancing setup costs against task scale. Building out explicit Graphs, deterministic test fixtures, and reliable regression suites requires upfront effort. For ad-hoc scripts or experiments that only run for a few days, setting up that infrastructure can take longer than simply watching the process directly. Finding the right threshold where the investment pays off is still an open question.

Questions I Want to Figure Out Next

• How can feature-writing agents automatically generate objective, high-quality acceptance tests for specific tasks with minimal human input, while avoiding hallucinations in the test assertions themselves?
• As long-term constraints accumulate in Graph rules and templates, how can we systematically detect and prune defensive rules that become obsolete as underlying models improve?
• When multiple parallel worker agents finish their local units, can semantic conflicts during multi-way merges be arbitrated more automatically through explicit rules?

References

• "Loops and Graphs: how to stop babysitting agents and only approve the last step (full course)": Published by Hanako (@hanakoxbt) on X, August 23, 2026. Argues that stepping back from babysitting requires separating Loops (intra-node self-correction until green) from Graphs (inter-node task orchestration, decomposition, parallelism, and feedback edges), emphasizing that checks must be programmatically decidable and capable of failing, leaving humans at high-cost gates.
• "Harness, Loops, Graphs: What Each Layer Fixes and What It Breaks": Published by m4lka (@m4lkxx) on X, October 25, 2026. Argues that Harnesses, Loops, and Graphs form a bottom-up ladder; notes that check strength is determined by the weakest evidence accepted, wishes are not walls, gates must be tiered by undo cost, and lessons belong in the structure of the failing layer.
• "Harness Engineering: The Complete Guide to Building AI Agents That Don't Fall Apart": Published by Lunar (@LunarResearcher) on X, September 6, 2026. Outlines the Harness engineering framework where models handle reasoning and harnesses supply structure, emphasizing upfront task contracts, tool gateway validation, environment evidence, and sinking instructions into checks and policies.
• "How to Build a Production AI Agent: The 7 Layers Between the Model and the Result (Full Guide)": Published by Yarchi (@undefinedKi) on X, October 30, 2026. Introduces a seven-layer architecture for production agents, arguing that instructions are wishes while permission boundaries are guardrails, autonomy should be granted by risk tier, and external communication, data deletion, and financial actions require human approval.
• "everything you need to know about agent EVALS": Published by anshul (@luhsnaa) on X, November 1, 2026. Provides a practical roadmap for agent evals: reading raw traces, eliminating non-actionable failures, binarizing code checks, and splitting golden datasets into capability and regression sets, noting that automated LLM judges belong later and critical tasks must be evaluated via pass^k.