How I build · The harness
The one idea. The instructions an agent follows are configuration with a running cost. They get a budget, a size check and, where a miss is expensive, mechanical enforcement — the same treatment as any other production configuration.
Reading path. Entry from The harness, the case study. The incident that forced most of this is Agents on a budget; the gates the harness serves are on the next How I build page, The delivery method.
1 · What loads, and what it costs
A coding agent reads its project's instruction files at the start of every session, and every sub-agent it launches reads them again before its first action. They are not consulted on demand; they ride along on every call.
That would be cheap if a payload were billed once. It is not. Whatever enters the context is re-read on every later turn of the session, so its cost is roughly its size multiplied by the turns that remain:
Measured on 41 of one build's own agent working sessions (a sovereign OSINT platform built for a defence innovation challenge): one tool result was billed 133 times on average, 364 at peak. Three rules follow, and every other section of this page is one of them applied:
| Consequence | Rule |
|---|---|
| Size matters more than call count | A 60 KB ceiling on auto-loaded instructions per project; reference material lives in files read only when a task needs them |
| Timing matters as much as size | Cheap checks early in a session, large reads late |
| Isolation beats both | A large read whose answer is small goes to a sub-agent, and dies with it |
What it bought, measured. On the project where the overrun happened, first-call context fell from 256,372 to 59,730 tokens (−77 %) (Agents on a budget). On a second product, the auto-loaded payload fell from 135.4 KB to 59,099 bytes, inside the 60 KB budget (MyWarren).
2 · Prose versus hooks
A rule written in prose is obeyed until it is not. The tool's own permission patterns look like the mechanical answer, but they are prefix matches on the whole command. On the video project, 2,332 of 2,389 recorded shell calls began with a change-directory step, so a pattern written to catch a risky command almost never saw it: the risky token sat in the middle of the line.
Where an instruction sits decides whether it can be skipped:
The rung is chosen by what a miss would cost. Three hooks run on the quiz project, each one sentence:
| Hook | When it runs | What it does |
|---|---|---|
| Boundary | before every tool call | Denies any tool — file tools and shell commands — access to private folders; asks before a shell command that names the read-only source folder and looks like it writes. A file-tool deny rule alone does not cover a shell cat |
| Guard | before every shell call | Splits the command into segments and inspects each one, so cd x && <risky> is caught exactly as <risky> is. Denies piping a download into a shell and reading credential files; asks, rather than denies, before inline interpreter code |
| Payload size | at session start | Silent within budget. Warns when the auto-loaded instructions pass 60 KB, and warns if an auto-loaded rules folder exists at all, because everything in it is paid on every call of every session and sub-agent |
How the guard sees what a prefix pattern cannot:
Proved, not asserted. The same three hooks were copied into this site's own repository, where a decision test file feeds each hook a recorded tool call and checks the answer it gives: 20 cases, 20 passing (17 for the boundary hook, 3 for the guard). The tests prove each decision is the intended one; they do not count how often a hook fired in real work.
Trade-offs accepted. A hook asks the person more often than a rule would; that is the price of a check that cannot be skipped. And the guard asks on inline code instead of denying it, because a hard deny cannot be overridden even by the person mid-session, and writing a throwaway script is ordinary work. The guard was copied unchanged from the video project, where the incident happened.
3 · Agents with narrow scopes
One session that knows everything is the expensive way to review: it pays the whole context for every check, and it reviews its own work. The alternative is several narrow agents, each with a role, a tool list and a scope.
| Agent | Built for | Tools | Scope enforced by |
|---|---|---|---|
| Hiring-manager reader | Cold-start review of a resume against a job description: gaps, weak claims, what an interviewer would press on | Read only | the tool list: it is given exactly two files and cannot write |
| Recruiter screen | Cold-start six-second screen: does the page say what the role is, in its first third | Read only | the tool list, as above |
| Spec drafter (OSINT build) | Drafts phase specs | an allow-list per agent | the allow-list; its write scope is stated in prose |
| Test lead (OSINT build) | Testability review of specs and test plans | as above | as above |
| Code reviewer (OSINT build) | Code review on each implementation; writes findings, never the fix | as above | as above |
| End-user subject-matter expert (OSINT build) | Product-fitment review from the analyst's seat | as above | as above |
Stated honestly. The four OSINT-build agents had tool allow-lists but no deny-lists: each one's write scope — one folder, one file, or a log only — was written in its instructions, not enforced. The later projects moved scope into mechanism: the two cold-start readers get one tool, Read, and the quiz project's boundary hook covers what a tool list cannot. That is the ladder in §2, climbed one rung at a time, and The harness §4 tells it in that order.
4 · Skills as repeatable pipelines
A process that has to run identically every time is written once as a skill — a packaged set of instructions the agent loads only when the task calls for it — instead of being re-explained in each session.
| Skill | The pipeline | What it enforces |
|---|---|---|
| Resume pipeline | Read the current version → write the next version with a change log → run an ATS check → build the Word file | A document is never overwritten; every version is kept, and the fixed headline and tenure figures are checked by script |
| Application writing | Draft a cover letter, outreach message or follow-up from the project's evidence | No person named except a recipient in a salutation; every company fact verified; no compensation language |
Because a skill loads on demand, it costs nothing on the calls that do not need it — the §1 rule applied to process.
5 · Memory that refuses lossy writes
The model starts every session cold, and compaction loses whatever reasoning lived only in the transcript. So state lives in a progress log the next session reads first. The log is capped at ten session blocks to keep that first read small; older blocks move, verbatim, to an archive that is searched and never read whole.
Moving blocks is the risky step, so the script that does it refuses to write unless the move is provably lossless:
Result: every session's state carried across context resets, with nothing summarised and nothing deleted.
Measured figures on this page
| Figure | Source |
|---|---|
| Context-cost amplification 133× mean, 364× peak per tool result, across 41 agent working sessions | the OSINT build's agent cost profiling |
| 60 KB auto-loaded instruction budget per project | the rule itself; enforced by the payload-size hook |
| 2,332 of 2,389 shell calls began with a change-directory step | the guard hook's header, measured on the video project |
| Hook decision tests 20 of 20 passing (17 boundary, 3 guard) | this site's repository, run 2026-10-18 |
| First-call context 256,372 → 59,730 tokens, −77 % | Agents on a budget |
| Auto-loaded payload, second product, 135.4 KB → 59,099 B | MyWarren |
What this page does not claim
- No hook catch rate. The hooks do not log their decisions, so how often each one fired in real work is not known. The 20 tests prove what each hook decides, not how often it decided it.
- No control. Nothing here proves the harness caused a build's throughput; it shows what each mechanism does and what was measured before and after it.
- Not every project has hooks. Hooks live where an incident happened; elsewhere the 60 KB rule is prose in the user-level configuration.
- The 133× figure is one build's measurement. No measurement pass has been run on the other projects; the mechanism is general, the number is not.
- No code is published. The hooks and the roll-off script are described here, not reproduced.