Controlled Emergence: AVL Code's Engineering Paradigm (Part 3)
— From Theory to Practice, and Seven Engineering Principles

This is Part 3 of the series "Controlled Emergence: AVL Code's Engineering Paradigm," published over three days: Part 1, "Emergence Is Not Magic, It Is a System Property" (July 16) · Part 2, "Harness Engineering and Loop Engineering" (July 17) · Part 3 (this post, July 18).

Part 1 settled the conceptual boundary of emergence: functional behavior can emerge from a system, but cognition cannot be inferred from it. Part 2 supplied the method: the Harness connects capability to the real world, and the Loop applies feedback control to an object that cannot be fully modeled.

Whether the method can land on a real product is another question: whether phase boundaries are enforced by the runtime, whether the objective can persist across turns, whether permissions can genuinely refuse an out-of-bounds action, and whether the exception paths have a backstop. This part maps those methods onto AVL Code's concrete mechanisms.

6. From Theory to Practice: AVL Code's Harness and GOAL Loop

We built AVL Code not to wrap some LLM in a desktop interface, but to turn model capability into an agent system that genuinely works on an engineering site. The model proposes candidate actions, work modes mark out the phases, Context organizes the conditions of the current turn, Tools and permissions govern real-world actions, GOAL holds the objective across turns, check gates supply factual evidence, and self-repair and watchdogs handle exceptions. The problem we set out to solve is not "how to get the model to take a few more steps," but "how to keep a long task moving forward in a real environment, and bring it to a reliable stop when it is finished, blocked, or out of bounds." That is AVL Code's engineering answer to the Harness and the Loop.

6.1 Using Work Modes to Build a Phase State Machine

The AVL Code user manual defines five work modes — auto, plan, prepare, execute, assess — and recommends the phase flow plan → prepare → execute → assess. Of those, plan and assess are read-only as enforced by the runtime; no prompt or hook can get around it.

The systemic point of this design is not to add five tabs to the interface, but to separate the objective and the available actuators of each phase:

auto is not a fixed step within plan → prepare → execute → assess; it is a one-stop autonomous mode for lightweight tasks: the runtime lets the agent choose directly, based on the current Context, whether to answer or to call a Tool, cutting the cost of switching phases by hand. Once a task involves larger changes, ambiguous requirements, or higher risk, entering the phased flow explicitly still makes it easier to establish confirmation points, permission boundaries, and acceptance evidence.

Switching modes changes both the assistant configuration and the set of Tool permissions, which shows that phase boundaries are enforced by the runtime rather than left to the model's "good behavior." Work modes and GOAL are not two interchangeable flows: the mode answers "how work is allowed to proceed in this phase," while GOAL answers "what objective to keep pushing toward, and when to continue or stop."

6.2 Using GOAL to Persist the Objective, and Context to Organize the Current Turn's State

The GOAL introduced in Part 2 is a session-level stable control state: it holds the Objective, the active / paused / complete / budget_limited state, the Token budget, usage, and the consecutive continuation count. Context, by contrast, is the working surface reassembled each turn, carrying the current goal block, the message history, Tool results, project instructions, and the local state of the run. Only by keeping the two apart can you avoid mistaking "the objective still exists" for "the objective must occupy every turn's entire prompt verbatim."

AVL Code can inject AGENT.md, AGENTS.md, or CLAUDE.md into Context as project instructions; Skills package domain workflows; a Plan describes phases, inputs, outputs, and risks; Todos record pending, in-progress, done, skipped, or failed states. GOAL keeps the main thread stable, while these Context components tell the model where it stands and what methods are available.

When the history approaches the context limit, Compact compresses earlier messages while preserving the plan, the todos, key Tool conclusions, user decisions, and necessary facts. Tool results are also size-clamped, with a context-capacity estimate before they are sent. What these mechanisms address is not "the model's parameters aren't smart enough," but state visibility and signal quality over a long-running task.

You can think of GOAL as the control loop's reference input and persistent state, and of the Context Harness as the state estimator: the former gives a stable answer to "where we ultimately need to go," the latter a continuous answer to "where we are now, which observations are trustworthy, and what is still missing for the next step."

6.3 Using Tools, Permissions, and the Sandbox to Separate "Proposal" from "Action"

AVL Code organizes files, commands, version control, code intelligence, security analysis, and external services into Tools. Once the model proposes a tool call, the runtime still decides whether to execute it according to the three-state permission — "enabled / ask / disabled"; when approval is required, the user sees the tool name, the arguments, and the scope of impact, and a timeout with no response is treated as a denial.

More importantly, some hard lines exist independently of ordinary authorization. The samples/ directory, for instance, forcibly disables execution-type tools, and destructive commands and dangerous injections remain subject to argument checks. This line has held throughout our real analyses: whether triaging the fast16 malware, recovering the steganographic payload Darkhotel hid inside a JPEG, or verifying Grok Build CLI's offline installer, the samples stayed inside the read-only sandbox from start to finish. This is where the key principle of the Harness shows itself:

A model may propose an action, but the legitimacy of that action, its permissions, and the boundary of its side effects must be adjudicated by deterministic machinery outside the model.

This both shrinks the blast radius of undesired emergence and makes more ambitious functional emergence possible — only when the execution boundary is trustworthy is a system fit to be given a larger space to act in. GOAL can ask the system to keep going, but it cannot bypass the Tool schema, permission approval, path boundaries, or the sandbox; persistence and the legitimacy of action are the responsibility of different layers.

6.4 Using Check Gates to Give GOAL Turns Factual Feedback

Figure 5 in Part 2 already gave the GOAL main control loop; here it is again, for easy comparison:

On this loop, LSP diagnostics, tests, Lint, SAST, and human acceptance are not a parallel loop of their own but the factual observation and evidence gate at the end of a turn. Drawing them directly as an "edit — check — fix" main loop would leave out the more critical control states: the persistent objective, automatic continuation, the budget, and human takeover.

With the self-check gate enabled, the runtime can run the selected checks first: on failure it writes the structured results back into Context and requires the agent to keep working on them; on a pass, or when no check applies, it hands the right to continue back to GOAL. The gate distinguishes block from report, limits the scope of the checks, and sets a ceiling on consecutive injections, so that flaky tests or unfixable problems cannot cause an infinite loop.

The division of labor is clear: GOAL decides "whether the task should still be pushed forward," and the check gate answers "whether this turn's result has enough evidence behind it." The former maintains the objective, the state, the budget, automatic advance, and the conditions for human takeover; the latter raises observation quality and blocks the evidence-free "false completion."

6.5 Using Self-Repair, Budgets, and Watchdogs to Handle Non-Ideal Operation

GOAL handles continuing and stopping between normal turns; real operation also has to handle the exception paths: context overflow, provider overload, network jitter, truncated output, repetitive reasoning, and long stretches without progress. AVL Code's self-repair mechanism picks, by error class, among compact-and-retry, provider fallback, backoff retry, or stopping and handing control back to the user; when the same check fails over and over it prompts for a change of approach, and stops once the ceiling is reached.

Subtasks also get an idle watchdog and an absolute time backstop; parallel tasks have caps on concurrency and on waiting; long-running background tasks save their progress and support resuming after an interruption (the multi-agent parallel analysis of an Android banking trojan uses exactly this parallel machinery). Together they answer the questions a closed-loop system is most likely to overlook:

• If an observation is temporarily missing, will the task be wrongly judged dead?
• If output keeps coming but no progress is made, how do we recognize "busy instability"?
• If automatic repair is not working, when do we stop consuming resources?
• If the system crashes, can the state be restored rather than guessed at from scratch?

Together with GOAL's Token budget, its halt on terminal errors, and its ceiling of 50 automatic continuations, these mechanisms form a multi-layered protection. Without those boundaries, "autonomy" easily degenerates into an infinite loop; with them, a system can hold to a predictable failure mode across a long task.

6.6 Controlled Emergence Within a Single Task

Take "add input validation to an existing service and get it through the security checks" as an example. The AVL Code Harness can form a chain of operation like this:

1. The user pins the task objective down with /goal and sets a Token budget as needed; GOAL enters active.
2. In plan mode, a read-only scan of the repository, the project instructions, and the relevant Skills produces the scope of impact, a test strategy, and a risk statement.
3. After the user confirms the plan, the mode switches to execute, and the runtime assembles the GOAL goal block together with the current Plan, Todos, files, and past observations into Context.
4. The LLM proposes an edit or a tool call; only after the Tool gateway completes argument checks, the permission decision, and any required approval does it act on the workspace.
5. LSP, tests, Lint, or SAST return factual observations at the end of the turn; failures are written back into Context in structured form, for the agent to keep working on in the next turn.
6. If the task is not yet finished and there is no stop signal, GOAL appends a hidden continuation message, carrying the same objective automatically into the next turn instead of waiting for the user to type "continue" over and over.
7. Once the technical gates pass, the mode can switch to assess for a read-only review of the diff, requirement coverage, and risk; when the objective is confirmed met, it closes out as complete.
8. If a user decision is needed, a terminal error occurs, or the budget or the consecutive-continuation ceiling is reached, the runtime stops advancing automatically and hands control back.

Not one of these steps requires assuming that "the model has become conscious." Yet observed at the system boundary, a whole-system property really does appear that no individual part possesses: within organizational rules and safety boundaries, perceiving, acting, and correcting errors across turns around a persistent objective, and converging when the evidence is in or a boundary is reached.

This is the functional-behavior emergence that AVL Code embodies, and it is what Harness engineering sets out to control and amplify.

The chain above is illustrative. What a real one looks like takes no imagination: the public cases on our website put every session up exactly as it ran — the Antiy IEP EPP automated inspection and CVE vulnerability scanning is a textbook long-task closed loop, while the MLPS 2.0 baseline compliance check shows how gates and evidence drive a conclusion. Their reasoning, tool calls, errors, and recovery are inspectable end to end — including the few steps where a wrong judgment had to be backed out and redone. These mechanisms are written into the user manual and the reference manual, and the same machinery is what runs in those sessions — not a promise written up at release time.

7. Seven Engineering Principles for Controlled Emergence

7.1 Define the System Boundary Before Talking About Intelligence

Be clear about what is being evaluated: a bare model, a model service with Context, an agent, or an engineering system that includes people and organizational processes. Different boundaries assign properties differently.

7.2 Describe Emergence in Terms of Acceptance-Testable Behavior

Ask less about "whether it really thinks," and define more carefully "whether it can complete the task within a given repository, permission set, and time budget, and what evidence it submits."

7.3 Keep Soft Constraints Apart from Hard Constraints

Project instructions, Skills, and prompts raise the probability of correct behavior; permissions, schemas, the sandbox, approval, gates, and budgets block unacceptable behavior.

7.4 Improve Factual Feedback First, Rather Than Endlessly Lengthening the Prompt

Real files, the compiler, tests, logs, and Tool execution results make up verifiable factual feedback, which is usually worth more than the model's own assertions. High-quality, low-noise, structured factual feedback is the foundation on which a closed loop converges.

7.5 Every Loop Must Have a Stop Condition

At a minimum, define the conditions for success, failure, blockage, risk, time, Tokens, retries, and human takeover. An agent that cannot stop is not more autonomous, only harder to control.

7.6 Do Both Verification and Validation

Passing tests proves the implementation meets certain technical conditions; it does not prove the requirements are right. A satisfied user proves the direction may be right; it does not prove the implementation is free of defects.

7.7 Turn Failure Trajectories into System Assets

Keep the key observations, design decisions, effective patterns, and failure anti-patterns, and let them enter organizational knowledge after review. Controlled emergence is not a one-off "flash of inspiration" but an engineering capability accumulated across tasks.

Closing

The LLM is an important source of capability in a generative AI system, but it is not a complete engineering product. What actually turns probabilistic generation into productivity is what surrounds the model — Context, Tool, State, Policy, Loop, V&V, and Human — and the designed relationships among them.

Emergence tells us that a system as a whole can have properties its parts do not; control engineering tells us that capability must be placed inside a closed loop of observe — feed back — correct — stop; systems engineering asks us to manage that whole starting from stakeholder objectives, the life cycle, risk, and evidence. Put the three together and what you get is not "proof that AI already thinks the way people do," but a more pragmatic road:

Do not mythologize the model, and do not deny what the system can do; do not chase boundless autonomy — constrain action with the Harness, drive convergence with the Loop, and verify the value of the whole with systems engineering.

In this sense, AVL Code's engineering paradigm is not about waiting for intelligence to emerge mysteriously; it is about actively designing the conditions under which valuable functional behavior is more likely to appear, is tested against real evidence, and is safely brought to a halt when it fails. That is controlled emergence.

We'll be waiting for you in AVL Code — riding a donkey.

References

Key AVL Code Material

• AVL Code website
• AVL Code user manual
• AVL Code reference manual
• AVL Code Dev Team (2026): Putting a "Self-Disciplined Security Engineer" on Your Machine — The AVL Code Team's Story
• Yaojin (2026): On the Road of Agent Development, We Are Don Quixote

Earlier in This Series

• Controlled Emergence: AVL Code's Engineering Paradigm (Part 1) — Emergence Is Not Magic, It Is a System Property
• Controlled Emergence: AVL Code's Engineering Paradigm (Part 2) — Harness Engineering and Loop Engineering

AVL Code — the AVL security engine, with intelligence at your side. From the Antiy Landi team.