Three Planes Around a Frozen Model
Operate is the part that runs without me. When I wrote this it was a fleet of scheduled jobs, 12 defined and 4 of them loaded, that gathered overnight from Slack, X, news, and GitHub, wrote the morning brief, closed out the action plan, reseeded grounding, and pruned memory. The "7 AM boundary" from Part 6 turned into a daemon that just keeps going, and there were 19 dated intel digests on disk, the last of them stamped that same day.
The catch with a harness that works overnight is that nobody checks its work until I wake up. Verify started from Part 6's lesson, knowledge needs enforcement. What Part 6 actually enforced was code shape, though, and the four sibling rules that came after it check something harder, whether a claim is true. Don't say "done" without a running artifact, don't act on a finding the artifact has already outgrown, don't outrun the source you're citing, and don't call something false because you checked the wrong place. Each one came out of a dated failure in real customer or account work (sanitized on this page), each one is wired to a gate, and two of them run as demos further down.
Evolve comes from Salesforce AI Research, which published DarwinX and open-sourced its framework, Beagle. The point of it is making an agent better without retraining it. You freeze the model, evolve the harness by selection, and keep a change only if it improves and doesn't regress anything. I ran it, and then I turned the same discipline on my own tooling, so my voice guard is scored on a held-out corpus and gated, which is the second demo below.
All three planes reach real systems through a connector fabric, about 28 MCP servers configured at the time, which is Part 3 grown up.
The Voice Guard, Live
This is the scorer I run on everything I write. It has two layers, a generic AI-writing detector that produces the 0–100 score and my own voice overlay for the tells I keep making (announced hedges, and aphorism cadences I don't actually use). The code is ported verbatim and makes no network call, so paste anything in or try a sample.
Both layers are here in full, the generic detector behind the 0–100 score (2,386 lines when I shipped this page) and my voice overlay, which at that point hard-banned 28 words, 18 phrases, and 19 structural patterns. They run in your browser with no network and give the same verdict my command line does.
The Preserve-and-Extend Gate
The harness decides whether a change to itself gets in with this gate, which I borrowed from DarwinX. A proposed change is scored on a tune set and a held-out set, and it's admitted only if it gains on tune and doesn't regress the held-out set past a small budget. Drag the sliders, then try sneaking through a change that looks great on average but quietly breaks the held-out set.
That's the real math, run against the live baseline (tune 51.7 / held-out 24.3, δ=5). The rule is admit iff g>0 AND R≤δ, where R = max(0, −held-out Δ). The overfit button is the case I care about most, a gain on tune that costs you on held-out, and the gate refuses it.
What the Gate Is Wired To
Behind that slider is a real fitness signal, built from four published methods an applied-AI scientist at Amazon pointed me to, and they fit the DarwinX loop cleanly. Meta-Knowledge prepares the context, VERA scores the output with an honest bound, ECHO attributes which step failed, and DEEVO optimizes where there's no gold answer.
That loop runs on two surfaces. One is the voice guard from the first demo, small-n, my own labeled corpus. The other is code, where the labels number in the hundreds and the bound is statistically real. That surface is a full SWE-bench Verified rollout through Salesforce AI Research's Beagle/DarwinX framework, on my own GCP.
What's being scored is stock mini-swe, and no harness lifts a model to 88.8%, so this number says nothing about my harness. It's a 2026 model run against a 2023 public benchmark, which bakes contamination in. I treat it as a gate baseline, meaning a harness change earns its place only when its lower bound beats this, and it doesn't belong on a leaderboard. VERA is the method behind how the 88.8% gets reported, folding the run into one score with an honest bound.
Of the two halves of evolution, only selection was live as of this writing, meaning a proposed change gets scored on both surfaces and admitted only through the gate. The generation half, an evolver that writes its own candidate changes, I was still driving by hand. So what's here is eval-and-gate, and the machine wasn't writing its own changes. The evidence for the evolve plane is also thin compared with verify's, one measured guard, one benchmark task the agent actually missed (the gate correctly rejected the change), and correction loops that mostly propose and seldom act, which is why the title calls the harness evolving and stops short of evolved.
The voice guard is also only a proxy. It scores slop and voice-law, and whether the writing is true or persuasive is beyond it. Push on any proxy hard enough and you end up gaming it, which is exactly why the held-out gate exists, and why what the guard can claim is that it got better at catching my known tells. Whether my writing got objectively better is a different question it can't answer.
The Right Oracle for the Right Claim
This is the verify rule behind one of the failures further down. Before you call something false, ask where it would be true if it were, because absence from a source that wouldn't carry the claim proves nothing. Pick where you'd check this one.
It caught a real mistake. A set of facts got labeled "fabricated" because they'd been checked against a quarterly filing that would never list them, and thirteen of the fifteen turned out to be real.
What the Harness Said About Itself
Before I wrote this page I ran a census of the harness against its own manifest, the file where it describes what it has. Flip the panel to see what the census found.
The manifest wasn't the only place the harness skipped its own rules. Until the day I wrote this, the tooling that makes all of this measurable had no version history, and its folder wasn't even tracked, so a harness that preaches "prove it, and don't trust a stale finding" wasn't applying either rule to itself. I've fixed that since. The drift in the last demo wasn't sabotage, it's just what happened as the system grew, and what I do about it is audit my own machine on a schedule, as adversarially as I'd audit anyone else's.
Where the Verify Rules Came From
I never sat down and designed the verify plane, it built up as scar tissue, one failure at a time.
A capability claim in a customer Support handoff got written toward the reassuring version instead of what the source actually said. The audit behind the oracle demo was a real account, sanitized here, and 13 of its 15 "fabrications" were true. An account brief invented dollar figures when the data regenerated underneath it, and the account-research platform quietly wrote zero rows for six weeks while every code review called it done.
Three of those four were customer-facing artifacts, so the harness learned to check whether a claim is true because a claim reached a customer, or nearly did, and was wrong. Each rule is just what I built afterward so that particular failure would stop happening, and each one ended up behind a wired gate. That's the mature, load-bearing half of the harness, four rules and four wired gates that I use every session.
Operate shows up in the deal work too. Every product claim gets grounded in a cited corpus before it reaches a customer, and opening an account's Slack channel or writing into a deal folder fires the reminder to do it automatically. On the verify side, a territory number traces to one source of record behind a gate that turns red on a wrong figure. I work accounts this way because of how the work used to break.
The deal domain those gates guard is private, so you get the rules and their dated origins without any of the accounts. Whether every gate fires on a given live brief is something you'd have to watch one run to know, and a file on a page can't show you that.
Can the Guard Catch an AI Writing as Me?
The guard from the first demo scores everything I write for AI tells, so the next question was whether it could catch an AI pretending to be me. I aimed the test straight at its blind spot, an AI answering the same questions I'd answer, in my own register, lowercase, with my phrasing and my analogies. Try calling these yourself before you get to the numbers.
Each of these three short answers to a Salesforce question came from an AI told to answer in my voice. Would you have called them a person or a machine?
In the real test, a consensus of three language-model judges caught obvious AI 11 times out of 13, with 0 false positives across 12 samples of my real writing. Against AI wearing my voice it went 0 for 11, every judge rated the imitation human, and a same-author judge rated the fake as more me than me, 83.1 to 82.8.
For one afternoon I thought I'd fixed it. A cheap deterministic check flipped the score to 11 out of 11 on the imitations, but it was keying on a punctuation habit the imitator over-applied, and a one-line instruction to the imitator erased it, back to 0 out of 7 on an adaptive version. Worse, a dumb "is this longer than forty words" rule scored identically to my sophisticated one, because what really separated the two sets was length. I'd built a detector for my own test and mistaken it for an imitation detector, which is the same proxy trap this page warns about, and I walked into it myself.
When the imitation is short, in my register, and grounded in things I actually say, there's no signal left in the text, and asking a blind checker "is this John?" was the wrong oracle for the question anyway. What holds is provenance, knowing who typed it. The guard still earns its keep, since it catches every lazy imitation for free and never flags my real work, but once a mimic knows the guard exists, where the words came from tells you more than the words do. The failure I actually worry about is the guard handing a "clean" verdict to exactly the input that was built to get one.
Since this page keeps telling you to measure a claim, it runs its own visible copy through the guard from the first demo when it loads.
While I was writing, the guard flagged my own tells, including one on this page, and I cut them.
What the Harness Buys
Seven parts have argued that the harness is the product and the model is a CPU you rent, so it's fair to ask what that gets anyone. For me it's a harness that measurably improved, one that keeps a change only when the change clears a held-out bar, so my output got better and stopped quietly regressing. Other SEs can run the same discipline through the SE Starter Kit instead of rebuilding it. The build I had planned next makes it model-agnostic, porting the same Claude Code config onto an open runtime so one harness runs on GPT, Grok, or Gemini. That port was still planned and not shipped when this page went up, and I'll show it when it runs.
Customers standing up agents keep hitting the same wall. They can't tell whether a change made the agent better, regressions ship silently, and "eval" is really a vibe. What's on this page is one working answer, where every change gets measured and a regression stops at the gate before anyone sees it, the eval carries a bound where a vanity number would usually sit, and provenance covers the case no detector can. In a customer conversation that's about agent quality and trust, which opens a bigger door than a feature demo does.
It also maps onto Agentforce's evaluation (Testing Center), auto-improvement (Agent Optimizer), and governance (Agent Fabric), and the model-agnostic part is the BYOLLM promise made concrete, because a customer's evals, memory, and governance live in the harness above the model layer and survive every model swap. What I haven't answered here is what happens to those gates when somebody other than me is running the harness.