Loop Engineering shifts you from prompting agents to designing the loop that runs them. A control plane for autonomous AI coding agents.

Instead of interacting with an agent turn-by-turn, you define a goal and a scope. The loop takes it from there — it runs your AI agent inside a bounded workspace, independently verifies the result against deterministic conditions, and retries with a different strategy on failure. It stops only when every condition passes.

The Control Plane vs. The Project Plane

The system enforces two planes inside your Git repository:

• Control Plane (.agentic/): governs how the work is done (path ownership, protocol, event log, verification scripts).
• Project Plane (src/, tests/, package.json, etc.): the actual application code your agent produces.

The Maker agent writes code only in the Project Plane. It can never touch the Control Plane. A separate, isolated Verifier agent checks the work without access to the Maker's logs or reasoning. Only the Verifier can declare a goal complete.

The Goal Lifecycle

The execution paradigm relies on structured goal states rather than conversational turns. Every goal follows a strict, multi-phase sequence:

1. Phase 1 - Registration: A goal contract is created. It captures the exact git_sha_before, locks path scope (allowed/denied write paths), and defines rigid deterministic completion conditions (e.g., exit codes must equal 0).
2. Phase 2 - Maker Implementation: The agent acts securely. It writes code to authorized paths, tests its assumptions, and logs its strategies. If an approach fails, the loop iteratively forces a new hypothesis rather than spamming identical code.
3. Phase 3 - The Scope Gate: Before any verification occurs, a scope gate performs a diff analysis. If the agent modified anything outside the allowed_write_paths, touched protected .env credentials, or mutated the control plane, the build is instantly rejected.
4. Phase 4 - Independent Verification: This is the crucial layer. An isolated Verifier looks purely at completion conditions against the candidate Git tree. It contains NO access to the maker's self-assessed "confidence" or conversational logs.
5. Phase 5 - Knowledge Graph Transaction: Once verified, structural details (classes, APIs, exports) are mapped into an immutable release within the localized Source Knowledge Graph, effectively keeping project memory updated securely.

Workspace and Ownership Protocol

In an agentic framework, letting AI write everywhere is a recipe for system collapse. Workspace governance enforces boundaries deterministically:

• Explicit Classifications: Your workspace.json controls everything. It maps which paths are source roots, test suites, generated artifacts, or control data.
• Default Deny Policy: Any undefined path is strictly non-writable.
• Immutable Control Plane: Makers can never modify CONTROL_PLANE, RUNTIME_STATE, or KNOWLEDGE_GENERATED paths. A specific `SYSTEM_MAINTENANCE` authorization is required for those actions, executed strictly by a Protocol Maintainer agent.

Loop Autonomy and Strategy Rules

Autonomy is bounded by goal, path scope, budgets, constraints, and deterministic completion conditions. The loop may change its implementation strategy, but it can never alter the user's product meaning.

• Finite Retries: Retrying the same failed strategy without new evidence is explicitly forbidden. Retry limits are finite (e.g., 3 simple attempts, 7 complex attempts).
• Immutable Tests: A loop may not weaken, delete, or skip a failing test unless the user goal explicitly authorizes that requirement change. No changing tests just to "make it pass".
• Falsification Logging: Each failed attempt meticulously records its hypothesis, evidence, falsification result, and rejected path to inform the next iteration. This ensures continuous learning within the bounded run.
• Parallel Sandboxes: Concurrent agent actions require isolated Git worktrees and a serialized queue manager to avoid race conditions.

Agent Packet Isolation

Security through structural isolation is a core tenant of modern intelligent orchestration. The Maker and the Verifier operate in completely different silos:

• The Maker Packet contains the user goal, current tasks, allowed paths, baseline anchors, and relevant context snippets to give it context.
• The Verifier Packet only contains the completion conditions, anchors, and execution limits. Access to Maker logic or narrative is strictly prohibited.
• The Verifier binds every PASS explicitly to a Git candidate tree. A Maker can claim a task is implemented, but a Requirement does not shift to VERIFIED until independent evidence proves it.

Source Knowledge Graph Governance

Markdown architecture documents are often just generated views; they are not graph authority. A true Source Knowledge Graph extracts only from verifier-approved Git trees, excluding workspace ignores, logs, and vendor paths dynamically.

• Provenance: No source fact can exist without exact provenance, validating its file hash, source span, and Git tree origin. Nodes (Project, Module, File, Symbol) and edges (IMPORTS, DEFINES, CHANGED_BY) make up this internal taxonomy.
• Immutable Releases: A promoted knowledge graph release is immutable. Runtime observations never overwrite static facts; they simply act as supplementary evidence.
• Incremental Invalidation: As the loop executes, the knowledge graph rebuilds intelligently using reverse dependency edges connected to changed file hashes, rather than brute-force parsing.

How It Prevents AI Degradation

Over time, long-lived autonomous agents risk degrading the repos they manage. Loop engineering directly subverts these failure modes:

Task Completion vs Project Completion

A goal is complete when its bounded conditions pass. The whole project is complete only when:

• Every MUST requirement is VERIFIED with immutable evidence.
• Project-wide acceptance checks pass on the final Git tree.
• No blocking issues remain.
• The final Source Knowledge Graph release matches the accepted project tree.

Observability: The Journal and the Echoes

Governance without observability is a rumor, so the loop writes everything down. Each run appends to a journal — goal registered, issue bound, checkpoint echoed, verification verdict, version promoted — and the checkpoints themselves are emitted by the scripts, never by the agent. That division is the audit story: the transcript is a tamper-resistant record because the agent is structurally incapable of narrating its own success. When something goes wrong, the journal reconstructs the run step-by-step: which issue was in scope, which paths were writable, what the verifier saw, and why the loop believed it was done.

The same stream powers the improvement loop. Recurring rejection reasons across runs surface the failure classes worth automating against; falsification logs accumulate into a map of strategies that do not work for this codebase; and time-to-verified per issue type becomes the honest velocity metric — measured not in tasks attempted but in goals that survived independent verification.

Loop Engineering transitions us from chat interfaces into a rigid, verifiable, objective-based development system. Welcome to the execution paradigm.