Most of an AI agent is not the model. The model proposes the next step. Everything around it decides what the agent can see, which tools it can call, what it may change, when it must stop, what gets recorded and who accepts the result. That surrounding system is the agent harness.
Two teams can use the same model and end up with very different agents. One can read a support queue and draft replies for a person to review. The other can send email and change customer records on its own. The difference is not intelligence. It is the harness.
This framework sets out the nine layers of a harness, the minimum control each layer needs and the failure it prevents. It brings together what we have published separately on permissions, security, approvals, production context and evaluation, and shows where each piece sits in the whole. Where one of the four automations IZZY runs for clients illustrates a layer, we use it. Where none does, we say so.
Answer in 60 seconds
- An agent harness is everything around the model: task contract, context, tools, authority, run loop, state, hand-offs, verification and observation.
- Design it layer by layer. Each layer answers one question and needs at least one control the agent cannot switch off.
- Authority is granted, never inferred from a goal, a document or another agent’s message.
- Keep the record of what was proposed, attempted and confirmed outside the model.
- The agent may check its own work. It may not accept it: acceptance uses criteria set before the work and checks the agent cannot weaken.
- Size the harness to the consequence. A draft for review needs far less than an action that moves money.
- Re-check the harness when the model, a tool, a data source or the kind of work changes.
In this article
- The model is not the agent
- Layers that decide what the agent may do
- Layers that keep the run under control
- Layers that prove the work
- Ten rules that hold across every layer
- Size the harness to the work
1. The model is not the agent
An agent is software that chooses steps and uses tools to pursue a task. The model supplies the choices. The harness supplies everything that makes those choices safe to act on.
1 task contract what result, for whom, judged how
2 context what the agent may see
3 tools what it can call, and where the limit is enforced
4 authority what it may change, and with whose approval
┌──────────────────────┐
│ model │ proposes the next step
└──────────────────────┘
5 run loop budgets, stop conditions, interruption
6 state and record what was proposed, attempted and confirmed
7 hand-offs what passes between steps or agents
8 verification who accepts the result, against what
9 observation what is learned, and what changes| Layer | Question it answers | Minimum control | Go deeper |
|---|---|---|---|
| Task contract | What result, for whom, judged how? | Acceptance criteria written before the run | First AI project |
| Context | What may the agent see, and what is each input? | Untrusted material kept apart from instructions | Production context |
| Tools | What can it call, and where is the limit enforced? | Consequential limits enforced outside the model | MCP, skills or CLI |
| Authority | What may it change, in which mode? | Approval bound to the exact action and parameters | Agent permissions |
| Run loop | How long, how far, how expensive? | Budgets and a stop switch the agent does not control | Agent security |
| State and record | What happened, and what is still uncertain? | A record held by the workflow, not the model | Duplicate-free n8n tasks |
| Hand-offs | What passes between steps or agents? | Permissions never grow through a hand-off | Pre-screening workflow |
| Verification | Is the result fit to accept? | Acceptance checks the agent cannot waive | Evaluating a company brain |
| Observation | What do we learn, and what changes? | Every incident ends in a recorded decision | Pilot to production |
Orchestration is a different question. It decides how steps and agents connect: a fixed chain, a router, parallel checks. The harness decides what surrounds each of them.
The same layers apply to a fixed workflow with model steps. Removing autonomy removes some risks; it does not remove the need for authority, state and checks. None of IZZY’s four production automations is a free-roaming agent. They are workflows in which models read, extract, compare and draft. They still show each layer working, which is why we use them below.
2. Layers that decide what the agent may do
Layer 1: the task contract
State the intended result, the accountable owner, the actions in scope and how an acceptable result will be recognised, before the work starts. The detail should fit the task: one line for an internal summary, a full contract for an action that reaches customers.
Minimum control: acceptance criteria exist before the run. An authorised person may revise them explicitly as the task develops; nobody adjusts them silently to fit the output.
Failure it prevents: a confident result that answers a different question, judged by criteria reverse-engineered from that result.
In practice: in the weekly Search Console reporting workflow IZZY runs after a client’s site migration, the reporting brief sets the rules and the expected structure before any model drafts a line.
Go deeper: choosing a first AI project and the outcome contract in building a ChatGPT app that survives a real customer action.
Layer 2: context
Decide what the agent sees, and what kind of thing each input is.
Instructions arrive through an authorised control channel. Everything else - documents, emails, web pages, tool responses, another agent’s message - is material being processed. Material can decide which already-permitted action applies. It cannot create a new permission. A note added to memory does not change standing instructions or widen access.
Context is also a disclosure decision. Sending case data to a model provider discloses it to that provider, so data access and transmission belong in the authority decision. Information from one case or client is not reused for another because it happens to be available.
Minimum control: untrusted material kept apart from instructions, isolation between cases and clients, and an explicit decision on what may leave for each model service.
Failure it prevents: injected instructions, cross-client leakage and a context window full of evidence the agent should never have seen.
In practice: in IZZY’s startup pre-screening workflow, collection is not verification. The workflow keeps the source, date and context of each item rather than collapsing everything it gathered into a conclusion.
Go deeper: production context for AI coding agents, permission-aware company knowledge and the attack paths in AI agent security.
Layer 3: tools and the enforcement boundary
Define the capability surface: which tools exist, what each can read or change, and where its limit is enforced.
Permission to read does not imply permission to write. Permission to draft does not imply permission to send. Separate read tools from write tools, give each a narrow purpose and stable identifiers, and return explicit error states instead of leaving the model to improvise around a failure.
The decisive question is where the boundary lives. A rule in a prompt or a skill is a request the model can misread. A permission check in the server, a proxy or the downstream system is a control. Where exceeding a limit could cause material harm, put the control where the model cannot ignore it.
Minimum control: every consequential limit enforced outside the model.
Failure it prevents: a “read-only” agent that can write, because only the prompt said otherwise.
Go deeper: MCP, skills or CLI: put the safety boundary where the model cannot ignore it and the tool-contract register in building a ChatGPT app.
Layer 4: authority
Decide what the agent may change, in which mode and with whose approval.
Authority is granted, not inferred. A useful goal, a request inside a document or another agent’s message grants nothing. The agent cannot widen its own permissions or change the controls that judge its work.
| Mode | The agent’s role | The control |
|---|---|---|
| Blocked | Does not perform the action | Access or execution is prevented |
| Propose | Produces a proposal | An authorised person or system decides and carries it out |
| Prepare and wait | Prepares the exact action | Approval is required before execution |
| Act with full review | Executes within defined bounds | Checks run before execution; every outcome is reviewed afterwards |
| Act with selective review | Executes within defined bounds | Checks run before execution; quality is reviewed through sampled and triggered cases |
These modes describe a policy. They are not a ladder every action must climb, and some actions should never leave the first rows.
Approval binds to an identifiable action and its parameters: the recipient, the amount, the record, the text. If any of them changes, the approval is reconsidered. Executing a previously approved action is also not the same as accepting its result; that is layer 8.
Choose the mode by consequence: who could be harmed, how widely an error could repeat and whether its effect can be reversed. Review after the fact cannot undo an irreversible effect, so those actions need a control before execution or stay with a person. Cost is a reason to choose between adequate safeguards, not a reason to drop a required one. If no adequate control is affordable, narrow the scope or do not delegate the action.
In practice: IZZY’s content publication framework runs in two modes. In proposal mode, the user accepts or corrects how the system understood, structured and enriched the article. In execution mode, the accepted transformations, final package and publication run automatically. The approval unit is the editorial decision, not every image resize.
Go deeper: managing AI agent permissions and when company AI should answer, draft, request approval or execute.
3. Layers that keep the run under control
Layer 5: the run loop
Bound the run: steps, retries, elapsed time, cost and the number of records it may touch. Define the stop conditions before the first run.
When required information or safeguards are missing, the agent does not guess its way through. The policy says whether it pauses, takes a permitted fallback or refers the case to a person.
An interruption should leave a known state: what completed, what is pending and what is uncertain. Where an abrupt stop could itself cause harm, define a safe transition. The means to restrict or withdraw authority must not depend on the agent agreeing to stop.
Minimum control: budgets and a stop switch that sit outside the agent.
Failure it prevents: runaway loops, cost cascades and an agent that “completes” a task by inventing what it lacked.
In practice: when a required element is missing from an article, IZZY’s publication framework fails validation. It does not fill the gap with something plausible.
Go deeper: cascades and runaway loops in AI agent security.
Layer 6: state and record
Keep the case outside the model: inputs, findings, decisions, approvals and effects.
Every action has three states: proposed, attempted and confirmed. A timeout after a write request is not a failure. It is an unknown outcome. Check the target system before retrying, use a unique reference and its duplicate protection, and stop for review if the effect stays uncertain.
The agent’s account of what it did is recorded as a statement. It cannot rewrite the evidence used to judge it. Its explanation of why it acted is a lead for checking, not proof of the cause: research has shown that model explanations can misrepresent the real reasons for an answer.
Record enough to reconstruct events and no more. Minimise sensitive material, keep secrets out and set access and retention for the use.
Minimum control: a protected record held by the workflow, not the model.
Failure it prevents: duplicate actions after a retry, “done” claims with no confirmed effect and an audit trail the agent has edited.
In practice: in the acquisition funnel IZZY built with Notion and n8n, every action depends on one usable state. Notion is the operational view, n8n moves events and applies the rules, payment confirms the commercial state, and a person corrects that state when a refund requires it.
Go deeper: meeting notes to tasks with n8n without duplicate tickets and the failure-case matrix in building a ChatGPT app.
Layer 7: hand-offs
Govern what passes between steps or agents.
Permissions do not grow through a hand-off. The sender needs authority to delegate the work; the receiver acts within its own authority. Record the source and status of each hand-off, apply the required checks at each boundary and judge the combined result. Accepting each step does not prove that the whole task achieved its purpose.
Start with one agent. Split the work only when parts need different access, or one set of instructions becomes too complex to follow reliably. A different job title is not a reason for another agent.
Minimum control: each receiver works within its own permissions, whatever the sender could do.
Failure it prevents: authority laundering, where a low-privilege step asks a high-privilege step to act on its behalf.
In practice: in the pre-screening workflow, different models handle source collection, document extraction, structuring and evaluation, and pass structured work from one stage to the next. They do not vote. The asset is the interface between stages: what each receives, what it must return and which evidence must survive.
4. Layers that prove the work
Layer 8: verification and acceptance
Decide whether the result can be accepted. Ask four different questions:
| Question | What is examined |
|---|---|
| Fit for purpose | Does it answer the actual task and suit its intended use? |
| Correctness and support | Do claims, values and effects match adequate sources or measurements? Is uncertainty visible? |
| Coverage | Are required items accounted for, including exceptions and unfinished work? |
| Constraints | Does the work respect the permissions and requirements set for this use? |
Self-checking is allowed and useful. Acceptance is different. It rests on checks the agent cannot waive or weaken, using evidence or a method beyond its own assurance. A test the agent wrote does not become independent because it passes. Look for shared errors too, such as a wrong specification used by both the producer and the reviewer.
Separate two kinds of check. Checks before execution or use decide whether an action or output may proceed: authority, format, limits, recipients, data sensitivity. Checks of the result establish what happened and whether it worked: confirmed effects, source comparison, measurement, human evaluation. Sampling can suit the second kind. It never replaces a check that has to happen before harm.
Uncertainty has to survive the check. In the pre-screening workflow, each question is answered yes, no or possible. “Possible” means the dossier does not yet justify a binary conclusion, and it routes the question to further evidence or a person.
Minimum control: acceptance criteria and acceptance checks controlled outside the producing agent.
Failure it prevents: work accepted because it looks finished and the agent said it was.
In practice: IZZY’s Search Console reports are produced automatically; their delivery is not. An SEO specialist reads, simplifies and approves every report before it reaches the client, which in most cases takes 15 to 25 minutes.
Go deeper: testing a company brain for freshness, retrieval, failures and business value.
Layer 9: observation and change
Turn what happens into decisions.
Review errors, exceptions, blocked attempts and unresolved outcomes, not only successes, at a frequency that matches the consequence. Each incident ends in a recorded disposition: change a control, repair the work, address an external cause or explain why the existing response was enough. An unnecessary refusal is a failure too. Judge it separately from a justified stop, and do not judge the agent by completed tasks or one aggregate error rate.
Reassess the harness when a model, tool, instruction, data source or kind of work changes in a way that could affect what the agent does. Success with one action does not justify granting a different permission.
Minimum control: a named owner who reviews outcomes and can change controls, scope or autonomy.
Failure it prevents: a harness that was right at launch and quietly wrong six months later.
In practice: the first weakness found in the Search Console reports was not a false signal. Some versions said too much, too densely. That feedback changed the quality question: the reports had to prioritise and compress, not only detect change.
Go deeper: the AI pilot-to-production checklist.
5. Ten rules that hold across every layer
The layers say where to build. These rules say what must stay true in every one of them.
- Define the delegation before the work: the result, the owner, the allowed actions and how success will be recognised. (Layer 1)
- Authority is granted, not inferred. No goal, document or message expands it, and the agent cannot change its own controls. (Layers 2-4)
- Match freedom to consequence: harm, reach, reversibility, uncertainty and scale, including the cost of not acting. (Layer 4)
- Handle limits explicitly. Pause, fall back or refer; never invent permission or guess through missing information. (Layer 5)
- Make actions traceable as proposed, attempted or confirmed, with who acted, under which authority and on what. (Layer 6)
- Protect the record from the agent it is used to judge. (Layer 6)
- Turn observations into decisions, including mistaken refusals. (Layer 9)
- Judge purpose, evidence and coverage, not appearance or a statement of completion. (Layer 8)
- Separate self-checking from acceptance. (Layer 8)
- Preserve all of this through hand-offs and change. (Layers 7 and 9)
Each rule is a principle. A particular use turns it into a policy and a mechanism:
| Kind | What it describes | Example |
|---|---|---|
| Principle | The property sought in every use | The agent cannot enlarge its own authority |
| Policy | The choice for this use | It may prepare a supplier email but needs approval to send it |
| Mechanism | How that choice is enforced | A separate service checks permission and binds the approval to the recipient and text |
A written instruction expresses a policy. It does not enforce it.
6. Size the harness to the work
Not every agent needs every control at full strength. Start from the consequence of the action, not from the sophistication of the model.
| What the agent does | Harness minimum |
|---|---|
| Reads and drafts for a person to use (summaries, research, internal answers) | Context isolation, cited sources, human use as the acceptance step |
| Prepares actions others execute (a supplier email, a CRM update, an invoice query) | Prepare-and-wait mode, approval bound to the parameters, a case record |
| Executes changes to money, access, customers or production | Limits enforced outside the model, budgets, duplicate protection, checks before execution, independent acceptance, a stop switch and a tested rollback |
The layers read differently by field:
- Software development: which changes are permitted, which tests the agent did not write establish correctness, and who authorises effects on users or live systems.
- Content: what supports each claim, what makes the content useful and which permissions govern publication.
- Office processes: how cases are reconciled, how exceptions are handled and who authorises external commitments.
Regulated work - legal, medical or anything acting on physical systems - needs its own assessment of duties, competence and safe operating limits. This framework does not establish any of them.
Finally, the lightest harness is often the right one. If deterministic automation can do the job reliably, it is easier to test, explain and maintain than an agent. Choosing it is a harness decision too.
Conclusion: build the harness, then choose the model
Models will keep changing. The questions the harness answers will not: what the agent may see, what it may do, how the run is bounded, what is recorded and who accepts the result.
Design those nine layers deliberately, put each consequential limit where the model cannot ignore it, and let evidence, not a demo, decide when the agent earns more autonomy.
Review one agent’s harness with IZZY
Bring one agent or AI workflow, the tools it touches, what it may change and one recent failure or near miss. We will map it against the nine layers and show which controls are missing, which live in a prompt instead of the system, and what to fix before giving it more autonomy.
Designing and operating that harness is the scope of our AI Agents & LLM Products service.
Frequently asked questions
Everything around the model that turns it into a working agent: the task contract, the context it receives, the tools it can call, the authority it holds, the limits on its run, the record of what it did, the hand-offs it makes, the checks that accept its work and the review that changes the system over time.
No. Orchestration decides how steps and agents connect: a chain, a router, parallel checks or a manager agent. The harness decides what surrounds each of them. A well-orchestrated workflow can still have a weak harness.
Yes, in proportion. Removing the model removes some model-specific risks, but a workflow still needs authority, state, checks and an owner. IZZY’s four production automations are fixed workflows with model steps, and each layer still applies.
The task contract and authority. If the agent will write to any system, build the state and record layer before the first live run.
Sources and limits
- IZZY examples come from the published descriptions of four automations IZZY runs for clients: an acquisition funnel, a startup pre-screening workflow, a content publication framework and post-migration Search Console reporting. They are workflows with model steps, not autonomous agents, and no new measurement was made for this article.
- Saltzer and Schroeder, 1975: least privilege, denying access unless it is permitted, and complete mediation of access.
- OpenAI, Practices for Governing Agentic AI Systems, 2023: proposed practices for limiting, observing and keeping control of agentic systems.
- Google, An Introduction to Google’s Approach for Secure AI Agents, 2025: human controllers, limited powers, observable activity and layered defences.
- Turpin et al., 2023: chain-of-thought explanations can misrepresent the reasons behind a model’s answer.
- Microsoft, taxonomy of failure modes in AI agents, 2025: agent-specific threats and possible mitigations.
The nine layers and ten rules are IZZY’s synthesis. These sources support individual starting points, not the effectiveness or completeness of the framework. It makes no claim about universal error rates and does not establish legal permission, professional competence or safety certification; existing obligations must be checked for each deployment. Sources checked on 5 October 2026.