BoteamThe agent harness in one page: rules, memory, tools
By Bob · 2026-08-18 · 3 min read
A solo founder's cliff notes on the agent harness, the four controls that decide whether your agent is a reliable teammate or a liability.
Most agents die for lack of grip, not lack of model. You can swap the model and the agent still misbehaves the same way — it deletes a folder you did not say to keep, it calls a tool you thought it could not reach, it takes an action you only found out about in the logs. The model is not the problem. The harness is.
A harness is the set of controls around the agent: what it is allowed to touch, what it remembers, what it can do with tools, and what it records. Four controls. If you set them on purpose, a boring agent that does one job well beats a fashionable agent you do not understand.
This is the one-page version — enough to ship, not a framework essay.
Control 1 · Rules — what the agent is allowed to do
Write down, in plain sentences, the boundaries. Not a philosophy — a short list the agent can actually follow.
- What action is it allowed to take without asking? (read, draft)
- What action requires confirmation? (send, delete, spend, publish)
- What is explicitly off-limits, even if it seems efficient? (delete project files, change pricing, contact customers)
- One "stop" rule: the condition under which the agent must halt and hand back to you.
The failure mode is not that the agent is dumb. It is that "you did not say I could not" is a terrible excuse after it has already acted. Write the rules so "I did not know" stops being possible.
Control 2 · Memory — what it remembers about you
The agent's memory is not your notes. It is a store it writes to and reads from, and it will act on that store as if it were truth.
- What does the agent persistently remember? (your goals, tone, product facts)
- What should it NOT persist? (raw customer input, private financials, anything you would not put in a shared doc)
- Who can read and edit that memory? (just you, or the agent too?)
- Can the user erase it? (there should always be a reset)
The rule of thumb: whatever the agent remembers is a lever it can pull. Decide what belongs on that pole before it learns to reach for it.
Control 3 · Tool permissions — what it can actually do
Tools are where an agent turns thought into action, and where most damage happens. Scope them like you would scope an employee's access.
- List every tool the agent can reach. Every one.
- For each: does it need write access, or read-only? (start read-only, add write only when proven)
- Are there tools the agent should never have on its own? (payments, deletes, sends)
- Is there a cap on spend or volume? (a daily limit on API calls, sends, or cost)
The discipline: grant the smallest permission that gets the job done, and treat write access as a promotion the agent has to earn with its read-only record first.
Control 4 · Observability — what it records so you can trust it
You cannot trust what you cannot see. The agent should log what it did, and you should be able to review it fast.
- Does the agent log every tool call — what, when, why?
- Can you see the reasoning behind an action, not just the result?
- Is there an alert when it crosses a rule or spends past a cap?
- Can you replay a problem in minutes instead of guessing?
The practical bar: if the agent does something wrong and you cannot tell why in five minutes, you do not have observability, you have hope.
The one-page checklist
Copy this before you ship any agent:
- Rules: boundaries written down, one "stop" rule defined
- Memory: what it persists is decided, sensitive data excluded, reset available
- Tools: every tool listed, read-only by default, write is earned, spend capped
- Observability: every action logged, reasoning visible, alerts on rule-crossing
Set these four and you have a teammate you can walk away from for an hour. Skip them and you have a liability that only misbehaves when it matters most.