What an agent harness is — and why autonomy needs boundaries
A reliable agent is not made by one prompt. It is made by an environment that keeps its steps visible and stoppable.

An agent is more than a chat that sounds especially determined. It can organise information, use tools, check intermediate results and pursue a task across several steps. That very ability is what makes agents compelling — and what makes them fragile: where a chat only replies, an agent acts.
To keep this ability from becoming blind activity, it needs a frame. This frame is often called an agent harness: the rules, states, permissions and control points around the agent. It is the unremarkable infrastructure that decides whether an impressive tool becomes a reliable one.
A harness is not a prompt; it is a working frame
A good prompt explains a task. A harness governs how that task may be carried out. It defines which inputs the agent receives, which tools it may use, what it records and when it must stop. This turns an impressive one-off performance into a repeatable workflow.
That matters because an agent can choose its next step. Without a frame, this freedom can look convenient at first. In practice it makes outcomes harder to inspect: no one can tell which assumption led to which action, or where an error began.
The distinction sounds academic but is close to daily practice. A prompt can be rewritten in seconds; a harness outlives many prompts. It is the place where you decide once what should hold in general — and no longer repeat that decision with every new task.
Four parts make action traceable
First, an agent needs a clear brief with a recognisable end. Second, it needs state: what is already known, what has been done and what remains open? Third, it needs limited tools and permissions. Fourth, it needs events that trigger something: new information, missing evidence, an approval or a stop.
These are not only technical parts. They are a language for responsibility. Clear state prevents old assumptions from quietly continuing. Limited permissions prevent research from becoming an unintended change. Events ensure a critical moment does not vanish in the flow of work.
No single part is complicated on its own. Their strength lies in the interplay: a brief without an end runs on, state without permissions invites quiet solo runs, and permissions without events know no point at which they should end. Only together do the four turn an impressive tool into an accountable one.
Autonomy needs a boundary before action
The most important boundary is not at the end, after harm has happened. It is before an action with consequences. An agent may prepare drafts, compare options or flag missing information. Sending, publishing, purchasing, deleting or changing should require explicit approval.
This boundary does not weaken an agent. It makes it more useful in everyday work. People can decide where context, consequences or values matter. The agent remains fast in preparatory work without quietly taking on a role it was never given.
The dividing line follows reversibility. What can be undone effortlessly, the agent may do itself. What has an outward effect — a sent email, a deleted record, a published page — belongs behind approval. That single question, whether something can be taken back, replaces many special rules.
Observation and review belong in the design
A harness does not end with a list of allowed tools. It needs a trace: which inputs mattered, which tools were used, which assumption remained open, and why work was stopped or approved. The trace does not need every detail. It does need to explain the path to an action.
After a run, a brief review is worthwhile. Which rule was too strict? Which question came too late? Where was the agent useful, and where was it merely busy? Better boundaries emerge gradually — not through belief in perfect autonomy, but through a working environment that can learn from observation.
Say an agent is meant to pre-sort invoices in an inbox. Its brief ends when every mail is assigned to a category and every unclear case is flagged. Its state records which mails have already been checked. Its permissions cover reading and labelling — not deleting or replying. An event is an invoice without an amount: then it pauses and asks. The trace notes the sender, category and reason for each assignment. The agent removes real work, yet every action with effect stays with the person.
A small harness card
A single card holds the frame together. It fits on half a page and travels with the initiative — copy it to the start and fill it in before the agent begins.
# MY AGENT HARNESS
**Brief and end**
The agent should … and is finished when …
**State**
It may retain … Open questions are …
**Tools and permissions**
It may … It must not …
**Events and stops**
When … happens, it pauses and asks …
**Trace**
For every run, I record …An agent harness is not a brake on good automation. It is the form in which automation becomes reliable. When brief, state, permissions, stops and trace are designed consciously, autonomy remains useful: active enough to remove work, bounded enough to earn trust.
Worksheet: Plan a small harness
Choose a task an agent could prepare. Deliberately begin with a small action that can be reversed — and build the frame step by step.
Define the brief and end. Write what the agent should prepare. Define an end that can be recognised without interpretation.
Limit the state. List the information the agent genuinely needs. Mark the assumption it must not close by itself.
Divide permissions. Separate reading, drafting and changing. Which tools are allowed? Which action always needs approval?
Trigger a stop. Write at least two events at which the agent must pause and ask a question.
Set a trace. Choose four points that must remain understandable after every run.
All materials to download — the topic overview and the worksheet:
● Members only
Read the full article and download all files with a membership.
Unlock full article + downloads → Subscribe0 comments
No comments yet — be the first.