Agent = Model + Harness
How guides, sensors, the data context layer, orchestration, and the feedback layer turn what this series has built into an auditable program, and why the supplier's inner harness alone does not cover Brazilian regulatory obligations.
The harness that already existed without a name#
In the previous five articles, we built, piece by piece, the infrastructure of a generative AI program at a regulated financial institution: policy, regulatory framework, frameworks, architecture, and engineering process. All that remained was a name for the system formed by all these components: the harness.
The formula organizing this idea is straightforward: Agent = Model + Harness
Mitchell Hashimoto helped popularize the term harness engineering in February 2026 by describing a simple discipline: each recurring agent error should result in an improvement to its surrounding environment, instructions, or tools. Days later, OpenAI presented an experiment in agent-first development, summarized by the phrase "Humans steer. Agents execute." The equation Agent = Model + Harness, subsequently systematized by LangChain and used by Birgitta Böckeler in her Thoughtworks taxonomy, helps organize this shift in perspective.
As frontier models converge across various capabilities, a growing share of differentiation moves away from the isolated choice of model toward the system built around it.
The three maturity phases of AI engineering#
Harness engineering did not emerge in a vacuum. One useful way to interpret this evolution is to divide it into three cumulative maturity layers, each built on the previous one:
Enlarge ↗The progression is cumulative. Harness engineering presupposes well-written prompts and well-managed context, organizing these practices into an operational structure.
The five layers of the harness#
Böckeler, from Thoughtworks, organizes the harness into two types of component: guides and sensors. Guides are feedforward controls: they instruct the agent on what it may do before an action, while sensors are feedback controls: they observe and validate behavior during or after execution.
An example makes the distinction concrete. CLAUDE.md is a guide because it directs the agent before it acts. A hook analyzing the result after a change acts as a sensor. When that same hook blocks a command before execution, it acts as a guard, an enforcement point.
From this foundation, the harness can be organized into five layers:
1. Guides#
Documents and settings that constrain agent behavior before action: CLAUDE.md, managed-settings.json, and corporate system prompts. In a financial institution, they may prohibit PII use, restrict external destinations, and define mandatory output standards.
2. Sensors and guards#
Hooks, validation loops, evals, drift detectors, quality gates, and SIEM integrations that observe, validate, or block actions during and after execution. Examples include prompt-linter, secret-scan, bash-guard, a SonarQube gate, and AI-specific SIEM use cases. The classification depends on the component's function and when it acts, not just the tool used.
3. Data context layer#
Certified data and authorized sources that the harness provides to the agent at runtime: the layer ensuring that the model reasons over trustworthy information within the permitted scope. Examples include an internal read-only SonarQube MCP and a sanitized Confluence knowledge base, without direct access to customer data.
4. Orchestration#
Task sequencing, review gates, and stopping conditions: the layer defining the order in which the agent works, when it may advance, and when it should interrupt execution for human review. In a regulated flow: spec → generation → hooks → gateway → CI/CD → human review → merge.
5. Feedback layer#
Capturing human corrections and turning these findings into active rules: the harness learns from mistakes without requiring model retraining. Review findings become new CLAUDE.md rules; recurring occurrences become detectable by prompt-linter.
These five layers operate at two levels: what the supplier provides by default and what the institution builds on that foundation. That difference is where Brazilian regulation enters the architecture.
Inner harness and outer harness: where regulation becomes a technical control#
Böckeler calls the layer the team builds over what the supplier has already embedded in the agent the user harness. In this article, I use inner harness and outer harness for the same distinction.
The inner harness is what Anthropic delivers with Claude Code: context window, native tools, execution loop, and basic permissions. Because it was developed for a global market, it does not incorporate by default the specific controls of CMN Resolution No. 4.893, the LGPD, Complementary Law 105, or CMN Resolution No. 5.274. The supplier cannot anticipate which obligations apply to each institution or what evidence a local regulator will require.
The outer harness is the layer built by the institution itself: corporate CLAUDE.md, managed settings, hooks, an on-premises gateway, MCP allowlist, CI/CD gates, human review, and SIEM integration. This is the layer where regulatory requirements, internal policies, and risk decisions become demonstrable technical controls.
Enlarge ↗The consequence is asymmetric: without the inner harness, there is no agent; without the outer harness, an agent exists in production, but not the ability to demonstrate the controls a regulatory inspection may require.
Enlarge ↗This forms a closed, auditable cycle independent of retraining. The mapping between regulations and layers is illustrative:
Enlarge ↗The failure modes the harness addresses#
Models used in isolation can hallucinate. Autonomous agents add a different category of risk: failures arising because the model executes sequences of actions without human supervision at every step. Some recur often enough to require specific controls.
Victory declaration bias or premature completion: the agent considers the task complete without checking whether the result is valid. The control is a mandatory CI gate before opening or approving any PR: if tests do not pass, the pipeline does not advance. This behavior can contribute to ASI09 Human-Agent Trust Exploitation when it induces human approval without sufficient validation.
Context anxiety: believing it is approaching its context window limit, the model takes shortcuts or abandons incomplete tasks, even when space remains available. Cognition AI documented this behavior in production with Claude Sonnet 4.5. The harness responds by dividing tasks into smaller steps, creating explicit checkpoints, and instructing the agent to pause when uncertain.
One-shotting overreach: the agent tries to complete the entire job in a single execution without intermediate reviews. The control combines per-session scope limits in guides with subtasks and review gates defined by orchestration.
Exfiltration through tool use - ASI02: the agent uses a tool to send data to an unauthorized destination. Mitigation combines destination allowlists, hooks, path-guard, egress controls, and read-only MCPs without access to customer data.
Indirect prompt injection - ASI01 Agent Goal Hijack: malicious content in files, repositories, or external sources attempts to redefine the agent's objectives. The control is to treat external content as data, never as trusted instructions, inspecting it before making it available to the model.
Regulatory hallucination: the agent cites a regulation with an incorrect number, article, content, or effective period. The control is an orchestration gate requiring legal or regulatory review before publication, merge, or any decision based on that reference.
The case of CVE-2026-21852, presented in Part 3 of the series, is a concrete example of risk associated with settings loaded from a repository. A malicious project could redirect ANTHROPIC_BASE_URL in Claude Code before the developer's trust confirmation. In the architecture proposed in this series, the vector would be mitigated by immutable corporate settings distributed through MDM, mandatory upgrading to a patched version (2.0.65 or higher), and egress controls capable of preventing redirects to unauthorized endpoints.
The feedback layer closes the loop#
The harness addresses errors structurally: not through retraining, but by creating constraints that prevent the same behavior from recurring. Hashimoto describes a similar mechanism, in which inappropriate behavior observed during use is turned into new rules, instructions, or improvements to the tools surrounding the agent.
This dynamic resembles the continual improvement process in clause 10 of ISO/IEC 42001, where a nonconformity should lead to correction, cause analysis, and action to prevent recurrence:
production occurrence → human review → root cause analysis → new rule → control update → recurrence blocked → new evaluation cycle
The rules accumulated in CLAUDE.md retain their date, origin, and rationale. The example below is illustrative; incidents, dates, and PR numbers are fictional:
Enlarge ↗Each entry represents an incident addressed. The date, origin, and resulting rule form the feedback layer's audit trail.
The model remains the same before and after correction; what changes is the harness, a behavioral constraint in the layer between the model and production, faster to apply than any adjustment to the model, as well as auditable and reversible.
There is, however, an important caveat: the harness also ages. Rules created for one model version can become unnecessary or even counterproductive in the next. Context anxiety itself illustrates the risk: mitigations written to work around one version's behavior become dead weight when the next version does not exhibit it in the same way. The harness must therefore be versioned and reassessed whenever the model changes. A control without continuous evaluation becomes operational debt.
The outer harness the series has already built#
Throughout the previous five articles, I described the components of the outer harness without using that name. This article organizes every piece within a common architecture:
Enlarge ↗The outer harness, then, was already built. What was missing was the concept to organize these pieces into a coherent architecture. With the harness named, the generative AI program becomes not merely functional but demonstrable: it becomes possible to show an auditor which layer addresses each risk, which artifact proves the control is active, and how the system learns when that control fails.
The six principles running through the series#
The program presented throughout this series can be summarized in six operational principles:
1. Regulation first#
No production environment should operate with real data before the approval of policy, impact analysis, applicable contractual instruments, and assessment of relevant regulatory requirements. The liability created by adopting things in the wrong order is difficult to reconstruct during an audit.
2. Residency constrains architecture#
The applicable treatment depends on where data is processed, not just where the supplier is headquartered. A gateway in a Brazilian environment centralizes inspection, minimization, and traceability before egress, supporting compliance with Complementary Law 105 and reducing LGPD-related exposure. By itself, it does not eliminate Article 33 requirements when personal data continues to be processed abroad.
3. Product is not supplier#
The data regime is defined by the surface used. The same supplier may offer products suitable for regulated workloads and others that should not receive sensitive data. Treating all these surfaces as equivalent is an architectural and governance risk.
4. Fail-closed as an invariant#
A control that can be bypassed when it fails is not an effective control. Without the gateway, there is no access. Without human review, there is no merge. Without evidence, there is no approval.
5. Spec first, code second#
Generative AI amplifies what it receives as context. Without structure, the model fills gaps and invents business rules. With a well-defined spec, it becomes an engineering amplifier.
6. Agent = Model + Harness#
Guides, sensors, data context, orchestration, and feedback are what turn a language model into a reliable, controllable, auditable agent in a regulated environment.
The model may be the same. The demonstrable control is not.
This is article 6 of 6 in the “Generative AI in a Regulated Financial Institution” series. Previous articles covered usage policy, the regulatory framework, risk frameworks, data residency architecture, and spec-driven development with AI.
Links:
Part 1 - The map of what lies ahead: https://bit.ly/4oXLCsi
Part 2 - The Brazilian regulatory maze: what BACEN, CVM, ANBIMA, and LGPD require before the first prompt: https://bit.ly/4wfQRG1
Part 3 - Frameworks in practice: NIST AI RMF, ISO 42001, OWASP, and GAIG translated into controls and evidence: https://bit.ly/4vzlXZf
Part 4 - Architecture: where policy becomes a technical control and why data residency defines the design: https://bit.ly/44EOSzh
Part 5 - Spec-driven development with AI: five antipatterns and the flow that makes the response traceable: https://bit.ly/4vchwmq