How to Design an Agent Harness
An agent harness is everything around the model that makes it an agent — the prompt, the guardrails, the memory, the tools and the loop. This guide shows you how to design one deliberately and security-first: name the components, scope the tools, choose the control loop, and keep the whole thing governable even when it can improve itself.
In plain words
Designing an agent harness means building the scaffolding around a fixed model — system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins, plus the control loop — so the model behaves like a reliable, bounded agent. PlayCISO has a free, browser-based harness designer that lays out these eight components with security defaults so you can sketch yours.
The hard part is not getting it to work; it is keeping it governable. Scope every tool with a typed, non-self-expandable contract, give memory provenance and a time-to-live, run executors behind an egress allow-list, and put a human gate on any privileged self-edit — then wire a kill switch before you ever let the harness improve itself.
Step by step
- 1
Name the eight harness components
An agent harness is everything around a fixed model that turns it into an agent. Harness² (Google Cloud AI Research and Northwestern University, arXiv 2610.14224) decomposes it into eight components: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins. Before you tune anything, write down what each one is for in your system — most teams conflate "tools" with "tool guidance," or ship a system prompt that is quietly doing the job of guardrails. A clear inventory is what makes the rest of the design reviewable.
- 2
Write a tight system prompt and explicit guardrails
The system prompt sets role, objective and style; the guardrails set the hard limits — what the agent must never do, what needs confirmation, and how it refuses. Keep them separate on purpose. A guardrail buried in a paragraph of persona text is easy to override with a crafted user message; a guardrail stated as a standalone, testable rule is not. Phrase limits as behaviours you can check ("never run a destructive command without explicit human approval"), and assume any untrusted text the agent reads will try to talk it out of them.
- 3
Choose a memory design with provenance and TTL
Memory is what lets an agent carry context across steps and sessions, and it is also the easiest thing to poison. Decide what gets remembered, for how long, and where each memory came from. Tag every stored item with its source and a time-to-live, and treat anything that originated from a tool result or an untrusted document as data, never as instructions. A lesson the agent "learned" from a web page it scraped should expire and should never silently rewrite a guardrail. Provenance plus TTL is what lets you trust — and roll back — what the agent thinks it knows.
- 4
Scope tools with typed, non-self-expandable contracts
Each tool the agent can call should have a typed contract: declared inputs, declared outputs, and a declared blast radius. Tool guidance tells the model when and how to use each one; least privilege decides what it is allowed to reach at all. The critical rule is non-self-expandability — the agent must not be able to grant itself new tools, widen a scope, or edit its own tool guidance without a human in the loop. A harness that can rewrite what it is permitted to do is a harness with no permissions at all.
- 5
Decide the control loop and add a verifier gate
The control loop is how the agent decides, acts and checks. A simple ReAct loop (reason, act, observe, repeat) is fine for bounded tasks. Harness² uses a recursive Propose–Probe–Compose loop: propose changes, probe their effect on the same task, then compose a refined result from the contrast. Whichever you pick, put a verifier or critic gate between "the agent produced output" and "the output takes effect" — a separate check that the result is correct and in-policy before it ships. The loop is also where runaway cost and tool-call storms happen, so bound the iterations.
- 6
Set routing and an egress allow-list
Routing decides which model, which subagent and which tool handles a given step; the egress policy decides what the whole system is allowed to talk to. Default the network to deny and allow-list only the hosts the agent genuinely needs. The Harness² paper is candid that its own executors run with unrestricted network access and one executor with its sandbox disabled — fine for a research benchmark, not for production. Run executors sandboxed, behind an egress allow-list, so a prompt-injected agent cannot exfiltrate data or reach an attacker-controlled endpoint even if it is fully convinced it should.
- 7
Put a human gate on privileged self-edits and wire a kill switch
The point of a self-improving harness is that it can rewrite its own scaffolding — including guardrails, tool guidance, scripts and plugins. That power needs change control. Require human approval for any edit to a privileged component, keep provenance and rollback for every adopted harness and lesson, and give the whole system a kill switch that halts the loop and revokes credentials in one action. Design the kill switch before you need it; an agent you cannot stop and reset cleanly is not one you can safely let improve itself.
Sketch all eight components and the control loop in your browser, with security defaults — least privilege, provenance, egress allow-list and a human gate — baked into the template.
Related
The interactive tool this guide walks you through — lay out the eight components and the loop.
Harness comparatorCompare harness designs side by side — components, loop style and governance surface.
Agent topology visualizerMap how model, subagents, tools and memory connect, and where trust boundaries sit.
Harness² governance deep-diveWhat a self-editing harness means for security leaders, and how to govern it.
Frequently asked questions
What is an agent harness?
An agent harness is all the scaffolding around a model that turns it into a working agent — the system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins, plus the control loop that drives them. The model's weights stay fixed; the harness is the part you design, tune and govern. When people say an agent "got better" without retraining, it is usually the harness that improved.
What are the eight components of a Harness² harness?
Harness² (Google Cloud AI Research and Northwestern University, arXiv 2610.14224) describes the harness as eight components: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins. The framework rewrites this scaffolding around a fixed model through a Propose–Probe–Compose loop and carries evidence-backed lessons forward to future tasks. The point of naming the eight is that each is a surface you can design and review independently.
How do I build an agent harness?
Start by inventorying the eight components for your use case, then design each: a tight system prompt, explicit testable guardrails, a memory scheme with provenance and TTL, typed non-self-expandable tool contracts, a control loop with a verifier gate, routing, and an egress allow-list. Finish with the governance layer — a human gate on privileged self-edits and a kill switch. Build security in from the first component rather than bolting it on; a harness is only as trustworthy as its weakest scaffold.
What is the difference between ReAct and Propose–Probe–Compose?
ReAct is a straightforward loop — the agent reasons, takes an action, observes the result, and repeats until the task is done. Propose–Probe–Compose, used by Harness², is a recursive optimisation loop: it proposes changes to the harness, probes their effect on the same task (the probe needs no ground-truth answer), and composes a refined harness from the contrast. ReAct improves a single run; Propose–Probe–Compose improves the scaffolding itself across runs, which is more powerful and carries a much larger governance surface.
What are the main security risks of a self-improving harness?
The core risk is that a harness able to edit its own guardrails, tool guidance, scripts and plugins can change what the agent is allowed to do with no human in the loop. The Harness² paper notes its executors ran with unrestricted network access and one with its sandbox disabled — acceptable for a benchmark, dangerous in production. Mitigations: non-self-expandable least privilege, human-gated change control for privileged edits, provenance and rollback for adopted harnesses and lessons, sandboxed executors behind an egress allow-list, and a kill switch.
Do I need a self-improving harness, or is a fixed one enough?
Most production agents do fine with a well-designed fixed harness — a clear prompt, hard guardrails, scoped tools and a bounded loop. Self-improvement earns its complexity when you face a stream of varied tasks the harness was never tuned for and you can afford the optimisation cost and the governance overhead. It is new and experimental; treat the recursive, self-editing variants as something you pilot behind strong controls, not a default. A fixed harness you fully understand usually beats an adaptive one you cannot stop.