Case study · Agency operations · 2026

The handoff that broke in front of the client

The process in the founder’s head, written down as a file that code runs, with a person at the gate and only approved work reaching the client’s folder.

An independent customer-experience studio in Southern California, under 20 people, founder-led. It designs onboarding for membership organizations and professional-services firms, and its whole pitch is that no customer falls through the handoff between teams. Then a client opened the shared review folder and found a draft on last year’s template, sitting next to the studio’s internal QA notes.

Before

The founder is the process. Every account runs the way the founder would run it, because the founder taught each person how, out loud, 1 handoff at a time. Nothing is written down that a new hire could execute. The work moves on memory: which template is current, whether the intake had an audience, whether anyone with taste read it before it went out.

When it breaks, it doesn’t break at the start. It breaks at the end, at the release, where the client can see it.

They had tried the obvious fixes. First, the founder read everything before release. That held until the studio grew past what 1 person can read in a day, and the founder became the queue. Then a checklist per deliverable in the project tool. People ticked the boxes from memory, so the checklist recorded what people remembered, not what happened.

The morning after the review-folder call, the founder issued a mandate with no spec behind it: write down how the studio does everything, and let AI run it. A studio that sells clean handoffs had just dropped a handoff in front of a client. The mandate was the right instinct. It was also a sentence, not a plan.

What was done

We didn’t start with the SOPs or with a model. We started where the failure landed: the client’s folder. The first rule: nothing reaches that folder unless a named person approved those exact files.

Then 1 process, not all of them: a content piece, from request to the client’s folder. The founder explained it once, in an interview. A model turned the interview into an SOP file, and code checks that file against hard rules before it’s allowed to exist: there’s a named human gate, publish comes last and only after the gate, and every step’s inputs come from the intake, a pinned template, or an earlier step.

Screenshot of the SOP runner’s Interview to SOP screen. Stats across the top read 6 steps, 1 human gate, 8.91s to codify, 0 attempts refused. On the left, the process interview, labeled written for this demo, answers questions such as when a content request comes in, what happens first, and which template the brief uses. In the center, SOP v1 with a VALID badge lists the 6 runnable steps: write the content brief from the intake, write the draft from the brief, run deterministic internal QA, export a review-tool-ready file, review the draft and export for taste and voice, highlighted as HUMAN-GATE with reviewer delivery, and copy the approved draft and export into the client folder. On the right, the SOP file content-production.sop.yaml, with the brief template pinned at version 2 and the draft template at version 3. The header reads The agency, content production, demo, sample content, no client named. — 01 · Interview to SOP The process interview on the left, the 6 steps the model wrote in the middle with the human gate marked, and the SOP file on the right. Real capture. The interview was written by us for this demo; it is not a transcript of anyone. Sample content, no client named.

The founder plays every instrument on the record. On stage there’s a band, and the band needs the charts.

The runner executes that file 1 step at a time: brief, draft, internal QA, export, the gate, publish. There is no “run step 4” command. It can only advance, each step writes a sealed receipt, and a skipped or reordered step halts the run.

Screenshot of the run screen for piece P01, headlined The checklist fills itself. Stats read 6 of 6 steps done, 2 AI steps, 20.67s AI time, 8 of 8 QA checks pass. On the left, the receipts table lists the 6 steps in order with their kind, executor, time, artifact, and a chain of seal hashes from each receipt to the next; step 5, taste-review, is executed by a person with the decision approve: On voice. Ship it. Below it, internal QA run by code shows 8 checks passed, among them starts with headline, required sections, word count, no exclamation, and no em dash. On the right, the published draft, marked approved and published. — 02 · The checklist fills itself 1 piece’s checklist filling in step by step, QA run by code, the stop at the gate, and the published draft. Real capture.

Then we broke it on purpose, the 2 ways the founder said it always breaks. 1 intake arrived with no audience. 1 draft was written on the old template. Both ran all the way to the gate, the way a busy team works around a gap. Both stopped there, loudly, with the reason printed. A halted run can’t be approved.

Screenshot of the failure injection screen, headlined It stops at the gate. Stats read 2 runs halted, 0 files leaked, 3 client files before, 3 client files after. On the left, run P03 is marked HALT, injected missing input, with the reasons intake.audience was empty when step brief ran and QA failed on no placeholders; its checklist shows steps 1 to 4 done and step 5, taste-review, stopped. In the middle, run P04 is marked HALT, injected stale template, with the reasons that the draft and QA steps used the archived version 2 template while the SOP pins version 3, plus 2 failed QA checks; its checklist also stops at step 5. On the right, the client-view folder lists the same 3 P01 files before and after, and a box reads New files from P03 or P04: 0. — 03 · It stops at the gate Both halts with their reasons, both checklists stopped at the gate, and the client folder before and after: 3 files, then 3 files. Real capture.

This is where the team’s job turns over. The delivery lead stops carrying the sequence in their head. Code checks readiness before a person sees anything. The person decides only what code can’t: is it good, is it on voice, would the founder put their name on it. Approve, and the exact bytes on screen go to the client. Flag it with a note, and that version never leaves work in progress.

Screenshot of the live gate page, headlined The taste gate, for gate taste-review, reviewer delivery, run P02 r2 on SOP v2. Stats read 0 readiness problems, draft version v2, plus 4 and minus 7 lines versus v1, 2 files shown. On the left, readiness checked by code shows a READY badge and 9 passing checks, the checklist waiting at step 5, and the note left on the flagged version: the opening is generic. In the middle, draft v2 is diffed against v1, removed lines in red and added lines in green, with a new opening about a late Friday afternoon. On the right, the decision panel, labeled only you decide this, lists the 2 files the client receives on approve with their hashes, a note field required to flag, and 2 buttons: approve, publish to client view, and flag, never reaches the client. — 04 · The taste gate The live gate page: readiness checked by code, the second draft diffed against the flagged one, approve or flag. Real capture; the reviewer’s decisions in the recorded run are seeded, and marked as simulated.

Screenshot of the client view screen, headlined Only approved work shows. Stats read 29 artifacts in progress, 8 client-visible files, 0 audit problems, 3 runs kept out. On the left, every run with its status: P01, P02 r2, P05, and P06 published, P02 r1 flagged, P03 and P04 halted, above a table of file counts in progress and in the client view at each moment of the run. In the middle, the work folder lists all 29 in-progress files. On the right, the client-view folder, marked audit clean, holds only the approved drafts and exports with an approval record for each piece, and a note reads Not here: P02’s flagged version, both halted runs, every brief, every QA report, every voided step. — 05 · Only approved work shows Every run and its status, all work-in-progress files, and the client folder holding approved files only, with a clean audit. Real capture.

Last, the part that kills most process docs: they go stale. So the SOP updates by sentence. “The client switched review tools; drop step 4’s export and add a share-link step.” The file rewrites itself, and every run still in flight is re-planned onto the new step.

Screenshot of the SOP update screen. The sentence at the top reads the client switched review tools; drop step 4’s export and add a share-link step. Stats read 7.57s sentence to new SOP, 2 runs re-planned, 1 receipt voided, P01 keeps its v1 record. On the left, the v1 and v2 step lists, with step 4, export the draft as a review-tool-ready file, struck through in v1 and replaced in v2 by create a share-link for the client’s review tool. In the middle, the patch from the model, applied and validated by code: remove step export, add step share-link after QA, replace references to step.export, followed by the SOP file diff from version 1 to version 2. On the right, the running workflow re-planned at write: P05 kept brief, draft, and QA with nothing voided, next share-link; P06 kept the same steps with its export voided, next share-link. — 06 · The SOP update The sentence, the old and new step lists, the model’s patch, and both in-flight runs re-planned onto the share-link step. Real capture.

The wobble

The mandate came with a promise attached: the process would never break. The build took that back for us. On an early run, a draft came out with the template’s header block sitting above the headline. All 7 QA checks passed it. The reviewer’s flag kept it out of the client folder, but for a different reason. We added an 8th check. On the next run, the model’s SOP patch named a step in a way the file’s rules don’t allow. The runner refused it, correctly, then stopped with no retry. We added 1. And the draft that was approved in the recorded run writes “three” and “five” where the house style asks for digits. No check looks for that, and the seeded reviewer passed it. So nothing here gets to 0 errors, and you can’t codify taste. The claim that holds up is where it breaks and who sees it: in front of a reviewer, before the folder, instead of in front of the client.

After

Measured on our build, with inputs we wrote and a simulated reviewer, not on anyone’s floor. In the recorded run, the runner wrote 29 work-in-progress files and 8 reached the client’s folder, every one traced by the audit to a sealed approval. The 2 injected failures added 0. The 1-sentence SOP change was written, validated, and live on both runs in flight in under 8 seconds.

What we haven’t measured matters as much. Client-visible failures before and after: a demo can’t measure it. Reviewer time: seeded, so not measured. How codify handles a real founder’s interview, longer and messier than ours: [TK].

The texture is where the change lives. The process stops living in 1 head. The current template is whatever the SOP pins, not whatever is on someone’s desktop. The client folder holds approved work and nothing else, and anything that got in another way shows up in the audit. The founder stops being the queue. And when a client changes review tools, the fix is a sentence, not a retraining.

What it required

The founder in the room, and not as a courtesy. The founder is the only person who holds the full process, so the founder is the only person who can be interviewed for it. Delegate the mandate and there’s nothing to codify.

The founder accepting that the first written version would be wrong in places, and correcting it instead of abandoning it.

The delivery team agreeing their job changes, from running the sequence to judging the work, and that the gate is a real veto. A flagged piece doesn’t ship, deadline or not.