Controlled Emergence: AVL Code's Engineering Paradigm (Part 2)— Harness Engineering and Loop Engineering

This is Part 2 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 (this post, July 17) · Part 3, "From Theory to Practice, and Seven Engineering Principles" (July 18).

Part 1 settled two things: emergence is an observable, measurable property that the system as a whole has over and above its parts; and what emerges once an LLM is combined with context, tools, and a runtime is functional behavior, not cognitive conclusions.

But "functional behavior can emerge" only answers what the phenomenon is; it does not answer how to engineer it. The model merely puts forward proposals — what actually decides whether those proposals can become constrained real-world actions is the layer of structure outside the model. This post is about that layer: the harness is responsible for connecting capability to the real world, and the loop is responsible for making the system converge across many turns and come to a stop.

3. Harness Engineering: Connecting Model Capability to the Real World

A harness, in its original sense, is tack: it does not replace the source of power, but it connects that power to steering, load, and braking. For generative AI engineering, the harness is the set of engineering structures surrounding the model, responsible for turning probabilistic output into constrained task execution.

A practical agent system can be approximated as:

Agent\ System = LLM + Context + Tool + State + Policy + Loop + V\&V + Human

The agent runtime connects model capability to the real world through orchestration, authorization, and external tools — Figure 4: The agent runtime hands the LLM's probabilistic decisions to the orchestration and execution layer, which calls external tools after validation, authorization, and timeout control, then writes the results back into the context; model capability thereby becomes a real-world action that can be constrained and fed back on.

Within this, the harness typically covers the main parts outside the model:

Harness Component	Question It Answers
Model and vendor adaptation	Which model to call, whether to fail over, how parameters are set
Context assembly	Which instructions, files, history, skills, and tool results enter this turn
Tool gateway	Which actions the model may propose, how arguments are validated, how results are written back
State management	How goals, plans, todos, artifacts, and check results are persisted
Permissions and sandbox	Which actions are allowed, which need approval, which must be refused
Loop control	Under what conditions to continue, switch strategy, retry, pause, or stop
Verification and evaluation	How to judge "it was done right" and "it was the right thing to do"
Observability and recovery	How to audit the trace, locate failures, and continue from an interruption

A harness is not a longer system prompt. Prompts, AGENTS.md, and skills mainly form soft constraints, shifting output probabilities through the context; permission checks, JSON Schema, path boundaries, approval, timeouts, test gates, and sandboxes are hard constraints, enforced by deterministic code outside the model.

Constraint Type	Example	Can It Enforce a Guarantee
Soft constraint	"Read the code before modifying it", "Follow the team's naming conventions"	Can only raise the probability of compliance
Structural constraint	Tool schemas, state machines, restricted output formats	Can limit the space of expression and transitions
Hard constraint	Write bans, sandboxes, argument validation, approval, budget ceilings	Can refuse out-of-bounds actions at runtime
Evidence gate	Compilation, tests, lint, SAST, human acceptance	Can stop a substandard result from being declared complete

The key to generative AI engineering is not demanding that a probabilistic model turn itself into a deterministic program, but letting deterministic mechanisms manage its contact surface with the real world.

4. Loop Engineering: Feedback Control on an Incomplete Model

If the harness decides "what the system is made of and where its boundaries lie", the loop decides "how the system holds to its goal across many turns, makes use of feedback, and continues or stops under the right conditions". It is not "letting the model answer a few more times", nor is it the same as "running the tests over and over after changing the code"; it is a runtime control loop made up of goal state, context updates, action execution, observation of results, resource budget, and stop conditions.

A single agent loop can still be abstracted as:

\begin{aligned} z_k &\sim \pi_\theta(\cdot \mid C_k) \\ a_k &= G(z_k, P) \\ o_{k+1} &= E(T(a_k)) \\ C_{k+1} &= U(C_k, a_k, o_{k+1}, r) \end{aligned}

Here, $r$ is the goal and its acceptance criteria, $z_k$ is the text or action proposal the model produces, $G$ validates and releases actions according to the permission policy $P$ , $T$ is the tool, $E$ is the external environment, $o_{k+1}$ is the factual observation obtained this turn, and $U$ reorganizes the action, the result, and the task state into the next turn's context. The genuinely hard part is not writing this set of formulas, but turning "keep going or stop" from a vague prompt into an executable state machine.

AVL Code's GOAL command is exactly one concrete implementation. It keeps a long task's goal, state, token budget, usage, and consecutive auto-continuation count in the session, so that the control loop does not depend on the model happening to "remember what it still has to do".

The AVL Code GOAL session-level goal auto-continuation mechanism — Figure 5: AVL Code GOAL organizes goal injection, the agent turn, usage accounting, stop signals, auto-continuation, and human control into a session-level closed loop. A normal terminal state continues by default; completion, waiting on the user, a terminal error, an exhausted budget, and the consecutive-continuation ceiling constitute explicit stop conditions.

4.1 GOAL Turns a Long Task into a Stateful Closed Loop

Users create or update a goal with /goal <objective>, set the token budget with /goal budget N, and can control the lifecycle through pause, resume, complete, and clear. GOAL has only four persistent states — active, paused, complete, and budget_limited; when the goal changes, the next turn receives realignment guidance rather than carrying on with the old goal out of inertia.

While GOAL is active, the runtime injects the goal block into the context, and the agent uses it to read the environment, call tools or subagents, and complete a turn. Once the turn reaches its end, the system first accumulates its own and its subagents' token usage and tool calls, then runs the continuation decision:

if total usage reaches the budget, the state moves to budget_limited and auto-continuation stops;
if the turn ends in a terminal error, continuation stops but active is retained, and control is handed back to the user;
if the last line of the response is <goal-status>complete</goal-status>, the state moves to complete;
if the last line of the response is <goal-status>need-input</goal-status>, it waits for the user to supply the necessary decision;
in every other case, including no tag being output at all, the default is to continue: the system appends a hidden message telling the agent to keep advancing the goal, and automatically starts the next turn.

When consecutive auto-continuations exceed 50 turns, the runtime stops advancing on its own and prompts the user to check progress; a real user intervention resets the consecutive-continuation count to zero. What this embodies is not "letting the model decide everything", but the model reporting a semantic state while a deterministic runtime validates the signal, keeps the accounts, transitions the state, and enforces the ceilings.

This is isomorphic to the basic ideas of control engineering, but the correspondence has already come down from abstract metaphor to inspectable product mechanism:

Control Engineering Concept	Its Counterpart in AVL Code GOAL
Reference input	The `Objective` persisted in the session, plus the user's acceptance requirements
Controller	The LLM's action proposals + the GOAL auto-continuation decision
Plant	The codebase, the build environment, external services, and task artifacts
Actuator	Tools, subagents, and permission-controlled runtime actions
Observation	Tool results, terminal responses, errors, and usage statistics
State estimation	The context, GOAL state, plan, todos, and history summaries
Control action	Goal-block injection, the hidden continuation message, pause, resume, and human takeover
Protective device	The token budget, halting on a terminal error, the 50-turn ceiling, permissions and approval

Tests, lint, SAST, and human acceptance still matter, but they are observations and gates at the end of a turn, able to take over a single continuation decision; they are not the GOAL main state machine itself. GOAL is responsible for "which goal to continue around, what state we are currently in, how many resources can still be spent, and when it must stop", while the check gates are responsible for supplying the factual evidence of "whether this step satisfies the technical constraints".

4.2 It Is Not a Simple Copy of a Traditional Controller

The "controller" in AI engineering is probabilistic; codebases and external services are high-dimensional, discrete, time-varying environments; the criteria for success often contain semantic judgment; and the sensors can observe only local state. Engineers usually have neither a complete model of the plant nor any way to prove that each action moves monotonically closer to the goal.

So loop engineering cannot simply copy over a fixed set of PID parameters; it has to absorb the more general ideas of control:

Execute in small steps, shortening the open-loop distance: the larger a single change, the harder it is to locate cause and effect after a failure;
Raise observation quality: prefer the compiler, tests, static analysis, and real tool results over letting the model guess — Network Fault Localization in a Complex Business System is a ready-made example: a chronic network problem that had gone five years without being directly localized was walked step by step to its root cause out of the evidence in 2.2 GB of packet captures, not by guesswork;
Control the feedback gain: failure information should be relevant, structured, and not excessive, so that a whole block of logs does not drown out the useful signal;
Add damping and protection: set ceilings on retries, turns, time, tokens, concurrency, and side effects;
Recognize oscillation and instability: when the same fix repeats over and over, changes keep getting reverted, or the todos stop advancing for a long stretch, switch strategy or stop;
Keep human control: high-risk actions, ambiguous requirements, and irreversible changes must have confirmation points.

The purpose of the loop is not "to keep the agent running forever", but to have it keep obtaining factual feedback around a stable goal, and to exit predictably when completion, a blocker, an error, the budget, or a human boundary appears. The value of AVL Code's GOAL lies precisely in turning this control over continuing and stopping from a wish in a prompt into a runtime mechanism.

5. Systems Engineering: The Full View Above Harness and Loop

Harness engineering mainly handles capability integration and boundaries; loop engineering mainly handles runtime feedback and convergence; systems engineering has to cover the full lifecycle from requirements to retirement.

Layer	Core Question	Typical Artifacts
Harness engineering	How to reliably connect the model, context, tools, permissions, and state	Tool gateway, context pipeline, permission policy, state machine
Loop engineering	How to correct course from observations, and when to continue, reroute, or stop	Feedback loops, gates, retry policy, budgets, watchdogs
Systems engineering	Why it is being built, for whom, whether the whole meets the mission, how lifecycle risk is managed	Requirements, architecture, V&V, risk, configuration, operations, and evolution mechanisms

SEBoK's Systems Engineering Core Concepts brings components, internal networks, the external environment, boundaries, behavior, and history all into the description of a system, and treats emergence and feedback as core concepts of systems science. That is a hint to us: the system-of-interest of an AI product should not be drawn as merely a model API, but should include at least the runtime, the workspace, tools, organizational rules, users, and the external environment.

5.1 Verification and Validation Are Two Different Feedback Lines

SEBoK's System Verification stresses using objective evidence to check whether a system satisfies its specified requirements, architecture, and design properties; System Validation is concerned with whether the system satisfies its specific intended use and stakeholder goals in the expected environment. In the common engineering phrasing:

Verification: did we build the system right? For example, whether the code compiles, whether the tests pass, whether permissions take effect as designed;
Validation: did we build the right system? For example, whether the change genuinely solves the user's problem, whether the result suits the real workflow.

Test gates alone can produce the outcome of "all tests pass, but the requirement was misunderstood"; acceptance left to the user's gut feeling alone can miss implementation defects. Controlled emergence needs machine evidence and human judgment of purpose to close the loop together.

5.2 V&V for AI Systems Must Run Through the Lifecycle

SEBoK's entry on V&V for AI systems points out that AI subsystems are characterized by a missing decision oracle, the impossibility of being one hundred percent accurate, undetermined behavior on untested inputs, and heavy dependence on training data. V&V therefore cannot be a single exam before launch; it has to enter the whole process of requirements, design, integration, operation, and updates.

For an agent product, this means evaluating not only the model but also context assembly, tool interfaces, permission policy, loop stability, failure recovery, and the human-in-the-loop process. After a model upgrade, the behavior of an old harness may change; after a tool schema changes, an old skill may stop working; after permissions are loosened, the same planning capability may produce different risks. Systems engineering is responsible for managing these interlocks, not merely for comparing model leaderboards.

Summary and a Look Ahead to Part 3

The harness answers "what the system is made of and where its boundaries lie", the loop answers "how to continue or stop based on feedback", and systems engineering asks us to manage the whole starting from stakeholder goals, lifecycle, risk, and evidence.

All three layers are about method. Whether they can land in a real product is another question: whether stage boundaries are enforced by the runtime, whether goals can persist across turns, whether permissions can genuinely refuse an out-of-bounds action, whether the exception paths have a fallback. Part 3, From Theory to Practice, and Seven Engineering Principles (published July 18), will match these methods against AVL Code's concrete mechanisms — working modes, GOAL, tools and permissions, check gates, self-healing and watchdogs — and set out the seven engineering principles of controlled emergence.

References

Key Systems Engineering Sources

Key AVL Code Sources

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