What is an AI harness?
An AI harness is the software around an AI model that manages how it carries out a task. It supplies instructions and information, connects approved tools, tracks progress and applies controls to actions. In an agent system, the harness determines how work continues, stops, recovers or reaches a person for approval.
AI harness
The surrounding runtime and controlsModel
Interpret and propose
Context
Instructions and sources
Tools
Scoped system interfaces
State
Progress and recovery
Verification
Results and human review
- Identity
- Permissions
- Approvals
- Budgets
- Evidence
What belongs inside an AI harness?
The harness connects a model’s responses to a working process. A model may propose a next step; surrounding software decides whether that step is valid, permitted and complete. For longer tasks, it also preserves progress across sessions. Anthropic’s long-running agent examples show why task state and checks matter.
The following responsibilities are a useful starting point. They can be supplied by your application, an SDK, a managed platform or a combination.
- Instructions and context
- Define the task, constraints and relevant information for the next model call. Keep external documents separate from trusted instructions.
- Knowledge and retrieval
- Bring in permitted records or source passages when needed. Retrieval-augmented generation (RAG) is one way to do this; some tasks need no retrieval at all.
- Tools and execution
- Expose specific functions, validate their inputs and check permission before execution. A model proposing a tool call does not itself grant access.
- State and recovery
- Record what has completed, what is pending and what needs reconciliation. Resuming work should preserve that history without repeating a completed action.
- Verification and oversight
- Check outputs and external results against the task. Apply approval rules, budgets, monitoring and escalation appropriate to the work.
RAG, persistent memory and multiple agents are optional design choices. A bounded task can have a much smaller harness.
Harnesses in working demonstrations
These demonstrations show two architectures we have built. A shared control plane is one design choice, not a requirement for every AI harness.
Demonstration
AI Control Plane
A shared control layer runs insurance, mortgage and finance workflows through one engine. It routes tasks to model tiers, holds sensitive actions for a person and records the workflow’s decisions and results.
Receive and route
Check and approve
Record and compare
Controls and responsibility
Policy failures are recorded too. Checks cover authority and excluded or masked information. The self-hosted comparison is labelled as a benchmark; it is not a general savings promise.
Demonstration
Financial Preparation Harness
Prior-period records and current financial statements become a structured, formula-driven review package. AI proposes document interpretations and mappings; code validates them and produces the figures for professional approval.
Map and validate
Calculate and reconcile
Review and export
Controls and responsibility
Figures come from code. Approval gates retain professional authority. Outgoing model requests are checked for excluded sensitive fields, and the administration view records model-tier cost per run.
The Ryzolv Harness Rules
An AI harness is only as safe as the rules it enforces. These are the five we build into every harness, whatever the industry.
The AI proposes, software validates, a human decides.
The model never has the last word. Its output is checked against hard rules before a qualified person sees it.
Example In tax preparation, that means the AI suggests how to classify an asset, the software checks it against a fixed list, and a CPA approves it.
The AI never produces a number on its own.
Every figure comes from a calculation that can be traced and rerun.
Example In financial reporting, a reviewer can click any figure and see exactly where it came from.
The AI sees only what it needs.
Identifying details are removed before anything reaches the model, and routine data is handled by plain software.
Example In healthcare, the model works on de-identified records; patient identity never leaves the system of record.
Every step is on the record.
Each run, proposal and decision is written to a tamper-resistant audit trail.
Example When a regulator or auditor asks "why did the system do this?", the answer is already logged.
Only a named human can approve.
No API key, machine account or AI agent can sign off.
Example In banking, an agent can prepare a payment, but only an authorised person can release it.
Proven in production
We've applied these rules in regulated tax preparation for business returns, where the AI handles the volume of workpaper preparation and every decision stays with the firm's CPAs. Details are under NDA.
Book a walkthrough of how we'd apply them to your workflowHuman-in-the-loop AI: who approves what
Human-in-the-loop AI places a person at a defined review or approval point. Under the Ryzolv Harness Rules, the AI proposes an action, software checks it against fixed rules and a qualified person decides whether it can proceed.
Approval belongs to a named, authorised person. An API key, machine account or AI agent cannot sign off. The proposal and the person’s decision form part of the activity record.
Harness, framework or platform?
These terms describe different responsibilities, but their boundaries overlap. An SDK can provide a harness; a platform can package one with hosting and administration. Ask what the system actually supplies and what your team must own.
| Term | Its role | What to ask |
|---|---|---|
| Model | Interprets inputs and generates responses or proposed actions. | Is its behaviour suitable for this task? |
| Framework | Provides reusable building blocks for developing agents and workflows. | What does it supply, and what must we implement? |
| Harness | Runs the configured task loop, tools, state and surrounding controls. | What actually happens when the agent takes action? |
| Platform | Provides a managed environment that may include models, harnesses, tools and administration. | Which responsibilities remain with our team? |
On smaller screens, scroll the table sideways to compare all three columns.
Start with the simplest structure that meets the task. Add orchestration when it solves a specific problem you can evaluate. See Anthropic’s discussion of agent patterns.
Where Canadian requirements fit
For responsibilities across the organisation, read our AI governance framework for Canadian organisations.
Applicability depends on the organisation, sector, data and decision involved. Engineering controls can support a legal or compliance review; installing a harness does not establish compliance.
PIPEDA and privacy principles
Where PIPEDA applies to an organisation’s handling of personal information.
Map purpose, data access, minimisation, retention and safeguards to the actual information flow. Keep logs proportionate; a full transcript can itself expose personal information.
Canadian privacy commissioners’ AI principlesQuebec private-sector privacy law
Section 12.1 concerns decisions based exclusively on automated processing of personal information.
Where it applies, support notice, access to relevant information and a route to staff review. Define who can review the decision and how that person can change it.
Quebec private-sector Act, section 12.1Ontario EDSTA, introduced through Bill 194
The legislation addresses specified public-sector entities. AI obligations depend on the applicable provisions and regulations.
Check the entity and use case first. Accountability records, risk reviews and human oversight can support that assessment; this is not a general private-business AI checklist.
Ontario’s enacted legislationOSFI Guideline E-23
The revised guideline applies to federally regulated financial institutions and takes effect on 1 May 2027.
Connect model inventories, ownership, independent review, change control and monitoring to the institution’s model-risk process. A harness supplies part of the evidence, not the whole program.
OSFI’s revised Model Risk Management guidelineReferences checked on 3 November 2026. Use the current legislation, guidance and applicable regulations when assessing an actual deployment.
Is your agent harness production-ready?
Use these 12 checks to structure a review. For each one, identify the evidence, its owner and any open issue. Ticking the boxes does not replace a release decision.
Download the checklist (.txt)Checks are temporary on this page. Nothing is submitted or saved.
Common questions about AI harnesses
What does human-in-the-loop mean in an AI harness?
A person reviews or approves work at a defined point in the workflow. Under the Ryzolv Harness Rules, software validates the AI’s proposal before a qualified, named person decides. An API key, machine account or AI agent cannot give that approval.
Is an AI harness the same as an agent framework?
The terms overlap. A framework provides development building blocks; a harness describes the configured environment that runs the agent’s work. A framework or SDK may supply much of that harness. Assess the actual behaviour and controls rather than relying on the label.
Do AI harness, agent harness and agentic harness mean different things?
People often use these terms for the surrounding software that runs model-led work. Agent harness and AI agent harness emphasise an agent’s task loop and tools. Terminology varies, so specify the responsibilities and interfaces when discussing a system.
Do we need a custom harness if we use Microsoft Copilot or another AI platform?
Start by assessing what your chosen product and configuration already provide. Review permitted data, actions, approvals, records and recovery. Custom engineering may be needed for gaps or cross-system workflows; adopting a managed product does not automatically mean building another harness.
Does every harness need RAG, memory and multiple agents?
No. A short, bounded task may need only instructions, one model call and a validated tool. Retrieval, persistent memory and specialist agents should address a specific requirement. Each added component creates behaviour that needs to be evaluated and maintained.
Who owns the harness: IT, security or the business?
Assign an accountable service owner. The business defines acceptable work and approvals; engineering owns implementation and operation; security and privacy teams review access and risk within their responsibilities. Agree escalation and change decisions before release.
Can a harness make an agent safe or compliant?
A harness can enforce controls and produce evidence, but it cannot remove every model, data or operational risk. Readiness depends on the use case, evaluation, operating process and applicable obligations. Security testing and compliance review remain scoped activities.