DEV Community

Jonathan Linotte
Jonathan Linotte

Posted on • Originally published at harnais.be

The Architecture of Agency - Where does operational agency lives.

#agents #ai #programming #softwareengineering

The model kept on a leash, the proof required

Where does operational agency lives in an AI agent system that actually works—and what does the word *harness mean once we stop fooling ourselves?*

TL;DR — In agent systems that actually work in production, it's almost never the model that decides what to do next: it's deterministic code. The model infers, reads, classifies, drafts — the code routes, validates, and rules. This piece argues for a simple stance: stop pretending autonomy lives in the model, and build the harness for what it actually is — an architecture that keeps operational agency in code, with computational verdicts, stratified permissions, and a 1.0 confidence threshold for anything irreversible.

An AI agent is an LLM given tools, an execution loop, and the autonomy to decide which tools to call, in what order, and when to stop. What distinguishes it from a simple workflow is precisely this: the model directs its own process rather than following a predefined code path.

The word harness comes from the Old French harnois (c. 1300), itself borrowed from the Old Norse hernest—"provisions for an army." Historically, a harness is a soldier’s gear or the network of straps routing a horse's power. In both cases, it is a structure of constraint. It converts raw force into directed work.

In AI engineering, the harness is the wrapper that equips a model to act. "The system that turns a model into something that can take actions," as MindStudio puts it. "An agent harness wraps around a model to manage long-running tasks," writes Aakash Gupta, adding: "Think of the model as an engine. The harness is the car." Anthropic, in a November 2025 engineering post (Effective Harnesses for Long-Running Agents), describes their Claude Agent SDK as "a powerful, general-purpose agent harness."

The Inversion: Where Decisions Go to Die

In agent systems that work in production—and I mean work, not just demo—the entity deciding what to do next is almost never the model. It is code. It is a deterministic function that inspects an input, checks a condition, and makes a call.

The model’s role in these systems is different, though equally essential: it infers. It reads ambiguous text, extracts meaning, proposes wording, evaluates quality, and reframes ideas. It is a sophisticated classifier, a writer, an evaluator. But the operational decision to call a specific tool with specific arguments at a specific moment is made by procedural code consuming the model's output.

When the harness evaluates what the model produced, the verdict—ACCEPTABLE, REVISE, BLOCKED—does not come from the model either. It comes from deterministic tests parsing the output. The model provides the raw material; the test delivers the verdict.

In production systems, model autonomy is a metaphor. The system runs because code has decided what to do with the model's output. This is where the word harness recovers its literal meaning. If operational agency lives in the code, the harness is exactly that: the structural framework that keeps the model in its role as a reader, routing its output into directed work.

This intuition isn't new. As early as 2011, Léon Bottou (From Machine Learning to Machine Reasoning) anticipated that the algebraic composition of modules produces reasoning that individual modules lack. Recently, this has crystallized into a discipline: harness engineering. Mitchell Hashimoto coined the term in My AI Adoption Journey (February 5, 2026). Ryan Lopopolo adopted it six days later in an OpenAI post (Harness Engineering, February 11). Birgitta Böckeler then offered a two-dimensional analytical framework (Harness engineering for coding agent users, April 2, 2026):

  • Guides that orient the agent before it acts.
  • Sensors that measure what it produces.

Each can be computational—yielding results that are "reliable"—or inferential, which remain "more non-deterministic." The matrix is useful, and its rapid adoption across the industry proves it. But it remains descriptive: it tells us what a harness contains without dictating where operational agency should reside.

Meanwhile, a parallel stance—code decides, the model infers—has been publicly championed by several teams. On the same day as Hashimoto, Nathan Sportsman at Praetorian formulated it bluntly:

"We transform the LLM from a 'creative assistant' into a deterministic component of the software supply chain."

Microsoft took the same direction with its Conductor framework (May 14, 2026): routing between agents is defined in YAML and remains entirely deterministic—"the orchestration layer consumes zero tokens."

In a February 2026 arXiv paper (Trustworthy Agentic AI Requires Deterministic Architectural Boundaries), Bhattarai and Vu argued that the reliability of an agentic system stems not from safety-aligning models, but from enforcing strict architectural boundaries. Cao et al., in their ESAA paper (February 2026), formalized this in identical terms, calling for a "strict separation between the Cognitive Blueprint… and the Runtime Engine." Earlier still, The Plausibility Trap (January 2026) proposed a "Deterministic-Probabilistic Decision Matrix" to decide, at every fork in the road, when to invoke a model and when to bypass it.

My position is unequivocal: any sensor delivering a verdict must be computational by default. Operational decisions cannot afford to be probabilistic without abandoning auditability.

Agency does not live in the model. It lives in the code that orchestrates it. Admitting this explicitly—moving it where it already resides in practice—is not a pragmatic compromise on an ideal of autonomy. It is reclaiming the true meaning of the words we use.

Why This Shift Isn't Academic

You could dismiss this as semantic pedantry—arguing that whether the code or the model decides, the outcome is the same. It isn't. This distinction marks the boundary between a debate over vocabulary and a fundamental architectural choice.

Ask a concrete question: can you audit the decision that was just made?

If the decision was made by an LLM, you can rerun the prompt, examine the output, and perhaps extract log-probabilities. But you cannot truly answer the question why. The model generated those tokens because they were the most statistically probable tokens given the prompt and its internal state. Beneath that, there is no formalizable reasoning you can extract and present to an auditor. You cannot audit a probability. The model guesses. It often guesses brilliantly, but it is guessing.

If the decision was made by code, auditing means reading that code. There is a file, a line, a logic, a unit test. The decision has a traceable, named provenance.

This is not a difference of degree; it is a fundamental difference in the epistemic nature of the decision. In 2026, this distinction is no longer merely aesthetic. The EU AI Act—though partially deferred—demands in Article 11, coupled with Annex IV, a technical documentation folder describing the system. Article 12 requires logging by design—meaning structured logging derived from the architecture, not a bolt-on feature added after the fact.

A system where operational decisions live in code can generate this compliance folder by reading its own source code. A system where decisions live in the model cannot—unless it merely logs API transcripts and prays the text explains everything. That won't pass muster with an informed regulator.

The Harness as Architecture

If agency lives in code, the harness reclaims its original purpose, and we can call this mechanism what it actually is: an architecture.

Practically, in the harness I am describing, a few ironclad rules must hold:

  • Deterministic First: Before any model call, attempt deterministic routing. The first rule in the contributor's guide: try_script() before any LLM. This prevents a trivial decision from taking a probabilistic path when a certain path would suffice.
  • Passive Context: Deterministic context collectors run in parallel before a single inference token is generated. The model doesn't decide what context is relevant; it receives it.
  • External Verdicts: A validator’s verdict doesn't come from the model, but from tests consuming its output. APPROVE, REVISE, BLOCKED, STALL, and ABSTAIN are values produced by deterministic code.
  • Stratified Permissions: Privileges are strictly stratified: READ_ONLY, WRITE_SAFE, WRITE_DANGEROUS, IRREVERSIBLE.
  • The Hard Ceiling: The confidence threshold for irreversible actions is set to 1.0—meaning explicit human approval. A point-of-no-return action is never triggered by raw model reasoning.
  • Atomic Mutations: State mutations use a temp + rename pattern: you write to a temporary file, then rename it atomically. A network drop no longer leaves a partial state on disk; a crash goes back to being just a crash, not data corruption.

None of these decisions are exotic. They have existed in classic industrial software for decades. What is new—and what is worth articulating as a stance—is applying them to an agentic system while accepting that they are not arbitrary constraints imposed on a model’s autonomy. They are the architecture of agency itself.

I am not describing a finished system, designed all at once a priori like a North Star on a whiteboard. As Hashimoto noted, a harness grows by accretion: it maps what the system has learned not to do, and why. For auditing, this is a core property, not a byproduct: the justification for every constraint is, by design, timestamped and defensible.

The Counterargument, and Its Reversal

The counterargument is familiar: if you put all the intelligence into the code, you lose what makes LLMs interesting. You are just rebuilding an 1980s expert system, using LLMs as mere subroutines.

It is a serious objection, but it misses the mark by a step. The model's capabilities aren't lost; they are leveraged within a system where code retains the final say. The model is summoned wherever a task demands comprehension: reading text, extracting intent, classifying sentiment, rewriting, summarizing, or qualitative evaluation. These are hard—sometimes irreducibly hard—problems, and the model solves them better than anything we have ever built.

But these tasks are not operational decisions. They are the raw material for them. Stratifying permissions is not an incidental precaution; it turns rigidity into a virtue. An unforeseen edge case doesn't trigger improvised action; it triggers a STALL, an ABSTAIN, or an escalation. Faced with the unknown, the system halts instead of improvising.

A second, more recent objection has been circulating, and it deserves a brief response. In February 2026, Ryan Lopopolo's team at OpenAI demonstrated that a million-line codebase could be built in five months by just three engineers, without a single line written by hand, inside a harness relying heavily on inferential guides and sensors.

The takeaway might seem to be that determinism doesn't scale. But the Codex experiment is, by design, an interactive process with a human in the loop at every pull request. This is precisely the scenario where agency can legitimately shift toward the model, because a human downstream delivers the final operational verdict.

This is fundamentally different from a long-running, autonomous system that must update shared state, trigger irreversible actions, or account for its decisions to a regulator without continuous human supervision. These are two distinct regimes, and my argument concerns the latter.

The error of the opposing view—in both its variants—is confusing the capacity for interpretation with the capacity for decision-making. A model that reads an email brilliantly has no inherent right, by virtue of that competence, to decide to file it, book a meeting, or draft a response. These are distinct decisions requiring systemic context, constraints, and user preferences that the model simply does not possess. Someone—specifically, the code—must explicitly articulate those preferences and anchor the model's output to them. And it turns out that in every system that works without a human holding its hand at every step, that "someone" is code. The question isn't whether we write it; it's whether we write it out in the open or pretend it doesn't exist.

These Are Matters of Taste

Building a harness like the one I describe requires choices at every intersection that cannot be reduced to technical optimization. Should the Verdict enum have five values or six? Should the confidence threshold for irreversible actions be 1.0 or 0.95? Should log writes be synchronous or deferred?

We can, and should, debate each point, but no technical benchmark will definitively settle them. In the end, it comes down to a matter of taste—an architectural stylistic coherence that defines what the system is and what it isn't.

These choices of taste cannot be delegated to a model. They can be debated with a model, or stress-tested by one, but they ultimately belong to a human who maintains the system over time and answers, in the first person, for the consequences of those choices.

This, I believe, is precisely why the metaphor of the autonomous agent is so seductive: it promises to relieve us of this burden. But it doesn't relieve us of it—because it can't. It merely hides it. The stance I am advocating for is, at the very least, to stop hiding that burden. Name it, document it, and make it auditable.

— From Brussels, the city behind the AI Act, where administrative
form has been turned into a critical tool since the 20th century. —

— John Linotte · Département des Harnais · Bruxelles · 2026-05-22
Originally published on Département des Harnais.

References

Top comments (0)