the control surface is the product

if you watch where an experienced operator’s hands go during an agent session, the model isn’t where the work happens.

the work happens in the settings file. in a hook script that runs before the diff. in AGENTS.md deciding what the agent is allowed to know. in the mcp server list deciding what it can reach. in the local runtime deciding what bytes leave the machine. in the audit log deciding what counts as evidence afterwards.

the model writes the code. the harness decides whether the code ships, who saw what, and whether anyone can prove it later.

the model is the part you rent. the harness is the part you own.

that’s not a slogan. it’s how the bill of materials actually breaks down.

the rented layer is volatile

count what moved under your stack in the last week and the asymmetry shows up fast.

the claude code cli ships often enough that “which version is on your laptop” is a real question, not paperwork. model lines rotate. default behaviors shift. a release that quietly degrades your context budget can be installed before you notice.

the cli isn’t the only thing churning. mcp ships revisions. local runtimes — ollama, llama.cpp, mlx-lm, vllm, open webui, whisper.cpp — each ship on their own clock. tokenizers change. document extraction lands in a local cockpit and turns it from chat skin to document workbench.

memorizing version numbers isn’t the right reaction. notice instead that “the AI” isn’t one product — it’s a stack of about ten components, with version drift in every one.

if your strategy is “use the best model,” your strategy lasts a week. if your strategy is “own the harness,” it lasts as long as you maintain it.

what the harness actually is

the whole stack, top to bottom:

model
  ↓
harness    ← settings, hooks, mcp, workflow files
  ↓
custody    ← which bytes leave the machine
  ↓
audit      ← metadata-only record of what happened
  ↓
operator   ← you, deciding what counts as done

the model sits at the top because it’s the most replaceable. everything downstream is the part you build, edit, and pin.

unpack the harness row and it’s a small, ugly, very specific list of artifacts.

every row is a thing you can edit. every row is something the model can’t edit on your behalf. every row is the reason a vendor release isn’t your only control surface.

a starter harness, on disk

if all of that is abstract, here is the smallest concrete version. five files, one repo, no magic.

your-repo/
├── CLAUDE.md                ← standing instructions the agent reads first
├── .claude/
│   └── settings.json        ← permissions, hooks, allowed bash patterns
├── .mcp.json                ← which mcp servers the agent can talk to
├── hooks/
│   └── preflight.sh         ← runs before edits; tests, lint, source check
└── audit.jsonl              ← metadata-only record, append-only

five files don’t catch every failure. five files do force you to write down, in plain text, the answers to: what does the agent know, what can it touch, what runs before it commits, what reached out, and what got logged. for the deeper take on the workflow files specifically, see claude code workflow files .

permissions are the new ux

the claude code settings page is where “what is this agent” actually gets defined. the schema isn’t exciting; the leverage is.

three knobs do most of the work.

permissions. which tools the agent has, what file globs it can read or write, which bash patterns are auto-allowed, which require a prompt. a careful permissions block is the difference between “agent does the boring task while i lunch” and “agent rewrote half my repo and pushed.”

hooks. code that runs around tool calls. a pre-edit hook can re-read a coding standard. a post-tool-use hook can run tests, lint, or block a commit. a stop-hook can write a structured session summary. this is where verification the agent cannot fake actually lives — the hook is yours, runs on machine time, takes nothing on the model’s word (hooks docs ).

mcp servers. every server is a permission grant — file system, browser, email, calendar, database, custom internal tool — and every one expands the blast radius (mcp docs ). it’s also the audit boundary: every action through mcp is a thing you can log, gate, and replay. the value isn’t “more tools.” it’s “well-defined interface between the model and the things it shouldn’t break.”

if you only fix one thing this month, fix this file. half the agent failure stories i collect in agent failure modes come down to a default permission set the operator never reviewed. for a step-by-step pass before you run it, see claude code session preflight .

workflow files run the work

the second half of the harness is everything that lives in the repo as text.

AGENTS.md, CLAUDE.md, skills/, repo maps. they all do the same job: turn standing instructions into a file the next session reads automatically, instead of a prompt you re-type. the format comparison covers the differences. headline: more alike than vendor marketing pretends. the meaningful question isn’t which filename. it’s what’s inside.

a few rules from running this against real codebases for a year.

• the file runs the work. if a rule isn’t in AGENTS.md or a skill, it isn’t enforced — it’s a hope. agents forget across sessions; files don’t.
• prefer skills to chat for anything you do twice. skills are the new apps , and agents.md is infrastructure now . the durable artifact is markdown, not chat history.
• mcp is the network layer; skills are the policy layer. they answer different questions. mcp asks “can the agent talk to email at all?” skills ask “what is the agent allowed to do once it’s there?”
• stale instructions are worse than no instructions. an AGENTS.md that says “use library X” two years after you migrated off X will route the agent into a wall every time. files need maintenance like code does.

this isn’t a config-file aesthetic. it’s the only way an agent’s behavior becomes legible to a second human.

custody is a runtime decision

every prompt is a copy of something. every response is a copy too. when both copies leave your machine, you’ve made a custody decision, whether you noticed or not.

the local runtime stack — ollama , llama.cpp, mlx-lm, vllm, open webui, whisper.cpp — exists to give that decision back. the runtime comparison covers when to choose which. the point: a local runtime is not a hobbyist toy in 2026. it’s the thing standing between your draft journal entries and somebody else’s training set.

what to put on the local lane:

• voice memos and transcripts (voice capture pipeline is the worked example);
• documents you wouldn’t paste into a public chat (a local cockpit with a document extraction engine moves you from chat skin to document workbench — see open webui );
• iteration loops where you don’t want every keystroke to bill;
• anything covered by a regulator your vendor won’t fight for you.

what stays on the rented lane: public coding work, public research, tasks where you want frontier capability and don’t mind the bytes leaving. no purity test here. just a knob you should know you’re turning.

a field report from the trust layer

i’ve spent the past month on network.self.md — an encrypted peer-to-peer state layer for personal agents, with public discovery, a dashboard, a policy gate, operator controls, and a durable audit. good lab for what an owned harness looks like when you build it from scratch.

four things landed harder than i expected.

1. public is not the same as public-by-default. an agent can have a public self.md profile (so other agents can find it) and still keep every payload private. discovery only releases identity-level metadata: who you are, your public profile, your group’s headcount. it’s a posture, not a content release.

2. the policy gate has to be the chokepoint. every inbound action funnels through one place that says yes, no, or maybe-with-prompt. multiple bypasses means you don’t have a gate; you have suggestions. fail-closed defaults aren’t ux. they’re a safety property — unknown event shapes, invalid signatures, and unknown senders all reject with a structured reason instead of silently falling through.

3. audit must be metadata-only. “we log everything” is how you build the next data breach. the audit pins itself to columns that hold no plaintext, no payloads, no tool args, no keys — only enough to reconstruct what happened and when. the test that pins those columns matters more than most of the code around it.

4. operator controls are local-first and persist-then-publish. changing policy from the cli or mcp doesn’t emit network traffic; it writes a row, and in-memory state catches up. audit records persist before they’re published, so a retry can never poison the record. infrastructure trivia, until you realize it’s the difference between an audit log you trust and one you tell yourself you trust.

none of that is special to peer-to-peer agents. it’s what a serious harness looks like when the model is treated as a guest on hardware it doesn’t own.

what to own in your stack this week

a checklist, not a manifesto. each item is one to two hours.

1. pin your claude code version. record the version in the repo (a tools.md or your readme). don’t auto-upgrade silently.
2. read your settings file end to end. delete every permission, hook, and mcp entry you don’t actively use. unused entries are blast-radius without benefit.
3. inventory your mcp servers. for each one, write a one-line “what does this let the agent do?” if you can’t write the line in a sentence, the server doesn’t belong in the loop yet.
4. promote standing rules into files. anything you’ve typed into a chat twice this week goes into AGENTS.md, CLAUDE.md, or a skill. the file runs the work (format comparison , workflow files guide ).
5. decide what cannot leave the machine. pick one local runtime for that lane (ollama , llama.cpp, or mlx-lm depending on hardware). run a smoke test offline before you trust it.
6. add a verification step the agent can’t fake. a real test, a real diff check, a real source fetch. if “looks good” is your only check, you don’t have one. the agent verification loop walks through the checks one at a time.
7. log agent actions metadata-only. what tool, when, against what target, with what outcome. no payloads, no plaintext, no keys.
8. describe what “operating normally” looks like in one paragraph. if you can’t write it down, you can’t notice when it’s not normal.

eight items. none of them require a model upgrade. all of them survive a model swap.

why this is the product now

three years of “which model is best” trained an entire industry to point at the wrong layer.

the model is a commodity input now. swap a frontier model for a smaller one plus a skill and you don’t lose much on the right kinds of task. keep the model and swap the harness around it, and the work changes shape entirely.

the next twelve months of personal-ai infrastructure won’t be decided by which lab tops the leaderboard. they’ll be decided by:

• which control surfaces are simple enough to read in one sitting;
• which workflow files survive a year of edits without rotting;
• which custody choices age well with regulators;
• which audit surfaces are honest about what they don’t store;
• which dashboards make the operator trust the loop instead of just watching it.

a smarter model is a feature. a console pointed at you is a product . the harness around all of it is yours.

pick what you own carefully.