Field Notes
The last post was about giving AI the right room to work in.
Sources, examples, decisions, current state, people notes, workflows, stop signs.
That is the company brain in a form an agent can use.
But there is a deeper question underneath it:
How does the agent know where to go every turn?
That is where the harness starts.
If you have used Claude Code, you have probably seen the CLAUDE.md pattern. It tells the coding agent how to behave inside a repo: commands, conventions, tests, important files, and what the developer expects.
In OpenClaw, the same idea shows up in a different form.
There are identity files. Soul files. Memory files. Workspace instructions. Skill files. Tool rules. Delivery rules. Folder READMEs. Things that are true before the user message arrives.
Those files are easy to underestimate because they do not feel like the work.
They are the harness.
They decide what the agent wakes up inside.
The prompt is what you ask right now.
The context is what the agent needs to know right now.
The harness is the always-on environment that tells the agent who it is, what matters, where to look, what it can touch, what it must verify, and where it has to stop.
That is why harness engineering matters.
A better model helps.
A better prompt helps.
A cleaner context layer helps.
But if the harness is weak, the agent spends half its intelligence figuring out the room it is standing in.
If the harness is strong, the agent starts every turn with footing.
It knows the job.
It knows the boundaries.
It knows the source map.
It knows the difference between drafting an email and sending one, recommending a price change and changing the price, trusting memory and verifying it, asking for help and using the right tool first.
That is the difference between a chat window and an agent you can actually operate with.
Playbook
Here is the practical version.
If you want more from your agents, stop only asking, "What prompt should I use?"
Ask a better question:
What harness is this agent running inside?
1. Start with the agent lane
Every harness should match the lane.
A coding agent and a personal operations agent should not have the same harness.
A coding agent needs repo conventions, test commands, architecture notes, edit rules, review expectations, and a clear definition of "done."
A personal agent needs a different map: identity, tone, durable preferences, people context, calendar rules, inbox boundaries, memory policy, external communication rules, and approval gates.
The harness should point it toward the right notes, histories, tools, and operating protocols before it improvises.
Same model family. Different job. Different harness.
That is the first design decision.
2. Write the bootstrap files
The bootstrap files are the pieces the agent reads as part of its operating environment.
For a coding agent, that might be CLAUDE.md, AGENTS.md, repo READMEs, package scripts, testing docs, and architecture notes. For a personal agent, it might be identity, voice, memory, tool routing, approval boundaries, and project operating notes.
The important part is not the filename. It is that the agent has a durable place to load the rules of the world before the task starts.
The file should answer:
- Who is this agent?
- Who is it helping?
- What work is it responsible for?
- What sources should it check first?
- What actions are allowed?
- What actions require approval?
- What does "good work" look like?
- What happens when information is missing?
The point is not to make the bootstrap file beautiful. The point is to stop making the model re-learn your world every time.
3. Build the context routes
Context engineering lives inside the harness.
The harness tells the agent where to look.
Context engineering makes sure the places it looks are complete, accurate, and current.
If a coding agent needs to understand auth, the harness should tell it where the auth flow lives, how to inspect callers, and what files define policy.
If a personal agent needs to brief you before a call, the harness should route it to the calendar, inbox, people file, meeting notes, CRM state, and project docs.
If a content agent needs to draft a post, the harness should route it through the content desk, canon, voice files, prior posts, banned patterns, and review workflow.
Bad context routing creates expensive confidence. The agent sounds sure because it found something. The harness should make it find the right thing.
4. Define the prompt behavior at the destination
Prompt engineering still matters.
It just belongs in the right layer.
Once the harness routes the agent to the right context, the prompt controls what happens there.
Summarize this. Compare these. Draft this. Review this for risk. Find the source of this bug. Prepare the email, but do not send it.
Those instructions are powerful when the harness already knows the rules of the lane.
Without the harness, prompt engineering becomes a pile of reminders. With the harness, the prompt can stay focused on the job.
5. Match tools and permissions to the work
Tool access is part of the harness. So are tool limits.
A coding agent may need terminal access, search, tests, GitHub, browser docs, and a way to inspect impact before edits.
It should not need your personal inbox.
A personal operations agent may need calendar read access, inbox search, note retrieval, and draft creation.
It should not send external messages unless that action is inside the approved lane.
A pricing agent may need market data, booking data, and recommendation output.
Actual price changes may still need a human gate.
People get sloppy at the tool layer. They either give the agent no tools and wonder why it only writes words, or they give it everything and hope judgment appears on command.
The harness should give the agent enough reach to finish the workflow and enough boundaries to keep the work governed.
This is why agent-ready tools matter. An API, CLI, webhook, export, browser surface, or MCP server is part of the harness path between intention and completed work.
6. Give memory source priority
Memory needs a job. It should remember durable facts, preferences, decisions, repeated corrections, and project state, not stale guesses.
The harness has to define source priority.
Fresh file beats memory. Canonical note beats old conversation. API readback beats remembered state. Conflict means stop and surface the conflict.
Memory feels like knowledge from the inside. That is useful and dangerous. The harness keeps memory in its lane.
7. Require review gates and receipts
Receipts are what make agent work auditable.
If the agent read a source, name it. If it changed a file, give the path. If it ran a test, report the result. If it sent a message, verify the send. If it could not verify a claim, say that before the claim turns into a plan.
This changes the trust question.
You stop asking whether the model sounds smart.
You ask whether the work can be audited.
That is the standard that lets agents touch real operations. Anthropic's agent-building guidance makes the same point in developer language: simple, composable patterns usually beat ornate frameworks. Harness engineering is how operators make those patterns durable.
Not every action needs the same gate. Some work can run end to end. Some work should stop at a draft, a recommendation, or the second the agent sees a conflict.
The harness decides that before the task starts.
Orientation
Your agent is only as good as its harness.
That is the cleanest way I can say it.
The prompt is the instruction in the moment.
The context is the material the agent works from.
The harness is the operating environment that makes both of those useful every turn.
Good harness engineering stacks the layers.
It tells the agent who it is, where to route, which context routes are complete, how prompts should behave, which tools fit the job, where memory belongs, what requires approval, and what proof is required.
That is how you get more out of the agents you are already using.
Not by treating every agent surface the same. By engineering the environment around each one for the work it is supposed to do.
A Claude Code harness should make the agent a better builder inside a repo.
An OpenClaw personal-agent harness should make the agent a better operator inside your life and business.
A research harness should make the agent better at finding and checking sources.
A pricing harness should make the agent better at seeing revenue signals without crossing into unauthorized changes.
Same intelligence. Different operating environment. Different outcome.
If you want to improve your AI system this week, open the bootstrap file.
Look at the thing the agent reads before the task.
Ask whether it knows the lane, the sources, the tools, the boundaries, the review gates, and the proof standard.
If the answer is fuzzy, the agent will be fuzzy.
If the answer is clear, the agent has a place to stand.
That is where real agent work begins.
— Brian