The trigger was one line in the devlog: “We’re not building an Archon team. We are building this particular multi-agent shape.” That’s CJ writing to himself at the point the architecture forked. The sprint was B4-native-agent-harness. The question it was answering: does the Opus rewrite layer need a general orchestration framework, or does it need one specific thing that a general framework would obscure?
The answer was the second one.
What the stack is actually doing
The de-AI-ish stack has three layers. They run in sequence, and each one does exactly one job.
dvlaw/ai_tells.py is the regex layer. Pure dictionary expansion — no LLM, no network call, no architecture beyond a lookup and a match. Sprint B4-dei-list-extend broadened the coverage. The output is a flag list: mechanical AI tells found in the text, each one localised to where it appears.
The Opus layer rewrites them. That’s B4-voice-fix-agent. It takes the flag list as input, loads the voice profile as a positive constraint, and passes the flagged passages through Claude Opus 4.7. The voice profile it works against isn’t a learned artefact from some multi-day enrolment process — sprint B-voice-seed captured it as a hand-written 10-rule codification, written during the 2026-05-28 review session. That shortcut shaved days off the timeline; the trade-off is that the profile is a point-in-time snapshot, not an empirically tuned model. Good enough for this use case.
The CLI surface wraps both. dvlaw_voice_fix.py <file.mdx> runs ai_tells.scrub, writes a .tells.txt sidecar, prints up to a five-flag preview, then hands off to the rewrite agent. Sprint B4-voice-fix-cli closes the loop so a user can invoke the whole stack without touching any of the internals.
That’s the full pipeline. The question is why the Opus layer talks to a native osascript Terminal harness rather than Archon.
The architectural pivot
Before B4-native-agent-harness, the thesis was being bounced off Haiku via the Anthropic SDK directly. That worked until it didn’t. The problem wasn’t Haiku’s capability — it was that the single-agent SDK pattern was becoming the wrong shape for what BBBrain needed.
The instinct was to reach for Archon. Archon is a general orchestration framework; it handles agent routing, tool dispatch, multi-agent coordination. It would have solved the problem. It would also have introduced a dependency on patterns, abstractions, and lifecycle assumptions that BBBrain doesn’t need and would eventually work around.
The harness BBBrain needs is not general. It is one specific multi-agent shape: a regex scrubber feeding flags to an Opus rewrite agent, with a CLI wrapper on top. That shape is fixed. The orchestration requirements are fixed. A general framework adds surface area without adding capability, and it makes the specific shape harder to reason about because it’s now expressed in the framework’s idioms rather than directly.
The osascript Terminal harness is the direct expression. It’s project-owned, which means it carries no external framework assumptions. It runs Opus 4.7 through a native agent invocation rather than through an SDK call shaped like a one-shot completion. The multi-agent coordination is explicit in the project code, not delegated to an abstraction layer.
This is a genuine trade-off. Archon would have been faster to stand up. If BBBrain’s orchestration requirements change substantially, the project-owned harness will need to grow to meet them, whereas Archon would already have that surface. The bet the devlog is making is that the requirements won’t change substantially — that the shape is known and fixed — and that the cost of the framework abstraction is higher than the cost of owning the harness.
What the harness validates
The devlog labels B4-voice-fix-agent as “second consumer of the native agent harness (first non-thesis).” That phrasing carries weight. The harness was originally built for the thesis pipeline. The voice-fix agent is the first time anything adjacent reuses it. A framework-bound harness would raise a fit question here; a project-owned one raises a simpler one — does the invocation pattern generalise? The devlog says it does, and that’s the reusability claim the sprint was validating.
One agent consuming a harness is an implementation. Two agents consuming a harness is evidence that the harness abstracts the right things. Not proof — two data points isn’t proof — but enough to proceed without redesigning the layer.
The regex-first principle
Worth pulling out explicitly because it shapes what the Opus layer is asked to do.
The regex scrubber runs first. It flags mechanical tells — the kind of AI-voice patterns that a dictionary can catch reliably without any inference. By the time Opus sees the text, the easy cases are already identified. Opus isn’t being asked to find AI tells; it’s being asked to rewrite the ones the scrubber already found, with the voice profile as the positive constraint on what the rewrite should sound like.
This separation matters because it keeps the LLM call tightly scoped. A single Opus pass over a flagged list is cheap and fast. An Opus pass over an entire document, tasked with both detection and rewrite, is expensive and harder to evaluate. The regex layer does detection; the LLM layer does rewrite. Each one does the job it’s actually suited for.
The .tells.txt sidecar is a byproduct of that separation. The CLI writes it alongside the input file. It’s a record of what the scrubber found before the rewrite ran. Useful for audit; also useful for iterating on the regex dictionary, because you can see exactly which rules fired on a given document without running the full stack again.
The voice profile shortcut
B-voice-seed deserves a note. The standard path to a voice profile in BBBrain involves a multi-day enrolment interview — an empirical process where the system learns the voice from enough examples to codify it. CJ skipped that for this sprint and wrote the 10-rule profile directly during the review session.
The case for that shortcut: the voice is already known. It’s CJ’s voice. A multi-day interview extracts rules that CJ could write from memory. The enrolment process is the right approach when the voice is implicit or distributed across many contributors. When the voice belongs to one person who has already articulated it, the interview is overhead.
The risk is version drift. A hand-written snapshot is correct at the time it’s written. An empirically trained profile updates as examples accumulate. If the voice evolves, the hand-written profile needs a manual revision; an empirical one would absorb the drift passively. That’s a known debt. The B-voice agent sprint will address it when it ships.
Out of scope
This article covers the architectural decision and the three-layer pipeline. It does not cover the thesis pipeline itself, the variant-picker sprint that preceded B4-native-agent-harness, or the B-voice enrolment agent. Those are separate sprints with separate write-ups.
What the devlog says next
The reusability claim on the harness is validated at two consumers. The regex dictionary is broadened. The CLI surface is user-facing. The voice profile is a working v1 baseline. The stack is complete enough to run on real documents.
The append-only record is in the devlog, tagged dvlaw, across the five sprints from 2026-05-28. Each entry is one paragraph: what changed, why, what the trade-offs were. The consolidated form is here. The next round of work — whenever the voice-fix agent surfaces something worth pulling out — will follow the same pattern.