The harness
I run my own AI operations the way I run a security operations centre: a routing layer in front, a memory system behind, authorization that is enforced rather than advised, and a structured record of what happened. This page is that architecture, drawn.
It is here for the same reason How This Was Built is here. An advisor who recommends AI-assisted operations ought to be able to show you one they actually operate — including the parts that constrain it.
How to read the drawing
The band is the harness. Eight segments, each a mechanism whose only job is to spend as few tokens as possible and reuse as much as possible. A prompt enters at the top left, travels down the left arm, across the bottom, and leaves at the top right.
The block inside the band is the model layer — four rungs and a cross-vendor route.
Four layers, and it is worth keeping them apart. Orchestration decides how a prompt is handled. State decides what the system knows when it starts. Controls decide what it is permitted to do. Evidence records what it did. The band below is the first two; the controls and the evidence are listed further down, and they are the half a security reader cares about.
The horseshoe is open at the top because that is where the model is swapped out. Models change every few months; the harness is designed not to. That gap is the whole argument. The loop closes through memory and policy rather than through the model, which is why a correction made once outlives the model that received it.
Fig. 1 — the reuse loop, its eight stations, and the model layer it wraps.
The eight stations
Reading the band from the left tip, around the bottom, to the right tip. Each is a file in the system, not a concept.
| # | Station | What it does |
|---|---|---|
| 1 | Classify first | Every prompt is triaged before anything is spent on it. Deterministic fast-paths cost nothing at all; only what survives them reaches a model. A greeting cannot book a seven-phase run, and a hard question cannot be answered off the cuff. This station decides what kind of work this is. Station 5 decides what runs it. The two are pulled apart in Classification, then routing below. |
| 2 | Decision cache | A hash of the normalised prompt keys a sixty-second cache, so a retry or a duplicate reuses the decision instead of paying to make it again. |
| 3 | Hot layer | Exactly two memory files load on every prompt, capped at 48 entries of 256 characters. Everything else stays on disk until something asks for it. The cap is the design: memory that grows without bound eats the window it was meant to serve. |
| 4 | BM25 recall | BM25 is Best Matching 25, the standard ranking function information-retrieval systems have used for decades. It is a lexical keyword search across the knowledge corpus with no model call at all. A full recall, including starting the process, measures 40 to 50 milliseconds on the current corpus. The top five results above a score threshold of 0.20 are injected; below it, nothing is, not even a header. BM25 returns a ranking score, not a judgment about meaning, which is why the threshold is a tuned number rather than a claim. |
| 5 | Rung select | The downstream half of station 1. Classification produces a level: max, high, medium or low. Callers name that level, never a model. Two tables do the binding: level to lineup, lineup to model. Cheap work cannot silently ride an expensive model, a hard call cannot be quietly downgraded, and the two things that change on different clocks, the lineup and what counts as hard, each have exactly one edit point. |
| 6 | ISA state | Each run keeps one state file, and that file, not the transcript, is the authoritative working state the agent reads back. It re-reads a page of structured state instead of re-reading the conversation that produced it. |
| 7 | Event fold | Separately from any single run, the registry of runs is event-sourced: every write appends a field-level diff to an append-only log, folded into a derived snapshot and compacted on a size trigger. The log is the durable record; the snapshot is a materialised view of it, so readers get a current picture without replaying history. |
| 8 | Compact & carry | The thread is summarised. The rules are not. Corrections, operating rules and identity re-enter the next context window at full strength while the transcript shrinks. This is the point of the shape: the loop closes because memory carries it, not because the model remembers. It carries a mistake with exactly the same strength, which is why What broke below exists. |
Classification, then routing
Drawing routing as a single station flatters it. Once you know a request is hard, sending it to the expensive model is a table lookup. Knowing it is hard is the actual problem, and that judgment is made before any of the expensive machinery runs. Two functions, not one: the band shows them as stations 1 and 5 because they sit at opposite ends of the loop, but station 5 is only executing a decision station 1 already made.
Three inputs settle a rung, in descending order of authority.
Policy pins, first and binding. Some work has its rung fixed by rule rather than by judgment, precisely because judging it is what you cannot afford to get wrong. Any change to the system's own rules routes to the top rung regardless of how small the change looks, and the advisory role is pinned there too. A pin is not a default. It overrides the classifier's opinion rather than seeding it.
The classifier cascade, for everything else. Deterministic fast-paths run first and cost nothing; the sixty-second decision cache catches retries and duplicates; only what survives both reaches a model. That model is deliberately not the cheap one, which is the counter-intuitive part. Under-classification is the asymmetric failure: a hard question answered on a cheap rung produces a confident wrong answer that costs far more to discover than the routing ever saved, while over-classification costs only money. Optimising the classifier for price optimises the wrong side of that trade. A length-tiered fail-safe covers the case where the classifier itself does not return an answer.
Failure, after the fact. A down-routed run that then fails its success criteria re-dispatches one rung up. This is the design admitting that the first two inputs are estimates: the system is allowed to be wrong once, cheaply, and to correct itself without a human noticing. It is the only path that moves up after dispatch. Everything else routes down or holds.
Every one of those decisions writes a line: session, timestamp, mode, tier, rationale, which of the three inputs decided it, and how long it took. Classification you cannot inspect afterwards is indistinguishable from guessing.
The model layer
Personas are separate from models. The same agent definition runs cheap or expensive depending on the rung the router hands it at dispatch, so the ladder needs no duplicated persona definitions. It is not free, though: models differ in prompting behaviour, tool use and context handling, so a binding can still need model-specific tuning. One concrete trap: an agent carrying its own initial prompt ignores the dispatch-time override and runs whatever model its definition names.
| Rung | Model | What the system routes here |
|---|---|---|
max |
Fable 5.1 | The hardest analysis and every change to the system's own rules, plus the once-per-deliverable commitment call. Its token rates are about twice those of the rung below, so it fires only when the work earns it. |
high |
Opus 5.5 | Everyday analysis and drafting, and the pinned classifier. Dispatch uses the tier alias, which resolves to the current generation, Opus 5.5 today, so "Opus" names the rung and the alias decides the generation. The table also keeps dated identifiers for a drift check, and today those are a generation behind. That is lesson nine below. |
medium |
Sonnet 5 | Utility inference: summarisation, classification, reading an image. |
low |
Haiku 4.5 | Lookups where judgment adds nothing. |
| cross-vendor | GPT-5.5 · Gemini · Grok · GLM | Vendor diversity rather than tier scaling; the rung never changes these. Each route carries a data-classification ceiling that governs what may cross it. |
The pin that explains the design: the classifier is fixed at high and deliberately never
max. It runs on every prompt that survives the deterministic fast path, which is the whole
point of putting that path first. The most-leveraged call in the system is explicitly forbidden
from being the most expensive one, and a large share of prompts never reach it at all.
What the harness provides
- Router. Decides mode, tier, model, vendor and reasoning effort before any work begins. Four stages, cheapest first.
- Algorithm. Seven phases with verification gates, escalating by how hard the question actually is.
- Memory. Four tiers, plus a background reviewer that proposes changes rather than making them.
- Hooks (53). Lifecycle interceptors. One blocks any claim that uses a word like verified or measured without evidence attached to it. It is not advisory; the response does not ship. On 4 October it held back one of the assistant's own answers until the article it drew on was cited.
- Claims gate. New since the first version of this page. Anything a prospect or recruiter reads, this site and my resumes included, is checked on every write against an allow-list generated from a file of sourced figures. A withdrawn claim, an overstated verb of authorship or an agency reference outside a resume blocks the write. It checked this page before it shipped.
- Skills (81). Self-activating domain units: a packaged procedure loads itself when the task matches.
- One assistant. The harness runs in one session on one machine, reachable from a phone or a computer through the same session, and it resumes the same conversation after a restart. That sounds like housekeeping. Lesson six is why it is on this list.
- Connectors. Mail, calendar and files reach the assistant only through account-level connectors that authenticate on the vendor's side. The machine itself has no network route to them, by policy.
- Tool authority. Access to a model is not authority to act. Every route carries an explicit action envelope: a deny-list enforced before a call is made, a four-tier gate on memory writes graded by destination, guards on system files and on cross-vendor egress, and a machine-level session policy that refuses network destinations outside an allow-list. That policy has refused five requests from my own agent since 19 September. The most recent was on 11 October, when it stopped the assistant's own attempt to check its administrator rights while measuring this page. One of those refusals is lesson eight: it held at the machine, and the file arrived anyway by another route.
- Ask-first layer. Between the hard refusals and ordinary work sits a layer that asks before it acts. Four kinds of action stop for my approval however they are phrased: anything that leaves the machine, anything that deletes or overwrites, anything that spends money, and anything that touches a credential. So does any attempt to change these rules. It asks; it does not block. It is designed so that repeated approvals of the same kind become a proposal to the machine's owner, who decides. The assistant never loosens its own rules. Lesson fifteen is what that looks like from my side of the screen.
- Data confidentiality. Three data tiers, and a per-route egress ceiling by data classification governing which vendor may see which class of material. No assistant, mine or anyone else's, receives an employer's or a client's security data without a contract that says so.
- Evidence. A structured line per routing decision (session, timestamp, mode, tier, rationale, source, latency), per tool failure, per memory write, and per blocked network call. That is operational logging with identity and decision provenance. It is not a tamper-evident audit trail, and calling it one would overstate it.
- Work. Capture surfaces into a single private system of record, with separate readers out.
The model has capability. The harness has authority. That distinction is the design: an interchangeable processing layer in the middle, with identity, policy, state, routing, retrieval, authorisation and telemetry deliberately outside it. The point is the one I make about security operations generally: the control you can demonstrate is worth more than the control you can describe.
What broke, and what it left behind
A harness earns trust the way a SOC does: by what it does after something goes wrong. These are the failures from its first months in daily use, each with the rule it left behind and where that rule now lives. They are written as they happened, with the private details taken out.
| # | What happened | The rule it left | Where it lives |
|---|---|---|---|
| 1 | The assistant's own phrasing became a fact. Early on it described my role with a stronger verb than I had used, and added a figure I never gave. That wording entered memory and loaded into every later session as established until I caught it. | Verbs of authorship carry weight. When the wording is the assistant's rather than mine, it takes the weakest accurate verb until I confirm it. A figure without an attributed source does not appear in anything outward-facing. | Code. The claims gate blocks the withdrawn wording on this site and on resumes. |
| 2 | A name was inferred, not recorded. The assistant guessed how a family member's name is written instead of using the form on record, and the guess reached paperwork before it was caught. | Never infer a person's name. Use the recorded form or ask. On anything official, the name matches the identity document exactly. | Written rule. |
| 3 | One inbox was read as all of them. A morning briefing said a message had not been resent. It had, from a business mailbox the assistant cannot see. | Absence in one source is not absence. The phrasing is "nothing in this inbox; I can't see the others." | Written rule. It came back on 9 October, three weeks after it was written: a briefing said a recruiter had not sent new times, and she had, to the business mailbox. |
| 4 | An empty calendar was read as a free morning. The assistant spent two days planning around an 8:30 Saturday arrival. I have a standing class then that was never on the calendar. | Before advising on my time, ask what already occupies the slot. Routine is often not written down. | Written rule. The class is now a calendar block. |
| 5 | Progress was tracked, not practiced. A daily learning plan advanced thirteen days against a state nobody had reported. I had not practiced. | Advance only on my report. No report means the day repeats. | Written rule. The counter records whose report moved it. |
| 6 | The wrong window. An evening's analysis happened in a different assistant on another computer. The next morning this one had never seen it. The app now lists plain chats, co-work sessions and harnessed sessions in one list, told apart by an icon. | One harnessed assistant, opened the same way on every device. A single question proves which window you are in: ask it something only the harness knows. | Written rule. The list itself is a product decision, not something the harness can fix. |
| 7 | Tools load when a session starts. A mail connector reconnected on the account never reached the running session, and compacting the conversation did not reload it. A restart that resumed the same conversation did. | Know which layer owns a tool before telling someone to click something. | Written rule. Session resume is now wired and was tested on a real restart. |
| 8 | An egress control has an edge. The machine's allow-list refused my agent a public rate sheet. The agent then fetched the same file through the model's own fetch tool, which runs on the vendor's infrastructure, where the allow-list does not reach. | The control is real and its boundary is narrower than its name. Vendor-side tools need their own policy. "Blocked at the machine" is not the same as "blocked." | Open. Found while rebuilding this page; not yet fixed. |
| 9 | The drift check drifted. The table meant to catch stale model identifiers is itself a generation behind, and the check that would notice crashes on a missing dependency when run on its own. Nothing routed wrong, because dispatch uses aliases that track the current model. | A detector nobody has run lately is not a detector. It has to run on a schedule and fail loudly. | Open. Found while rebuilding this page; not yet fixed. |
| 10 | Editing a draft moved it. Updating an email draft through the mail connector silently detached it from the conversation it answered. | Rebuild rather than edit, and check the thread before calling it done. | Written rule. |
| 11 | Another assistant asked for the keys. Answering a vulnerability-triage question, a different vendor's assistant offered to analyse the scanner export itself. | No assistant receives an employer's or a client's security data without a contract that says so. This one declines it. | Written rule. |
| 12 | The whole message was copied, not the link. A set of setup steps said "copy the link." The app's copy button copies the entire reply, so the browser searched for a paragraph of instructions. | Give a link on its own, or send it where it is the only thing to click. Every walkthrough states what must be on screen before step one and what you should see after the last. | Written rule. |
| 13 | A notification was read as a status. A connection request stayed on the daily list as "pending" for five days after I had accepted it. Accepting it happens inside the other site and never reaches the inbox. The same shape showed up twice more, with documents already returned. | A notification proves something arrived, nothing more. Ask once, record the answer, stop asking. | Written rule. |
| 14 | A narrow search was reported as a complete one. A morning briefing said nothing needed me while a recruiter's interview offer sat in the inbox, because the search had not included that sender. Days later the assistant said an email was not in my mail after looking back only thirty days. It was from July. | Before saying something is absent, say how far you looked. The daily search now includes the sender of every open conversation in the pipeline. | Written rule. |
| 15 | It was asked to switch off its own safety prompt. The ask-first layer stopped every web lookup for approval, stock quotes included: nine approvals in one morning. I told the assistant to give itself the permission. It declined, because changing its own rules is one of the actions that layer exists to stop, and it drafted my request to the machine's owner instead. His fix was in his build queue within the hour. | The assistant does not loosen its own controls, even when I ask. It routes the request to whoever owns the control. | Written rule, with the layer itself asking before any change to it. |
| 16 | It asked instead of searching. A briefing asked whether I had filed a state form, because it had seen a sign-in code from the state's site. The filing receipt had arrived eleven minutes after the code. The search behind the briefing looked only at mail flagged as important, and the receipt had been sorted elsewhere. | When a message suggests I have already acted, search that sender for the follow-up before asking. Ask only if nothing turns up. | Written rule. |
| 17 | A file was damaged in transit. Saving a document from mail to the drive meant passing its bytes through the model. Twice the copy arrived damaged: the words survived and the packaging did not. | Files do not pass through the model. They move on my side with one tap, or the text is rebuilt and checked. | Written rule. |
The pattern. Most of these are one failure in different clothes: the assistant produced a fact from an incomplete source, and then treated it as established. Lesson 16 is the newest version of it, and lesson 3 is the proof that writing a rule down is not the same as fixing it. Station 8 is why it spreads. The loop that carries a correction into every future session carries a mistake with the same strength. That is not an argument against the loop. It is the argument for checking what goes into it, because a guess that enters memory is still a guess when it comes back out.
The honest count. One of the seventeen is enforced in code. Fourteen are written rules. Two are open, and both still are. A written rule reaches every session at full strength, but it is still an instruction to a model, and a model can miss one; lesson 3 just did. Turning the written rules into checks is the work, and the page will say when each one moves.
Provenance
Updated 11 October 2026. Counts were taken from the running system that day: 53 hooks, 81 skills, 6 agents, 170 knowledge notes. On 5 October they were 53, 81, 6 and 168; on 29 September 53, 81, 6 and 162; and on 19 September 52, 81, 6 and 149. The hook added in that stretch is the claims gate. Recall measured 38 to 48 milliseconds across three queries. The session policy's own log shows five refusals since 19 September. The rungs are read from the routing table that resolves them, and that table's identifiers are still a generation behind, which is why lesson nine is still open. Nothing on this page is illustrative.
The framework is LifeOS, built by Rob Foree. He maintains it the way it asks to be used: a backlog of yes-or-no criteria worked by parallel agents in separate lanes, under a metered usage budget that keeps a reserve for whoever is at the keyboard. What is drawn here is the instance I run and the way I operate it.