Supplementary Notes on "Mission Driver: A General Reference Implementation of Loop Engineering"

In my previous article "Mission Driver: A General Reference Implementation of Loop Engineering", I introduced the design principles and usage of Mission Driver. It is the core implementation of Attractor-Guided Engineering (AGE) at the control layer, responsible for 7×24 fully autonomous AI operation.

However, in practical application, I have found that many people habitually map it to concepts they are already familiar with—a more complex workflow orchestration system, an Agent orchestrator, or yet another Harness control mechanism. This understanding does not truly capture what makes Mission Driver distinctive: most common Loop Engineering implementations on the internet are essentially black-box models—the AI's internal state is invisible and uncontrollable to the user, and human intervention can only stop the loop and modify prompts. Mission Driver, by contrast, makes the core operational state explicit in roadmap and plan files (files are the AI's cognition), and human intervention is asynchronous—one can directly modify the roadmap or inject new plans, which the next loop iteration automatically picks up. The human-machine division of labor thus becomes more flexible: humans can review the roadmap, while the AI can autonomously introduce audit work items into the roadmap.

Another more fundamental difference is that most current AI engineering is oriented toward single tasks—including goal-driven approaches, which are all organized around individual tasks. The information container is the task itself; when the task completes and the session ends, the information becomes invalid. For long-term evolutionary operation, this is informationally insufficient. The directional guidance that AI needs for long-duration (weeks or even months) autonomous operation cannot come from external user input and user monitoring; it can only come from the project's own Owner Doc system. The AGE documentation system is not built for individual tasks but for the entire domain structure space: it defines what structure the system should maintain in the long term (desired attractors), which artifact holds authority over which questions (Precedence), what evidence proves what commitments (Proof), what key decisions have been made historically (trajectory memory), and whether information remains sufficient to support autonomous action (Freshness). These relationships remain valid across tasks and across sessions—any new development agent, relying only on the current repository, can recover the same set of facts, authorities, directions, and trajectories. This is precisely the informational foundation that enables Mission Driver to run fully autonomously for extended periods.

Without understanding these points, it is very difficult to get Mission Driver running fully autonomously, and equally difficult to use it to achieve results that surpass the built-in goal-driven mechanisms of coding CLI tools. This article is a conceptual clarification, explaining the conceptual system in which Mission Driver resides (Loop Engineering / Attractor-Guided Engineering), answering what problems it solves, and why it is designed this way.

"Files are the AI's cognition" does not mean that files equal the entirety of the AI's internal runtime state. Rather, it means:
Only those cognitions that have been externalized, can be recovered across sessions, and continue to constrain subsequent actions constitute the inheritable project cognition of a long-term autonomous system.
What Mission Driver maintains is not the continuous existence of a particular Agent instance, but the continuous recoverability of project cognition.

I. Positioning Within the Conceptual System: Loop Engineering vs. Attractor-Guided Engineering

1.1 Loop Engineering: The Industry's General Expression, But Without Answering "Why Convergence Is Possible"

Loop Engineering is the industry's general expression for the current stage of AI autonomous operation. Andrew Ng's three-layer Loop model (Agentic Coding at the minute level, Developer Feedback at the hour level, External Feedback at the day/week level) and Boris Cherny's "I no longer write prompts—I design systems that write prompts. I write Loops" together identify the loop as the core mechanism of autonomous operation.

This generalization is not wrong in itself. But it only describes "what execution form autonomous operation requires," without answering two deeper questions:

Why can a loop exist stably, to the point of tending toward convergence?
During the loop's continuous operation, how do humans and AI interact?

These two questions are exposed very directly in practical engineering. Many systems that claim to be loop-driven actually derive their direction, adjudication, and correction from humans outside the loop—users make decisions while watching the output, which is not fundamentally different from vibe coding. And when human intervention is needed, they often face a black box: they don't know what state the AI is currently in, or on what basis it made its current judgment. To adjust behavior, the only options are usually to stop the loop, modify the prompt, and start over.

These two gaps share a common root: the loop is merely an execution structure. Direction, state, trajectory—the things that allow a system to self-correct—fall outside the scope of the loop.

1.2 AGE: Answering "Why a Loop Can Exist Stably and Tend Toward Convergence"

AGE (Attractor-Guided Engineering) is the conceptual system established to answer the two gaps identified in the previous section. Its core consists of four concepts: state space (all possible structures that may appear during system evolution), attractors (the structures the system should stably tend toward in the long term), trajectory (how the system actually arrived at its current state), and control (the measurement and correction mechanisms that pull the trajectory back toward the vicinity of the attractor).

For a detailed introduction to AGE, see Attractor Before Harness: A Methodology for Large-Scale AI Development

In this conceptual system, "continuous operation" is no longer an end in itself, but a natural consequence of direction having been externalized. The reason a loop can exist stably and tend toward convergence is not because the loop is cleverly designed, but because mechanisms across three temporal dimensions are already in place:

• Before operation, the docs system has already been established—clearly distinguishing normative documents from time-sensitive documents, ensuring that the information sources the AI faces have clearly defined authority and update policies: normative documents (stable Owner Docs such as architecture/design) define "what the system should be in the long term"—desired attractors and authority attribution, undated, updated in place, with validity that does not decay over time; time-sensitive documents (plans/logs/audits/analysis and other process records) describe "what actually happened within a certain time window and what the current state is"—dated, trustworthy only within their validity window, and after expiry must be re-verified (freshness) before they can continue to support autonomous action; conflicts between the two categories, and among normative documents themselves, are adjudicated by the authority attribution defined by Precedence—resolved by the priority defined by Owner and scope, not by update time or convenience of access;
• During operation, the AI's internal state and cognition are made explicit—roadmap/plan/audits files are its cognition, and humans need not guess what the AI is thinking; human intervention has a standard protocol: directly modify the roadmap or add/remove plans, which the next loop iteration automatically picks up, without stopping the loop or modifying prompts; logs synchronously record the key decisions and verification results of each execution round, sedimenting into a traceable trajectory. Intervention is no longer a black box, and no longer requires interrupting operation.
• After operation, experience is distilled and fed back—the AI can mine lessons from logs/plans/audits: patterns of human correction are sedimented into skills, dimensions missed by audits are added to audit prompts, repeated failures are elevated to lessons (nop-app-erp demonstrates concrete practical cases); Mission Driver's postmortem review also writes reports into memory, which subsequent missions on the same modules automatically load. The loop thus becomes not merely repetitive execution but continuous learning.

Long-Term Continuity Comes from Cognitive Recovery, Not Session Continuation

The cognition of a single Session is not time-translation invariant. Temporary understanding formed at time t cannot be assumed to naturally exist in a new Session at time t+1.

Long-term autonomous operation must satisfy a stricter condition:

At any reasonable interruption point, starting a new execution agent, it must be able to recover the cognition needed to continue the same engineering trajectory based solely on the current project state.

This process can be expressed as:

$$
C_t\rightarrow Action_t \rightarrow Validate_t \rightarrow R_{t+1} \rightarrow Recover \rightarrow C_{t+1}
$$

Where:

• $C_t$ is the temporary cognition recovered by the current Session;
• $R_{t+1}$ is the project cognition structure after validation and write-back;
• $C_{t+1}$ is not a direct copy of $C_t$, but the action cognition re-formed by a new Session based on $R_{t+1}$.

Therefore, AGE does not require preserving the complete reasoning process of every Session, nor does it require replaying all history. It requires that the current repository preserve a cognitive structure sufficient for subsequent actions.

1.3 Mission Driver: A General Implementation of Loop Engineering, Defining State and Evolution Within the AGE Conceptual System

Mission Driver implements the core proposition of Loop Engineering: instead of writing prompts, write a loop that continuously generates prompts. It can be viewed as a general implementation of Loop Engineering—at its foundation is a general-purpose Flow DSL execution engine, where each loop iteration reconstructs the prompt for the next AI step, with placeholders ({{planGuide}}, {{roadmapPath}}, {{plansDir}}, {{testCmd}}) injected with actual values from a configuration variable table. Swapping a flow file adapts it to different scenarios; humans no longer hand-write prompts one by one, but instead design, configure, and monitor the loop itself.

In terms of the conceptual system, Mission Driver is a fully automated operation mechanism within the AGE framework. The division of labor between the two is clear: the loop's execution structure is provided by Loop Engineering, while state management and evolution rules are defined by AGE. Mission Driver operates on top of the attractor definitions carried by the docs system (desired attractors are externalized and carried by the docs system; Mission Driver depends on rather than defines direction), and drives Plans through the complete lifecycle from review, execution, verification, to audit. It is not a Harness in the ordinary sense, but a continuous orchestrator that executes according to the roadmap under attractor guidance. This is also what distinguishes it from other engines that "only implement the loop structure." From the perspective of operational form, Mission Driver orchestrates work items and plans—DRAFT_PLANS projects work items from the roadmap into plans, EXEC_PLANS drives plans through the complete closed loop of execution, checking, and auditing; and this closed loop is precisely what carries the Harness function (measurement and correction) in AGE.

The boundaries between Mission Driver, Harness, and AGE are:

• Harness (Agent = Model + Harness). In the understanding of Harness Engineering, the harness is everything outside the model—guidance files (instructions such as AGENTS.md), context engineering (task-relevant information supply), sensors (automated checks such as lint/typecheck/security scanning), guardrails (boundary rules such as file naming conventions, "no bypassing the ORM to write SQL directly"), verification gates (test and build gates), monitoring (human review), and feedback loops (engineering corrections so that the same error becomes structurally impossible to repeat). In AGE, the Plan Loop, tests, Closure Gates, independent audits, DEEP_AUDIT, and trajectory correction play the role of the Harness—they measure the actual trajectory, judge deviations, and pull deviations back. The Harness solves "whether the current trajectory has deviated and how to correct it," but the Harness itself does not define "where it should return to."
• AGE defines the attractor and gives the Harness its long-term evolutionary direction and convergence criteria—the convergence mechanisms (Closure Gates, independent audits, DEEP_AUDIT, trajectory correction) are structurally the Harness. AGE's increment lies not in the mechanisms themselves, but in two layers of information that the Harness itself does not carry: the first is the directional basis—the desired attractor defines "where it should return to." It is not a single rule, but a region of permitted structures jointly delimited by a small number of high-value structural constraints (such as nop-app-erp's "one <domain>/model/*.orm.xml per domain is the single source of truth for the persistence model," "module dependencies form a unidirectional DAG, cross-domain references go through R/S/P contracts," "docStatus × approveStatus × posted three-axis orthogonal state separation," and other constraints that jointly delimit the region). "Attractor Before Harness" means that only after it exists can one decide what the Harness measures, what it rejects, and where it pulls deviations back to; the second is the definition of convergence—convergence is not static compliance, but a dynamical property: under sustained perturbations (requirement changes, AI-generated expansion, refactoring, external feedback), the system's long-term trajectory repeatedly returns to the vicinity of the attractor-defined structural region ("the key is not staying at X forever, but being able to return to the vicinity of X after deviation"); the basis for judgment is not a single cross-sectional compliance check—passing one check only shows that the current cross-section has not exposed problems. Only when deviations are identified, recorded as unclosed obligations, and subsequent work continuously pushes toward regression can the system be said to possess convergence.

In operation, this definition manifests as four observable mechanism designs:

1. State Explicitation: roadmap/plan/audits and other files make explicit the AI's internal operational state and cognition—humans need not guess what the AI is thinking; the files are its cognition. This is precisely the answer to "black-box intervention."
2. Intervention Without Stopping the Loop: human intervention can directly modify or add plans and modify the roadmap without stopping the loop—REVIEW_PLANS automatically picks up any Plan with Status=draft, and DRAFT_PLANS reads the latest roadmap. This is precisely the answer to "must stop the loop to change the prompt."
3. Sufficient Statistics of Trajectory: through logs, core trajectory information can be recorded without relying on git history—all key decisions can be quickly archived through a small number of records similar to "sufficient statistics," and a new agent need not archaeologically excavate historical commits to recover key evolutionary cognition.
4. Audit Feedback: audit history can be reverse-mined into various skills to improve subsequent work—the findings of each round of deep audit are sedimented into experience that subsequent loops can load.

AGE's complete mechanism chain can be compressed as:

Desired attractors define long-term structure
Trajectory records actual evolution
Plans close local trajectories
Harness provides measurement and correction
Mission Driver automatically orchestrates Plans
The repository carries cross-session facts and memory

nop-app-erp is a clear example of this mechanism in operation: 22 days (06-22 → 07-13), 187 Plans (counted from 07-01) all passed dual audits, and human intervention decayed from early high-frequency platform mechanism corrections (7 entries on 06-22 alone) to zero after 07-14. This is a typical knowledge transfer process: user interventions fall into three categories—Category A (explicitly pointing out Nop platform mechanisms, concentrated in the early period 06-22 ~ 06-26), Category B (pointing out engineering principle directions, such as the DDD principles of the posting engine and meta-rules of architecture documents, concentrated in the middle period 06-29 ~ 07-01), Category C (only requiring the AI to self-check and compare, without hinting at answers, predominant after 07-04); the frequency decline of Category A and the rise of AI autonomy cross at 06-29 ~ 07-01, after which AI autonomy becomes the primary working mode. The transferred knowledge was sedimented into 19 reusable skills, docs-for-ai supplements, and lessons, constituting the knowledge base for self-sustaining operation—as the project retrospective states: "The user was not writing code, but transferring platform knowledge. Once knowledge transfer was complete, intervention frequency automatically dropped to zero." Intervention reaching zero is not because the AI learned to write code, but because the attractor had already been defined.

Treating Mission Driver as an ordinary Agent orchestrator loses its directional basis within AGE. But it also does not itself possess directional definition authority—it is merely the execution mechanism at the control layer, and must work in coordination with the external docs system.

II. What Problems Does It Solve

2.1 Two Structural Dilemmas of Vibe Coding

The problems Mission Driver aims to solve begin with the dilemmas of Vibe Coding. The current mainstream AI-assisted development pattern—human prompts, AI responds, human corrects, AI responds again—is essentially an infinite loop with no exit condition. This pattern has two problems (details in Part I of "Mission Driver: A General Reference Implementation of Loop Engineering").

The first is quality loss of control. AI execution is essentially a probabilistic sampling process. Without external control structures intervening, the AI easily goes astray: halfway through a change it wanders off to modify other code, forgets to run tests after finishing, gets stuck in dead loops after failures, or loses state after process crashes and has to start over. Even more dangerous is self-declared completion—skipping actual implementation and directly claiming the work is done.

The second is capacity limitation. When a human is in the loop, every step depends on human triggering and judgment, and the ultimate bottleneck remains human working hours and energy. But when AI can run 7×24, working hours are no longer the constraint—weaker models may be slow, but they are cheap enough to run overnight. The cost structure shifts from "output per human-hour" to "intelligence output per dollar." To truly unleash this potential, humans must exit the loop, becoming on-demand intervention control factors rather than executors participating in every step.

2.2 From Human In The Loop to Human On The Loop

Mission Driver's goal is not to "replace humans," but to "allow humans to intervene at any time, without needing to intervene at every step." It makes human intervention optional rather than mandatory.

In Vibe Coding, every step in the loop depends on human triggering. The Plan Loop itself can form a minimal autonomous closed loop for a Plan from drafting, review, execution, to closure; but in the form with only the Plan Loop, the orchestration problem of "what to do next" (ordering, state advancement, gap discovery, deep audit triggering) still depends on humans. Mission Driver's design places the orchestration layer above the Plan Loop: the Plan Loop solves "how to reliably close one change," while the Mission Driver Loop solves "which change to close next"—in Mission Driver, humans can choose to participate, but the system can also proceed from the first item of the roadmap to the last without human intervention.

This optional participation directly responds to the two gaps identified in 1.1: intervention does not face a black box (the AI's current operational state, cognition, and judgment basis are all made explicit in roadmap/plan/audits files), and intervention does not require stopping the loop (directly modify files, and the next loop iteration automatically picks them up)—rather than "can't see the state, can only stop the loop and modify the prompt."

The mechanism of this optional participation is asynchronous: the plans/ directory is a shared queue on the filesystem. A human can draft a Plan and place it in the queue at any time, or modify a Plan's status (e.g., change one mistakenly marked as active back to draft), or adjust roadmap priorities—the next loop iteration's REVIEW_PLANS will automatically pick it up and review it, without distinguishing whether the Plan was machine-drafted or hand-created by a human. Humans and Mission Driver work on different time scales (a human might process things once a day, while Mission Driver automatically completes a full loop every 4-12 hours), exchanging state through the filesystem rather than real-time communication.

This means it needs to automatically solve four sub-problems of the orchestration problem:

• Ordering: the execution order of a large number of changes. This is not a statically pre-computable schedule—each completed change may reveal new dependencies, requiring subsequent order adjustments. Ordering needs a dynamically queryable roadmap structure, not a one-time Gantt chart.
• State: what stage each Plan is currently in—draft, active, in execution, completed? State needs to be persisted in the Plan file itself, so that anyone reading the repository (or the next loop iteration) can independently judge.
• Advancement: who selects the next work item? Who drafts a new Plan and marks it as active? This action needs to be automatically executable, but the acceptance of the execution result requires independent review—advancement and audit cannot be the same subject.
• Audit: when roadmap work items are exhausted (DRAFT_PLANS returns nothing), who triggers deep review? Deep audit only intervenes when the main execution loop has no new work, avoiding competition with ongoing changes.

In the mode with only a Plan Loop and no orchestration layer, these four problems are all answered by humans. Mission Driver's design goal is to transfer them from human brains to the machine—but it does not replace the Plan Loop: it drives and orchestrates the Plan Loop, keeping each minimal autonomous closed loop running continuously and orderly (see 3.4 for the nesting relationship).

Regarding the roadmap on which "ordering" depends, its nature needs clarification: the roadmap is only work planning, not an execution plan, nor a design contract—the granularity of a work item equals "the reasonable delivery scope of one execution plan," and the information a specific work item depends on (project initiation materials, design contracts, scope adjudication) is defined separately in the docs system, not stuffed into the roadmap body. The roadmap evolves dynamically during operation: state is written back from the plan lifecycle, review gate correction items are written back, and it is jointly maintained by humans and AI; moreover, work items do not need to be fully determined before operation—for example, research work items can be arranged first, and subsequent work items formulated based on the research report. It should be noted that the degree of evolution permitted varies by task type and is constrained by the respective roadmap guide: in general, the guide explicitly requires the AI not to skip order or add work items, to ensure execution stability; for exploratory tasks, the guide may allow the AI to dynamically supplement subsequent work items based on intermediate outputs (such as research reports).

2.3 Differences from Ordinary Workflow Engines

A common misconception is that Mission Driver is merely an automated Agent orchestrator. Both are indeed state machine engines—steps, transitions, state advancement, formally isomorphic. But the essential difference lies in the nature of the execution units and the operational content: ordinary workflow engines execute deterministic pre-defined steps, while Mission Driver orchestrates probabilistic AI steps and dynamically generated planning.

Ordinary workflow engines and Mission Driver have three fundamental architectural differences:

Dimension	Ordinary Workflow Engine	Mission Driver
Operational content	Pre-determined tasks fixed at design time; the process definition is the task, with no complex planning layer	Roadmap dynamically plans work items; plans define closure contracts for individual changes, both generated at runtime
State location	Inside the engine (runtime/engine database), requiring engine queries	In repository files (plan status and checkboxes), recoverable by reading the repository; recovery logic is also AI intelligent judgment execution
Operational form	One run consumes one determined instance and ends	Oriented toward 7×24 continuous operation, interruptible at any time, restarts resume by disk scan rather than replay

The most fundamental of the three differences is the nature of the execution unit. Ordinary workflow engines orchestrate deterministic steps: each step is pre-written code or a command, with determined input, determined execution, and determined success or failure; failure is an anomaly requiring interruption or human intervention.

Mission Driver's Flow DSL has five step types: tool (shell commands) and script (JS functions) are deterministic; group (sub-steps with round-based looping) and subflow (recursive sub-processes) are structural orchestration; while agent (spawning an opencode subprocess) is inherently non-deterministic—the same prompt in different sessions may take different paths and produce different results. Precisely because probabilistic steps exist, the engine's design goal shifts from "deterministic execution" to "ensuring convergence under probabilistic execution." This convergence relies on three layers of fault tolerance:

• Each invocation is a micro-loop: within an agent step, failure to extract the marker (the <AI_STEP_RESULT> tag in AI output, on which the engine relies to drive state transitions) does not immediately result in failure—the parsing sub-agent (runParseAgent) infers missing tags and normalizes near-synonyms through markerAliases; if still unmatched, it spawns a correction subprocess to output legal values (up to 2 attempts); if the process is killed, it goes through onError retry (default 3 times); transient provider errors (429/rate limiting) go through a separate exponential backoff retry budget.
• Loop nested within loop: the main loop (five-step closed loop) is on the outside, with embedded groups (such as CLOSURE_VERIFY's script-check → AI-audit → re-check, up to 3 rounds) and subflows (EXEC_PLANS' plan-execution, DEEP_AUDIT's deep-audit-loop); subflows recursively create new FlowEngine instances within the same process, each holding independent flowVars / visitCounts / retryCounts—structurally closer to a recursive call stack than an assembly line.
• Fault tolerance is structural: each step has independent maxRetries / onError / onMaxRetries; globally there is ping-pong detection, maxCycleVisits, maxTotalSteps to prevent infinite loops; subflow boundaries are fault-tolerance boundaries—one plan's failure does not propagate to sibling plans.

Comparing the two: ordinary workflow engines treat failure as an anomaly (interruption or human intervention), while Mission Driver treats failure as expected input (retry, degradation, isolation are default paths); the former pursues deterministic execution, while the latter pursues maintaining convergence amid uncertainty.

Therefore, the precise positioning of Mission Driver is:

It is an engine that, under attractor guidance, continuously orchestrates the lifecycle of work items and plans according to the roadmap. The review, execution, verification, and audit closed loop that plans carry is precisely what performs the Harness function, enabling these control processes to run long-term without synchronous human participation.

Finally, the position of direction also differs: an ordinary workflow engine's direction is in the process definition itself (the process is the task); Mission Driver's general-purpose Flow DSL is merely an execution skeleton, with direction externalized in the docs system (desired attractors), and the roadmap being a task-ified projection of the attractor rather than the direction itself. It does not define on its own: what the project should become, which Owner Doc has authority to modify the structural baseline, which Proof Relation is correct, or whether a particular deviation should be fixed in the implementation or by correcting the Attractor. If these relationships have not been externalized, Mission Driver can only continuously produce file changes without guaranteeing that these changes belong to the same acceptable trajectory (full discussion in 4.1).

2.4 Comparison with Similar Industry Implementations (LoopX): Consensus and Differences

LoopX, https://github.com/huangruiteng/loopx is a local control plane for long-duration AI agents, with the slogan "Keep the loop moving. Keep the judgment human." It does not replace the agent runtime, but rather wraps external runtimes such as Codex / Claude Code / Cursor with an agent-agnostic bypass control layer, using a persistent state kernel to carry lifetime goals, gates, todos, evidence, quota, and handoff—so that goals, judgments, evidence, and costs do not drift across multiple rounds and multiple agents. It explicitly declares that it is not an autonomous production controller, and that dangerous permissions and ultimate ownership always belong to humans.

It is likewise a concrete implementation of Loop Engineering, and like Mission Driver, it attempts to solve the problem of "making long-duration AI operation governable." The two are highly consistent at the engineering level of Loop Engineering, with differences concentrated in the theoretical layer, automation boundary, and architectural orientation.

Engineering-level consensus (judgments shared by LoopX and Mission Driver):

Consensus	LoopX's expression	Mission Driver's expression
Chat memory is not the fact source for long-term tasks	"Chat memory and a timer are not enough to govern that"	Logs record core trajectory without relying on git history; "files are its cognition"
Human On The Loop: human intervention changes from "mandatory" to "optional"	"Human-in-the-loop should not be equivalent to asking the user to confirm every few minutes"	Humans can choose to participate, but the system can also proceed from the first item of the roadmap to the last without human intervention
Bounded rounds + validated write-back before counting as complete	"Validate and write durable state before spending"; opposes writing "bypass has progress" as "gate resolved"	Closure Gates reject "all checkboxes ticked" false completion; DEEP_AUDIT can overturn completed conclusions
Longer operation does not equal a better product	"A long loop without better state management only creates greater drift"	"A Loop with fixed goals, fixed feedback, and inability to rewrite its own structure is merely a servomechanism"
Evidence must be compact, checkable, recoverable, and handoff-able	compact artifact, run index, handoff, enabling "the next round's agent to recover context"	Plan closure contracts define "where to start, what changes are permitted, where to close, and what evidence suffices to prove closure"

Differences concentrate in three points:

1. Theoretical layer: AGE's attractor system is a unique theoretical increment. LoopX positions itself as a control plane rather than a direction source: quota should-run is a compute guard rather than a strategy selector—goals, boundaries, and acceptance criteria are provided by users in the goal text, and the control layer only ensures these goals do not drift across rounds, agents, and runtimes. LoopX acknowledges that the gap in direction baselines is real, but chooses to supplement it with a minimal contract (such as binding authority material revision to admission/checkpoint), maintaining provider-neutrality (repository owner docs are just one provider). The conceptual system in which Mission Driver resides goes one step further: desired attractors define long-term structure, Trajectory records actual evolution, Harness provides measurement and correction, and the directional premise is externalized as repository structure (structural invariants in Owner Docs, etc.). In Andrew Ng's three-layer Loop model, External Feedback corresponds to the Mission Loop layer (day/week-level signal response), and LoopX's quota/gate mechanisms are also signal response layers—neither has an explicit desired attractor definition externalized as repository structure, nor convergence mechanisms.

2. Different designs of automation boundaries. LoopX architecturally makes human judgment a first-class citizen—human judgment (reward, gate, quota, attention cost) is preserved at every link of the operational layer; "Quota protects not just compute, but also human attention." At the same time, LoopX explicitly opposes committing complete reasoning, prompts, and raw trajectories by default—citing concerns about privacy leakage, repository bloat, and dual state authority; Todo/claim/gate/receipt remain kernel-owned. Mission Driver, by contrast, confines human governance to the direction layer (desired attractors, Owner Docs), and pursues unattended operation at the execution and orchestration layers: 7×24 operation, automatic completion of a full loop every 4-12 hours, human intervention decaying from early high frequency to zero in later stages, and all state (plan/log/audit/skill) fully file-ized in the repository. But the two are not in substantive conflict: LoopX's "judgment throughout the operational layer" corresponds to the boundary of "not defining direction" in Mission Driver's conceptual system (Chapter IV), while "automatic execution and orchestration" corresponds to the first two layers that can be automated (Chapter V)—the difference lies in where human judgment is preserved in the operational chain.

3. Different architectural orientations. LoopX is an agent-agnostic bypass control layer: wrapping external runtimes with three adaptation depths—in_loop / wrapper / passive_posthoc—using an append-only event ledger as truth (with current state as merely a projection), and introducing quota allocation and peer claim/lease multi-agent collaboration; the direction baseline remains provider-neutral (repository docs, private wiki, local owner docs all acceptable), and state remains kernel-owned. Mission Driver is a self-contained Flow DSL engine + orchestrator: the filesystem is the single truth layer, zero IPC, breakpoint recovery via disk scan, sub-agents isolated through Fresh Sessions, but without event ledgers or peer/lease concepts. The two solve different subsets of the same class of problems—LoopX emphasizes resource governance across multiple runtimes and multiple agents, while Mission Driver emphasizes reliable advancement and directional consistency of the closed loop within a single project.

Summary: The two are highly consistent at the engineering layer of Loop Engineering (state persistence, bounded rounds, evidence recoverability); the difference is that AGE externalizes direction as repository structure and defines convergence mechanisms, while Mission Driver pursues unattended autonomous operation through a fully file-ized roadmap approach.

III. Why This Design: Internal Design Philosophy

If one only looks at the execution form, Mission Driver's five steps are indistinguishable from any task orchestrator. Its design value lies in each layer of mechanism corresponding to a problem that must be solved. The following unfolds in the order of "from local to global."

3.1 Plan Is a Closure Contract, and Also a Manager of Intermediate State Legitimacy

Problem solved: Vibe Coding has no exit condition.

The core of the Plan Loop is the Plan. A Plan is not a task list—it is the basic unit of AI autonomous execution, a closure contract. It contains three core elements and one auxiliary item:

• Current Baseline: read from the repository, not from memory. This is the Plan's starting anchor, allowing reviewers to independently judge whether the change volume promised by the Plan matches the current repository state.
• Goal Set (Goals + Non-Goals): clearly defines what to do, and more importantly, what not to do. Non-Goals prevent Scope Creep during execution, and also prevent reviewers from evaluating the delivery against standards the Plan did not commit to.
• Exit Criteria + Closure Gates: observable completion conditions, each followed by a small checkbox waiting to be ticked. Not vague descriptions like "feature done" that cannot be adjudicated.
• Auxiliary item: Draft Review Record: the process record of independent review iterations, making the Plan's evolution traceable.

In cross-session scenarios, the Plan simultaneously manages the legitimacy of intermediate states:

When a migration is halfway through, the repository may simultaneously contain old interfaces, new interfaces, compatibility layers, temporary tests, partially migrated modules, and transitional documentation. The original executor knows these are intermediate states, but the next Session can only read the current repository. Without an explicit Plan, the next agent would very likely interpret these temporary structures as formal architecture—and thus, intermediate states could gradually acquire long-term legitimacy through subsequent expansion without any adjudication.

The Closure Plan exists precisely to prevent this silent elevation. What it answers is not "what things need to be done," but:

Where does this segment of local trajectory begin, what changes are permitted, where must it close, and what evidence suffices to prove closure.

Ordinary task lists focus on "what was done"; the Plan focuses on "which realities in the current repository are still merely transitional states, not yet qualified to become long-term baselines." Therefore, the Plan's core is not managing workload, but managing the adjudication of intermediate state legitimacy.

3.2 Separation of Generation and Verification: Rebuilding Epistemic Independence, Not Repeated Checking

Problem solved: Evidence generated in the same context will gradually bias toward a certain probability distribution. (When the context contains enough erroneous information, it may even induce the AI to mistakenly believe you want it to generate erroneous samples.)

AI can generate code, tests, documentation, Plan updates, completion statements, and self-review conclusions all within the same context. If the initial understanding deviates, these outputs can be mutually consistent yet collectively point in the wrong direction—they won't contradict each other, but they may collectively deviate from real requirements or long-term structure.

Therefore, the significance of Fresh Session and independent Audit is not "looking again," but severing the verifier's direct inheritance of the generator's completion narrative. The verifier must re-read the live repository, current Owner Docs, Plan obligations, Proof Evidence, and unclosed conflicts, beginning judgment from external evidence.

But an independent session is not the final truth. A Fresh Session is still not an absolutely objective third party—the same model, same materials, and similar Prompts can still produce correlated errors. Reliability must also come from an evidence hierarchy of executable checks, property tests, E2E, real runtime evidence, different models or different tools, domain experts, and user feedback.

Here we must also point out a more insidious trap: passing tests does not mean semantic commitments have been proven. Tests only constitute Proof when they maintain a valid relationship with a certain commitment. Suppose the system's real commitment is "Spreadsheet correctly presents currently visible rows at any data scale," and the old implementation mounted all rows at once, so the test was written as "assert 30 row headers exist simultaneously." When the implementation is changed to virtualization, this test may remain stable and clear, yet no longer prove the original behavior—it begins protecting old implementation details. This is Proof Drift:

The test still exists
The test may still pass
But the proof relationship between the test and the original semantic commitment has been severed

What AGE must maintain is not simply "code ↔ tests," but "semantic commitments → observable consequences → proof evidence."

3.3 Engineering Implementation: File-ization, Breakpoint Recovery, and Subflow Isolation

Section 2.3 already summarized the structural features of file-ized state and loop nesting. Here we supplement three engineering details not expanded in 2.3.

Injection mechanism—cross-project reuse. Prompt templates contain placeholders such as {{planGuide}}, {{roadmapPath}}, {{plansDir}}, {{testCmd}}, and the engine injects actual values from the mission configuration variable table. Switching projects only requires modifying the JSON configuration, not modifying prompt logic—the two concerns of "project structure" and "prompt structure" are separated.

Breakpoint recovery—disk scan, not replay. After a process crash and restart, the engine does not replay historical steps, but scans the status lines and checkbox marks of Plans on disk, jumping directly to the breakpoint to continue. This is also the reason parameters are not passed between main flow steps: each step relies only on plan files to transmit information; CHECK does not know how many Plans REVIEW_PLANS discovered, and each step reads input from disk and writes output back.

Zero IPC—observability. No inter-process communication, message queues, or databases. To determine "what state the system is currently in," one simply reads files—execution and audit share the same truth layer.

Specific manifestations of subflow isolation. Suppose there are 3 active plans, and plan-002 fails after 3 execution retries—the execution agent discovers that a certain premise does not hold, moves the blocking item to Deferred But Adjudicated, records the trigger conditions, and continues completing the remaining Phases. Plan-002's blockage does not propagate at all to plan-001 and plan-003. Retries typically reuse the same session to preserve execution context, which is a different scenario from 3.2's "auditors must open a new session and read the repository from scratch."

3.4 Loop as Intelligence: Multi-Timescale, Structural Memory, and Recursive Closed Loops

"Loop as intelligence" does not mean that mechanical repetition produces intelligence—a single Loop with fixed goals, fixed feedback, and fixed control rules is merely a servomechanism.

The essence of intelligence is a system's ability to operate multi-timescale perception-prediction-action closed loops around some organizational identity in an uncertain environment, sedimenting feedback into structural memory, and recursively revising its own model, control methods, and structural boundaries.

In AGE, this manifests as closed loops layered at different timescales:

• Execution-level Loop (seconds to minutes): catching errors, diagnosing, repairing, and retrying;
• Plan Loop (hours to days): judging whether a change can be effectively closed through review, execution, Proof, and Closure Audit;
• Mission Loop (days to weeks): orchestrating multiple Plans, identifying cross-module gaps and accumulated deviations;
• Attractor Evolution Loop (longer cycles): judging based on long-term trajectory whether to correct the implementation, the Harness, or the Attractor itself.

Multi-timescale solves the contradiction between stability and adaptation. With only fast Loops, the system treats all problems as local anomalies, endlessly piling up patches; with only slow Loops, the system cannot absorb perturbations in time. Faster closed loops handle current deviations, while slower closed loops judge what these deviations mean when accumulated over the long term.

The same signal may have different meanings at different levels:

Test failure
→ may be an implementation error
→ may be a Plan premise error
→ may be the Harness measuring the wrong object
→ or may indicate the Attractor itself needs correction

The key to transforming a Loop from "repetition" to "learning" is structural memory. A closed loop cannot merely leave behind success or failure; it must write understanding back into the current repository, changing the goals, constraints, and available paths of subsequent closed loops:

Discover deviation
→ fix current implementation
→ write general understanding into Logs, Bugs, Audits, Skills, or Owner Docs
→ update tests, Plan Guides, or audit rules
→ subsequent Loops operate under new structural conditions

Owner Docs, Logs, Plans, Bugs, Audits, and Analysis are not auxiliary documentation, but structural memory transmitting cognitive results across different timescales. If experience remains only in one conversation, the system has merely completed a reaction; when experience enters the repository and changes subsequent control conditions, the system has learned.

A Loop only guarantees that the system tends toward a steady state under given feedback; it does not guarantee that the feedback and goals are correct. Therefore, an intelligent system also needs: multiple relatively independent evaluation signals for cross-validation; Fresh Sessions and independent audits to reduce same-source bias; Meta-Loops to check whether tests, Plans, Harness, and Owner Docs have drifted; and interruptible mechanisms allowing slower Loops to pause, overturn, or redefine the goals of faster Loops.

The Attractor is also not outside the Loop. It forms a recursive relationship with the closed-loop layering: Attractor constrains faster Loops → Loops produce actual trajectories → trajectories sediment into structural memory → slower Loops read long-term accumulation → when necessary, correct the Harness or Attractor → new structural conditions enter the next round of execution.

From the AGE perspective, intelligence is not a single-layer Loop under a fixed goal, but a recursive closed-loop layering guided by Attractors, operating across multiple timescales, capable of self-correction and accumulating structural memory. A Loop with fixed goals, fixed feedback, and inability to rewrite its own structure is merely a servomechanism; when closed loops at different levels can cross-validate feedback and write experience back into models, control rules, and structural boundaries, the system moves from repetitive execution toward learning, adaptation, and evolution.

IV. Its Boundaries: What Mission Driver Cannot Do

4.1 It Does Not Define Direction

Whether each step of the main flow is meaningful depends on what direction they are reading:

• On what basis does REVIEW judge whether a Plan is reasonable?
• On what basis does EXEC choose implementation structures?
• On what basis does CLOSURE_AUDIT (the closing audit in the EXEC_PLANS subflow) judge completion?
• On what basis does DEEP_AUDIT identify systematic deviations?
• On what basis does DRAFT project the Roadmap into the next round of work?

If the answer is merely "based on current code and existing tests," then Mission Driver may only be efficiently replicating the current baseline. If the current baseline itself has already deviated, it will more quickly solidify errors.

Mission Driver can guarantee that the Loop keeps advancing, but cannot alone guarantee that the trajectory direction is correct.

4.2 Writing Owner Docs Does Not Equal Possessing Attractors: Desired Attractors vs. Actual Attractors

"Where the system should converge" and "where the system actually converges" are in fact different questions.

Desired attractors answer: "What structural vicinity should the system repeatedly maintain or return to during continuous evolution?" They are defined by a small number of high-value structural relationships (a certain model is the single source of truth for domain facts, Template and Instance are separated, Data and Capability are orthogonal, modules obey clear dependency directions, core primitives form a closed set...). Desired attractors are usually carried by Owner Docs, but Owner Docs are not the attractors themselves—documents merely turn these structural relationships into an engineering representation that is versionable, routable, auditable, and modifiable.

Actual attractors answer a different question: "Under the combined action of the current code baseline, development habits, tests, CI, Plans, Reviews, Agent behaviors, and organizational incentives, what structure will the project actually repeatedly return to?" The actual attractor is not the current code—the current code is merely one state in the state space; the actual attractor is an evolutionary tendency that can only be identified through long-term trajectories.

For example, Owner Docs may stipulate that "the domain model must have a single source of truth." But if copying models across modules is most convenient, tests only verify intra-module self-consistency, Reviews do not check cross-module semantic duplication, plans close by local functionality, and the costs of duplication are deferred to the future—then the project's actual attractor structure may be "each module maintains its own local model."

Therefore, AGE's goal is to gradually align the two: define desired attractors → externalize them as repository semantic structures → design the Harness based on them → the Harness changes actual evolution rules → observe long-term trajectories → judge whether actual attractors approach desired attractors → correct the implementation, the Harness, or the desired attractors.

Current state complying with Owner Docs is insufficient to prove that actual attractors have aligned. Passing one check only shows that the current cross-section has not exposed problems; only when, after sustained perturbations, deviations, and corrections, the system can still repeatedly recover key structures can one say that the desired attractor is becoming an effective engineering attractor.

4.3 It Is Not a Neutral Executor

Mission Driver does not define desired attractors, but it significantly affects actual attractors. The reason is that it determines which behaviors will be repeatedly executed: which types of Plans get prioritized, what evidence suffices to close tasks, when deep audits are triggered, which types of problems get sent back to the execution queue, and which failures trigger escalation rather than automatic patching.

If Mission Driver only rewards "tests pass + checkboxes complete + current task closed," it may pull the project toward the actual attractor of "local completion maximization." If it continuously reads Owner Docs, Proof Relations, Closure Gates, Freshness, Independent Audit, and unclosed trajectory obligations, then it may help actual attractors gradually approach desired attractors. In nop-app-erp, independent audits repeatedly overturned false completion claims (e.g., the second-round audit FAIL in the EXEC_PLANS subflow on 07-20—the executor claimed to have remediated a "modified generated files" violation, but an empty git diff proved no modification had occurred)—it was precisely this bias source of independent audit that pulled local completion maximization back toward convergence on real structure, preventing the actual attractor from drifting toward "number of tasks completed."

This also means Mission Driver itself must accept Meta-Audit:

• Does it have a long-term preference for tasks that are easy to close?
• Does it ignore structural problems that are difficult to prove automatically?
• Does it mistake current tests for final standards?
• Does it continuously replicate the current baseline?
• Can it identify Harness Drift?
• Does it reduce autonomy when information is stale?

4.4 It Is a Stress Test for AGE's Completeness

Although Mission Driver is not the theoretical starting point of AGE, it can rapidly expose whether AGE has truly been implemented.

In human collaboration, many gaps can be covered by human ad-hoc interpretation: when documents conflict, humans know whom to listen to; when a Plan is incomplete, humans supplement it verbally; when tests are outdated, humans know to temporarily ignore them; when intermediate states are unrecorded, humans remember to clean up later; when Owners are unclear, architects can adjudicate on the spot.

After Mission Driver runs continuously, these implicit patches disappear, and the system exposes: incomplete routing, unclear Owners, Precedence unable to adjudicate, Plans inconsistent with live repo baselines, Closure being merely checkboxes, Proof disconnected from semantic commitments, historical materials mistaken for current norms, temporary structures without exit obligations, and insufficient Freshness yet autonomous expansion still permitted. nop-app-erp's competitive leverage audit on 07-12 is a relevant example (the audit was triggered by a human rather than automatically initiated by Mission Driver, but the gap it revealed is the same): a sub-agent verified 8 claimed competitive advantages and found 2 exaggerated and 2 missing—from the perspective of the Plan Loop and Mission Driver, every corresponding Plan had passed review, and the control layer had not failed; what failed was the direction definition layer with insufficient externalization. It shows that such gaps can only be exposed and intercepted through the continuous externalization of the direction definition layer, regardless of whether the trigger is human or machine.

Therefore, Mission Driver is not merely about improving efficiency. It is also testing:

Whether the project has externalized enough direction, authority, proof, and trajectory memory that it no longer depends on some synchronously present human to interpret.

If the answer is negative, the more automatic Mission Driver is, the faster the drift may be.

V. How to Understand "Fully Automated AI Development"

"Fully automated" has at least three different levels.

1. Execution automation: given a clear Plan, AI can autonomously modify code, write tests, run verification, fix failures, and submit audit evidence.
2. Orchestration automation: given a Roadmap and Attractor, Mission Driver can autonomously draft Plans, review, queue execution, close tasks, discover gaps, initiate deep audits, and generate remediation work.
3. Directional autonomy: the system can autonomously clarify ambiguous goals, propose new structural languages, compare competing Attractors, handle organizational interest conflicts, and decide product strategy.

The first two layers can already achieve a high degree of automation; the third layer still requires explicit human governance. The "fully automated" in the nop-app-erp case should more precisely be understood as: once direction and key structures are clarified, the execution and orchestration layers enter high-autonomy operation, and humans transition from synchronous execution nodes to asynchronous direction and anomaly governors.

VI. Summary

Traditional software engineering is essentially human-centered engineering. The role played by humans is like an omniscient and omnipotent god who can descend at any time, interrupt at any time, and inject the "correct answer" at any time. The system itself has no direction, no self-discipline, no memory. The reason a project does not go off track is not because the system has intrinsic order, but because humans are always present, continuously adjudicating, correcting, and supplementing. Every deviation is pulled back on track by divine oracle descending from the god.

But 7×24 autonomous AI operation means the god must exit. Humans cannot stand forever beside the system as that invisible architect. The system must therefore wean itself off dependence on oracles, possess its own intrinsic operational laws, and become a physical system actually operating in the physical world: a dynamical system evolving in state space, constrained by its own laws, observable and controllable. Its stability, convergence, and disturbance resistance become real dynamical system evolution problems, no longer dependent on the god's on-the-spot judgment.

In this transformation, knowledge externalization is not a question of "whether it can be done," but a necessary premise. Because large AI models are stateless, autonomous operation across sessions, processes, and sub-agents must rely on externally persisted state and rules. Direction, authority, proof, trajectory, freshness—if these key pieces of information are not written into the repository, they do not exist; if they do not exist, the system degenerates into an empty shell waiting for oracles. Externalization may be insufficient, but without externalization, there is no truly meaningful fully automated AI operation.

Moreover, one must not fantasize that stronger models can replace external knowledge. Stronger models can provide more world knowledge and more judgment and choices within a single conversation, but weaker models can also compensate through longer computation processes and external docs—the difference in essential capability is not large, while costs can be dramatically reduced. World knowledge itself drifts, domain constraints change, and long-term autonomous systems must treat external docs as an interface for injecting new knowledge, allowing new facts, new boundaries, and new lessons to flow continuously into the system. Therefore, the AI's ability to grasp external knowledge is more important than how much world knowledge the model has memorized internally.

Mission Driver is the executor of this process, and also a verifier. What it verifies is not "whether AI can complete tasks," but: when the last session ends and the last executor leaves, does this project still know who it is, where it is going, and how to return when it has deviated? Have direction, proof, memory, and adjudication structures been completed to the point where the project can continue evolving as the same project?

It is not about making some Agent remember the project, but about making the project itself no longer forget itself.

The question once asked: How to make Agents work stably over the long term.
The real question: How to make the project itself—documents, code, and tools such as Mission Driver running on top of them—constitute a continuously evolving subject.