Over the last seven weeks, I wanted to see what one person could deliver without laying hands on execution, and to see what would happen with my own productivity. I've learned that agentic execution operating models fail without structure.
This paper documents that structure: a three-tier hierarchy of agents (chief of staff, program managers, specialists), the human-in-the-loop discipline that keeps it safe to leave running, and seven weeks of real, concurrent, multi-program use of it by one human operator.
Framing note
This is written for anyone running, or considering running, more than one AI agent against real work without a team standing behind them to catch mistakes: solo operators, small teams experimenting with agentic delegation, and engineering leaders evaluating whether a hierarchy is worth its setup cost. The purpose here is to document one working model in enough detail to be reused or argued with: what the hierarchy actually enforces versus what is just habit, what human oversight looks like once execution is fully delegated, and what a real multi-week case study says, and does not say, about whether any of it works.
In short
One person cannot execute five concurrent programs by hand, but one person can supervise several that execute themselves, if the supervision has a structure durable enough to survive being run by someone busy. The structure here is a three-tier hierarchy (chief of staff, program managers, specialists), enforced by two things a prompt can't: a hard allowlist of named agents on who the top of the tree is permitted to dispatch, and the removal of Bash, Grep, and Glob from that same top tier, so it cannot quietly do the work itself instead of delegating it.
Structure alone doesn't make it safe to run unattended; a human-in-the-loop discipline does: propose, verify, execute, as three beats that are never merged, with approval attaching to a concrete artifact rather than to whoever happens to type the command. Structure alone doesn't make it honest, either; a controls-vs-claims discipline does: treating "there's a rule for that" as a claim to verify against behavior, not a fact to relay upward unchecked. Seven weeks of real use across five concurrent programs is not a benchmark, but it is evidence: 130 commits under one canonical identity, three adversarial-review catches with real numbers attached, and a five-day allowlist gap in the model's own roster that the same discipline caught in its own house.
A hierarchy exists so judgment stays human while coordination doesn't.
The model is three tiers. A chief of staff sits at the top, on the largest model in the lineup (opus or fable), because its whole job is judgment: turning a human's intent into something a program manager can build against, and deciding which decisions are worth a human's attention and which aren't. Below it, one program manager (PGM) per active program, often running on a smaller model, each scoped to a single program's repositories and free to dispatch anything it needs. At the bottom, specialists: leaf agents with no ability to dispatch anything further, built to do one kind of work well and then stop (engineers, designers, researchers, product managers). Most carry no persistent memory; a couple do, where the work benefits from it, and this optimizes token consumption.1
Two mechanisms make this a structure rather than a set of instructions a busy session can drift past. First, the chief of staff's dispatch tool carries a hard allowlist of named agents: if a name isn't on the list, the dispatch request fails outright, and the chief of staff isn't even shown the type as an option. That turns "who this tier may address" from a line of prose into something the client refuses to execute. One dependency worth naming: this allowlist is honored because the chief of staff runs as the session's own agent, not as something dispatched inside another session. Inside a subagent definition the same syntax is ignored outright: the subagent can spawn any type, and the names in the parentheses have no effect at all. The control is real, and it is conditional on that binding. Second, the chief of staff has no Bash, no Grep, no Glob. It cannot run a command, and it cannot search a tree for what it doesn't already know the path to. That absence is the point: it forces every piece of real investigation through delegation, instead of letting the chief of staff quietly do the work itself and report a synthesis as though a program manager had done it. It retains Read, Write and Edit (deliberately, so it can write specs and maintain its own memory), so this is a boundary on discovery and execution, not a total read barrier.7 Filenames, directory layout, and which model runs which tier are all taste, changeable to fit how you work. The allowlist and the missing tool grants are not; remove either one and the model stops enforcing the behavior it exists to enforce.
The chief of staff also carries a staff of its own: a chief engineer / architect, an Anthropic SME, and a design lead, advisors it dispatches directly when weighing a plan or a recommendation, distinct from the shared specialist tier below.
A fourth tier cuts across the other three: cross-functional advisory specialists (security, UX, architecture, and engineering-lead review are illustrative examples) report directly to the chief of staff and are automatically available to every program manager too, since PGMs carry an unrestricted dispatch tool. They review and advise rather than implement: enforced by tool grant for security, architecture and engineering-lead review; for UX it's a brief-level convention, since declaring persistent memory auto-grants Write and Edit. A finding from any of them is input to a decision, never authorization by itself. This shared tier is what makes the adversarial review in Section 04 possible without standing up a dedicated security specialist inside every single program.11
Memory lives on disk at every non-leaf layer, using the platform's own per-agent memory feature: one always-loaded index per agent, capped, plus topic files the agent reads on demand, so a session can end and the next one can pick up state without re-explaining it. As of this writing, that tree holds 1 chief-of-staff definition, 5 program-manager definitions, and 17 specialist definitions, the chief of staff's own staff among them.17 That count is a filesystem fact, not a claim about what's actually dispatchable, and the gap between the two has bitten this model in its own house. Four specialist files sat on disk from 2026-08-17 to 2026-08-22 (five days), reachable by nobody.18 Whether the four were ever registered as dispatchable types during those five days was never established; the contemporaneous record says they were not visible as available agent types. What is certain is the second edit that hadn't happened: their names were never added to the chief of staff's Agent(...) allowlist, so every dispatch failed. The enforcement mechanism worked correctly, and that is why the failure was silent. Applying this paper's own standard: a file on disk is a claim, not a control, until something has actually dispatched it.
Approval is a gate on an artifact, not a human running the command.
Two rules sound like they contradict each other and don't: agents should never change anything without approval, and execution is not the human's job. Both hold at once because the gate is approval, not operation. The human personally pasting or running a command is not the control: it's the thing this model exists to remove from their day. The control is a human approving a concrete artifact: a complete file, a diff, a named plan, before an agent applies it.2
That only works if propose, verify, and execute stay three separate beats, never merged into one turn. An agent that proposes a change and then executes it in the same breath has broken the loop even when the proposal was good and the execution was correct, because nothing checked the proposal against intent before it became real. The full chain: the human states intent, often informally; the chief of staff turns that into a specification a program manager can build against; the program manager scopes, staffs, and designs, and reviews that plan with the chief of staff before going further; the chief of staff evaluates the plan against the original intent (its actual job, not passing the plan upward unread); adversarial review runs, using the shared tier from Section 01; the chief of staff returns a recommendation; the human approves; and only then do agents execute, including whatever apply step is involved.2
The report that reaches the human at that recommendation step is written the way you'd brief someone whose attention is the scarcest resource in the room: decisions first, before the reasoning behind them; each decision reduced to four lines (the ask, the impact, the trade-off, the alternative) with a stated recommendation, not a menu of unweighted options. One rule in that discipline is narrow but has real teeth: never put a placeholder inside a fenced shell block. Many chat interfaces render a fenced shell block with a one-click "run" affordance, and a block containing a literal placeholder can get executed as written rather than read as a template: one command per block, and every command runnable exactly as it appears.3
Approvals themselves are batched, not serialized. A session opens with the full planned arc and every foreseeable approval point bundled together, so a human grants what's acceptable once and the work runs without stopping to ask again for something already covered. A decision that surfaces mid-session and wasn't pre-approved gets parked, not acted on immediately: the full queue is presented once, at a natural pause. Some gates are exempt from batching no matter how routine they start to feel: credentials, anything destructive or touching the physical world, and root- or home-directory configuration changes. Naming those exceptions up front is what makes it safe to batch everything else aggressively.4
Work moves through one fixed lifecycle, from intent to execution.
Section 02 describes the approval discipline that governs this lifecycle; this section is about what actually moves through it. Intent, from the human, is often informal: a screenshot, a sentence, a description of what something should look like, not a spec. It becomes a specification once the chief of staff has translated it into something a program manager can build against. The program manager scopes the work and staffs it (deciding which specialists it needs and what each one is responsible for) before any adversarial review happens, because a plan that hasn't been scoped yet isn't a real plan to review. Review runs, a recommendation goes to the human, and only approved work executes.
What moves through that pipeline is governed by five rules that make the output usable and the rollback cheap:6
- Whole files, never line edits. "Change line 84" breaks the moment an editor's line numbers drift, and a line edit can't be reliably undone: a whole file can simply be re-pasted.
- Version the filename, not the commit.
ops-dashboard-v19.yamlbecomes...-v20.yaml, so the previous version is the rollback, sitting right next to the new one rather than buried in history. - Write to the repo, not through chat. Hundreds of lines pasted into a chat message aren't diffable and aren't where an editor expects them. The deliverable is a file at a path; the message just names the path.
- Identify by filename, never by commit SHA. A SHA is meaningless at the interface a human actually works in (an editor and a file path) and forces a translation step every time. Two versions of the same file in flight get told apart by content, not by hash.
- Build from current live state, never a stale copy. Verify the file being edited still matches what's actually running before touching it: anything a human can edit directly is assumed to have drifted since an agent last looked at it.
None of these five rules is exotic. What they buy, together, is a rollback path that requires no memory of what changed and no git archaeology: just the previous filename, sitting where it was left. A worked comparison of a vague dispatch brief against a properly scoped one (naming exact files, separating commit from push, forcing a working-tree report before any mutation) shows the same discipline applied one level earlier, at the point the work is assigned rather than the point it's delivered.15
Review stays adversarial until only nits remain.
Internally, work iterates in adversarial loops before a human ever sees it (one reviewer hunting discrepancies against a spec, another trying to break the deliverable), and the exit criterion is qualitative on purpose: iterate until only nits remain, not until a fixed number of rounds has run. The human is handed one consolidated, finished batch. A drip of small versions for a human to eyeball one at a time is exactly what this discipline exists to prevent. Every dispatch that produces a real deliverable is expected to name, explicitly, who the adversarial reviewers are and what each one is attacking: normally a cross-functional specialist from Section 01's shared tier or one of the chief of staff's own staff (the chief engineer / architect in particular), not a second pass by the same agent that wrote the thing.5
That shared tier is dispatched proactively, not only on request: the moment a chief of staff is weighing a program manager's plan against the original intent is exactly the moment an outside, adversarial perspective earns its keep, and waiting to be asked defeats the purpose.11
When a program manager hits a capability gap that a better brief can't close (it needs a role that doesn't exist yet), the request travels a fixed pipeline rather than getting resolved ad hoc: the program manager scopes the work as best it can with what it has, and returns a "roles needed" note alongside its actual output, never instead of it. The chief of staff evaluates the request against three tests: does the need recur across dispatches and probably across programs; is it genuinely uncovered by any existing role; does it need different tools or authority, not just a better brief. Every request, including ones the chief of staff would reject, gets forwarded to the human with a one-line verdict. Nothing dies at the chief of staff's desk, because even a rejected request carries signal about where a program is struggling. While a request is pending, the program manager keeps working best-effort: it labels its output as such, states a confidence level, and never fabricates a detail a specialist would otherwise have supplied: a made-up field name or device ID becomes a real action taken on a false premise the moment anything downstream acts on it.12
The tree that reviews every program is also the tree with the most leverage if something writes to it that shouldn't, so authorship of the definition files themselves is deliberately narrow: only the human edits the chief of staff's own definition, even when the chief of staff is certain something in it is wrong: it proposes the exact change and waits. Only the chief of staff edits program-manager and specialist definitions. And any program manager whose remit plausibly touches the agent tree (backup, source control, infrastructure) is instructed, in the strongest terms its definition can carry, never to write anywhere under the shared agents directory. Worth being precise about what that is: prose in an agent definition, not a tool restriction. By this paper's own standard, that's a claim rather than a control, and it's named as one here rather than overstated.13 10
A control that isn't verified against behavior is a claim, not a control.
The rule: never accept that a control exists because something says it exists. When a plausible claim and a cheap check are both available, take the check. This shows up, independently, across unrelated categories of "control" often enough to be a standing discipline rather than a one-off lesson: dead code: a validation function that's correct and simply never called from the path that needed it; a comment that contradicts the line directly beneath it; a config flag documented as a security control that isn't actually on the platform's protected list; a policy that exists only in a conversation, with no file on disk any other agent could have followed; and a pruned allowlist that quietly re-accretes the entry that was just removed, because removing a bad entry once is housekeeping, not a control.14
Three catches from the same seven-week window this paper's efficacy claims are drawn from (Section 06) show the discipline finding real things, not hypothetical ones.
Flagged non-redistributable in config; nothing enforced the flag at runtime. Fixed fail-loud before the next scheduled run.
Undeclared fields shipping through an allowlist that was never wired in. 37 declared, 3 blocked, 0 on re-verification.
In a restore procedure four reviews had signed off on. Found by running it, not reading it.
An unenforced licensing flag. An adversarial licensing review found a redistribution risk in two third-party datasets an ETL pipeline was set up to publish: both were already flagged non-redistributable in the pipeline's own config, but nothing in the pipeline actually enforced that flag at runtime, so the flag was a comment, not a control. The fix derived the pipeline's publish allowlist from that same config flag at runtime, with a fail-loud guard, closing the gap before the next scheduled run (2026-09-01).19
A dead security gate. An output-field allowlist existed in that same pipeline's code and looked, on paper, like a real control, until a review found it was never actually wired into the build, so it had blocked nothing, ever. Wiring it in for real and then enumerating the actual field set in production found 40 undeclared fields shipping, not the 37 a prior static inventory had expected. 37 were added to the declared list and now ship; 3 were escalated, deliberately left off the declared list, and blocked from shipping by that same now-enforced gate. An independent re-verification after the fix found 0 undeclared fields in production.19
A restore drill that ran the commands instead of reading the plan. Two prior security reviews, an architecture review, and an engineering-lead review had all signed off on a backup-restore procedure. None of them had actually executed it. A drill that did (running the restore and its post-verify step for real) found 2 live bugs no review had caught: the restore command failed against the tool's own scoped backups, and the post-verify step checked for a JSON field that doesn't exist in that CLI's real output, meaning every successful real restore would have appeared to fail and triggered a self-rollback.20
A fourth data point is worth naming honestly rather than folding into the same category: a 2-day CI outage, caused by a workflow file silently corrupted by an inline script, went undetected for those 2 days before being found and fixed ahead of the next scheduled run. That is a control gap that got closed before it caused harm (real, and worth recording), but it is not a catch in the same sense as the three above, since nothing was actively checking for it. Call it what it is.21
Seven weeks, five concurrent programs, one human operator: what this case study produced.
Everything in this section describes one person's real, running use of this model across five concurrent programs, over roughly seven weeks: the measured case-study window runs 2026-07-04 through 2026-08-27. It is a case study, not a controlled benchmark: there is no control group, no counterfactual "same work without the hierarchy," and the sample is one human operator's own repositories. Read the numbers as evidence that the model held up under real, concurrent, cross-program work, not as a general throughput claim, and not as a claim about capacity: five is what this human operator ran during this window, not an asserted ceiling on how many programs one person can supervise.
Token economics, measured in one session: individual subagent dispatches consumed between 19,000 and 105,000 tokens each while returning summaries of 300 to 500 words, observed output length, against a definition that asks for under 300, sitting on top of a boundary the platform enforces regardless: the parent receives only the subagent's final message, never the tool calls and file reads underneath it. That boundary is the model's real cost control. In that same session, roughly 190,000 tokens went to measurable waste across four causes: agents replying that they'd "report back" and then terminating, forcing a full re-dispatch; a retry dispatched before the original run was confirmed dead, producing two contradictory reports that then had to be reconciled; a dispatch that read a file and then refused the work on scope grounds; and an agent superseded mid-run by information the human supplied directly. None of that waste came from rigor, and rigor is not what got cut in response to it: in the same session, re-dispatching to verify a claimed bug location and to resolve a contradiction between two reports caught 5 defects that were live in production. A cheap wrong answer, in this model, is the most expensive output there is, because it can propagate into a commit or a deploy before anyone catches it.8
Commit throughput, measured across 7 repositories spanning the 5 programs (3 of the 7 repositories belong to the marketplace-apps program alone), by git log, filtered to the canonical commit identity (support@sullinslabs.com), over the 14-day window 2026-08-14 through 2026-08-27 inclusive:
The same window shows 192 commits from all authors and identities across those repositories, including addresses deprecated earlier in each repository's history: the gap between 130 and 192 is stated plainly here rather than left implicit; it reflects the same operator committing under deprecated identities inside the same window, plus 2 commits from an automated pipeline identity, not other contributors. And 130 commits over 14 days is not a steady 9.3-per-day rate: that arithmetic mean describes a period that was genuinely bursty, not smooth. The home-automation system alone accounts for 60 of the 130, 46%, concentrated in one intense multi-day dashboard migration, not spread evenly across the window. Presenting this as a smooth cadence would misdescribe what actually happened.16
Breadth, in the same window, across programs run concurrently by one human operator: the website rebuild; data-integrity and licensing remediation on the relocation-data app; listing preparation, access-control hardening, and the close-out of one exploratory spike, all across the marketplace apps; a dashboard migration on the home-automation system (the largest single body of work across the full case-study window, 25 or more dashboard versions produced over the full seven weeks, 2026-07-04 through 2026-08-27, not just the 14-day window above) alongside a live SSH-based apply pipeline; this operating-model documentation itself; and a first cross-program security review that landed same-day fixes on 2026-08-20 across 5 of the 6 repositories that existed that day (the home-automation system's own repository didn't exist yet; its history starts 2026-08-21, so it's excluded rather than counted as a miss). This was confirmed directly by running git log against all 7 of the case study's repositories under the canonical identity, filtered to that single date: the website, the relocation-data app, internal ops, and two of the three marketplace-apps repositories each carried at least one same-day fix commit; the third marketplace-apps repository had none that day.
Roster, restated with its caveat from Section 01: 1 chief-of-staff definition, 5 program-manager definitions, 17 specialist definitions (spanning the chief of staff's own staff, the shared cross-functional tier, and program-scoped specialists), on disk as of this writing: a count of files, not a confirmed count of what's currently dispatchable. The count itself never drifted; what drifted was dispatchability, for five days.17
A shared vocabulary is optional, and it still lowers the cost of delegating.
Everything above this section is mechanism: allowlists, approval gates, deliverable formats. None of it requires a theme. But running a hierarchy solo, every day, for months, surfaces a smaller and more human problem that pure mechanism doesn't solve: re-explaining scope and authority every time you address a different tier gets tedious, and tedium is exactly the kind of friction that erodes discipline over a long enough stretch. One way to lower that friction (not the only way, and not a load-bearing part of the model described in Sections 01 through 06) is to give the hierarchy a shared vocabulary that implies scope and authority on its own, so it doesn't have to be re-stated.
Take an illustrative example, chosen because it's widely recognizable and carries no ambiguity about scope: a rank-and-role structure like Star Trek's. A first officer reporting to a captain implies a working relationship (who briefs whom, who has standing authority to act, who needs sign-off) without a sentence of explanation, because the audience already knows the shape of that relationship from decades of shared reference. Address a chief-of-staff-equivalent role by an executive-officer-style title, or theme a set of program dashboards around a shared fictional frame, and the effect isn't cosmetic: a returning human operator, some weeks and several unrelated programs later, gets scope and authority back in the time it takes to read a title, rather than the much longer stretch it takes to reconstruct "wait, what can this one actually do." That is a real, if modest, saving in cognitive reload: a solo operator has no colleague to ask "remind me what this is scoped to," so anything that shortcuts self-orientation compounds over a long-running setup the way any small daily friction does.
The stronger claim underneath the theme is about how a solo setup feels to run, not just how fast it runs. A pile of independently named scripts and agents reads as a pile of tools, each one evaluated on its own merits every time. A themed hierarchy, even a loosely applied one, reads as a crew being directed: an organization with roles, not a junk drawer of processes. That framing makes it easier to hold the discipline in Sections 02 and 04 (approval gates, adversarial review) as standing operating procedure rather than as friction to route around when busy. Nothing here is a claim about performance, and nothing in this section changes what's actually enforced by the allowlist in Section 01. It's a claim about sustainability: a solo operator supervising real, mutating work for months benefits from something that makes the daily act of delegating feel less like operating machinery and more like directing people, even when there aren't any. Pick a theme, or don't: this is the one part of the model that's entirely taste.
The model has edges, and naming them is part of running it honestly.
Three mechanically different events share the single word "restart" inside this model, and conflating them is one of the more expensive mistakes in running it day to day. First: a brand-new agent definition file (a new program manager, a new specialist) hot-registers within seconds of being written, outside a small number of documented exceptions; no restart needed, though dispatching it before confirming it's registered is its own small failure mode. Creating the file is half the job: until the new name is added to the chief of staff's allowlist and the process restarted, the agent is registered and unreachable at the same time. That combination (a control working correctly, producing a silent failure) is what cost this model five days in August. Second: editing the chief of staff's own dispatch allowlist behaves differently, observed repeatedly to require a new process, not just a new conversation. Current documentation describes agent-file edits hot-reloading and doesn't address the running main-thread agent's own grants specifically, so treat this as verified against behavior, not against documentation. Third: adding an MCP server, several agents in this model use home-automation and browser-automation integrations over MCP, has, in this human operator's experience, also needed a full restart; that is an observation about this human operator's own runs, not a documented platform guarantee, and it is stated here with that caveat rather than overstated as one. For the two cases that do need a new process, quitting the CLI and relaunching works, and so does resuming from a fresh shell, because both re-read the definition from disk; starting a new conversation inside the process that's already running does not. "Restart" is commonly read as "start a new chat," and that reading is the one that fails. None of this is a flaw in the model; it's a real mechanical property of the platform it runs on, and treating "restart" as one undifferentiated word instead of three specific events is what causes the confusion, not the underlying behavior itself.9
Cost grows with session length in a way that rewards discipline more than raw capability: the chief of staff's context accumulates every summary, brief and file read for the life of the session, and the whole history is resent each turn: billed at a reduced cached rate while the prefix stays intact, but re-billed in full the moment anything earlier in it changes. Compaction eventually caps the growth by summarizing the conversation away, which is itself a cost and a fidelity loss. A long session doing the same work as a short one is the more expensive of the two. Memory, not context, is what makes ending a session cheap: state persists on disk between sessions; conversation history does not need to. A session that has wandered across several unrelated programs is a signal to close it and start fresh, not a reason to push through.8
And the same discipline this paper spends Section 05 describing applies reflexively to the paper itself. The efficacy claims in Section 06 are one human operator's seven weeks, not a benchmark with a control arm: stated plainly there and restated here on purpose. The roster in Sections 01 and 06 counts files on disk, not confirmed dispatchability, and that gap has been real before: five days of it, in this model's own recent history. A model built around verifying claims against behavior should not get a pass on its own numbers, and this paper doesn't ask for one.
Sources
- Sullins Labs internal guide:
chief-of-staff-workplace-setup-guide.md(2nd edition), Section 0, "The model in one picture," lines 28–73. Hierarchy structure and memory-file layout, Section 01. - Same guide, Section 0b, "The operating model, human in the RIGHT loop (HITRL)," lines 76–153. The propose/verify/execute chain and the approval-vs-operation distinction, Section 02.
- Same guide, Section 0c, "Briefing the human, POTUS style," lines 157–186. Decision-first reporting format and the fenced-shell-block placeholder warning, Section 02.
- Same guide, Section 0d, "Approval batching, flight plans," lines 189–208. Flight-plan approvals, decision batching, and the gates that never batch, Section 02.
- Same guide, Section 0e, "Adversarial review batches," lines 211–231. The "iterate until only nits remain" exit criterion and consolidated-batch return rule, Section 04.
- Same guide, Section 0f, "Deliverable format," lines 234–255. The five deliverable-format rules, Section 03.
- Same guide, Section 1, "What's load-bearing versus what's taste," lines 257–291. The allowlist and missing Bash/Grep/Glob as the model's actual enforcement mechanisms, Section 01.
- Same guide, Section 1b, "Token economics: why the model is shaped this way," lines 293–365. Per-dispatch token ranges, measured waste, and the verification counter-example, Sections 06 and 08.
- Same guide, Section 4b, "What hot-registers and what needs a restart," lines 525–593. The three distinct restart events, Section 08.
- Same guide, Section 5, "The four hard-won rules," lines 596–743. Authority limits, reporting discipline, and the incidents that produced each rule, Sections 02 and 04.
- Same guide, Section 6b, "The cross-functional specialist tier (advisory)," lines 842–904. The shared advisory tier and its dispatch criteria, Sections 01 and 04.
- Same guide, Section 6c, "The role-request workflow (PGM-originated)," lines 906–939. The role-request pipeline and the best-effort-while-pending rule, Section 04.
- Same guide, Section 6d, "Agent definition authority," lines 942–965. Authorship limits on agent definition files, Section 04.
- Same guide, Section 12a, "Controls vs. claims," lines 1417–1461. The controls-vs-claims discipline and its five failure shapes, Section 05.
- Same guide, Section 13, "Worked example: good dispatch brief vs. bad one," lines 1498–1555. Source for the dispatch-brief comparison referenced in Section 03.
- Git commit history (
git log), 7 repositories spanning the 5 programs (the website, the relocation-data app, the marketplace apps across 3 repositories, the home-automation system, internal ops), filtered to authorsupport@sullinslabs.comand separately to all authors and identities, 2026-08-14 through 2026-08-27 inclusive. Commit-throughput figures, Section 06. ~/.claude/agents/directory listing (chief-of-staff.md;pgms/;specialists/), counted as of this draft. Roster figures, Sections 01 and 06.- Internal agent memory:
agent-memory/chief-of-staff/project_agent_roster.md, section "The bug that hid all of this," andagent-memory/chief-of-staff/project_security_review_2026_08_20.md, section "Specialist reachability." Source for the five-day allowlist gap, Section 01. - Repository history: the relocation-data app's ETL pipeline, and the associated output-field allowlist fix, cited by description (identified by filename, never by commit SHA, per this paper's own house rule, Section 03), confirmed by reading the pipeline's own config and release records for the licensing finding and by tracing the build's actual call paths for the dead-gate finding, not by trusting either control's presence on paper. Licensing-review and dead-code-gate findings, Section 05.
- Repository history: the home-automation system's backup-restore drill records, confirmed by direct execution of the restore command and its post-verify step against a real backup, not by review of the written procedure alone. Restore-drill findings, Section 05.
- Repository history: CI workflow-file corruption and fix, 2026-08-20 to 2026-08-22, confirmed against the workflow file's own commit and outage timeline. Control-gap example, Section 05.