Business Analyst
HaikuReads a transcript, email or screenshot and lists every ask, decision, bug, commitment and open question, with exact words.
Never touches the network, guesses a speaker’s name or merges look-alike items.
Every task is a graph of agents, with a person at every gate.
A prototype software agency where every role but mine is held by an AI agent.
Pressing a button on a card launches a graph: an orchestrator leads the job and hands each subtask to a role agent with its own tools and guardrails. Permissions, not instructions, set what each agent can touch. I approve every price, every merge to main, every production deploy and every email; the agents do everything in between.
5
orchestrators, each leading one kind of job
9
role agents: five on Haiku, four on Sonnet
2
blind validators that must both pass every release
The whole pipeline
11 stagesIt’s built around a real delivery problem: two legacy systems, a desktop CRM and a pair of web apps, sharing one production database with no staging copy. So the design question was never “what can an agent do?” but “what is each agent allowed to touch?”
A card moves through eleven stages. Each one is a separate job with a fresh context, and each has a gate before the next.
Understand
- IntakeAccount Manager logs every email and meeting on the cards it concerns. When unsure, it flags a duplicate rather than merging.
- Origin checkSupport Engineer. I accept or reject the verdict.
- EstimateSolutions Architect. The client approves the price.
Build
- PlanTechnical Lead. The plan file must exist on the card.
- ImplementTechnical Lead and role agents. Zero suite failures.
- Assemble releaseTechnical Lead. Never merges to main.
Validate
- AcceptanceQA Analyst, from the ask alone. Pass on every card.
- VerificationQA Analyst, by a different method. Pass on every card.
Ship
- Publish betaRelease Manager. I press the button.
- SoakMe. Only I can mark it complete.
- Promote stableRelease Manager. The final stage.
The nine role agents
Haiku · SonnetRole agents exist where a subtask needs its own tools or its own guardrails. Each is defined by one file that says what it must never do, and hooks enforce most of it. Each repository keeps its own copies, so the CRM’s engineer knows its legacy file encoding and the web engineer knows the deploy scripts.
Project Coordinator
HaikuTidies a job’s media: pulls video frames, drops duplicates, names files by card and takes an inventory.
Never works outside its job folder or decides what an image means.
Senior Software Engineer
SonnetInvestigates without changing anything that ships: reads code, queries production through a read-only account, benchmarks on a local copy.
Never edits source, builds or writes to production.
Software Engineer
SonnetImplements a plan on its assigned branch, builds, runs the tests that cover the change and commits.
Never runs the full suite, merges or publishes.
QA Analyst
SonnetReviews the finished diff blind, against the client’s words and the plan, and tries one edge case the tests miss.
Never reads the implementer’s reasoning or fixes what it finds.
Test Engineer
HaikuBuilds, confirms the binary contains the change, runs the UI suite in the foreground and reports the numbers.
Never edits anything or judges a failure.
Database Administrator
SonnetThe only agent that changes production, through one tool that rehearses first and records everything.
Can’t drop the main database: its account has no DROP privilege.
VM Probe
HaikuAnswers read-only questions about the Windows build VM: stuck tasks, disk space, build directories.
Never ends a task, kills a process or deletes anything.
VM Suite Watcher
HaikuRuns a long test suite and polls it cheaply until it finishes.
Never uses a streaming monitor, starts a second suite or builds.
One request, start to finish
01 — 0601Intake
Client email becomes a request.
Messages land in a shared inbox. Intake agents file each one by type, link it to a request, name an owning role and hand it off. Anything they can’t place stays marked unfiled until someone looks at it.
02Audit
A person checks every triage call.
Each request shows the client’s own words, why it was filed where it was, and the sources behind that decision. The reviewer marks it correct, wrong or unsure from the keyboard and moves on.
03Build
Requests break into tasks.
Tasks move from new to scheduled, in progress, in review and released. Each card carries its type, whether it’s estimated, and the release it shipped in.
04Track
One view of every request.
Work lists each request with its status, price, tasks, hours and messages. Group it by release to see what went out in each version, save the view, or export it.
05Control
One switch turns it all off.
Every agent has a charter, a settings file, a run history with cost, and a mailbox. Any agent can be paused. Power off refuses every agent call and kills any run in flight, and nothing turns itself back on.
06Bill
Invoices line up with releases.
Each invoice line names the release and change it pays for, with hours and amount. The list shows the effective hourly rate per invoice and flags the ones that fall below target.
The same desk, on a phone.
Mobile
Anatomy of a job
Graph 01Work starts as a card on a release board. Each button on the card (Triage, Estimate, Plan, Implement, Publish) queues a job, and each job is its own graph with a fresh context. This is the graph behind Implement.
- Human I press Implement on a card The job is queued with the card’s approved plan.
- Relay Launches a headless worker A fresh context for every job. It moves work between the board and workers and never analyses anything.
- Orchestrator · defined by the job brief Technical Lead Directs the engineer, the tester and the validator, and decides when the full suite runs.
-
- Role agent · Sonnet Software Engineer Builds the plan step by step on its own branch, with the tests that cover each step. Never merges, publishes or adds a production write.
- Role agent · Haiku Test Engineer Builds, confirms the binary really contains the change, runs the UI suite and reports the numbers. Never edits, or judges whether a failure matters.
- Role agent · Sonnet QA Analyst Checks the screen captures against the client’s own words, measuring in pixels. Never reads the implementer’s reasoning.
- Role agent · Haiku VM Suite Watcher Runs the 20 to 40 minute full suite once, at the end, and polls a progress file every 30 seconds. Never starts a second suite.
- Gate Zero failures, checked by the relay The relay checks the branch and the results itself rather than trusting the report. Any failure sets the card to blocked, with the reason, and it comes back to me instead of retrying silently.
Two validators who never meet
Graph 02Nothing reaches users until two validators have passed it. They use different methods and never see each other’s work, so one can’t talk the other into a pass.
- Orchestrator Technical Lead assembles the release Merges every ready card into a release branch one at a time, bumps the version, builds and runs the full suite. It never merges to main.
-
- Validator A · Sonnet Acceptance Works only from the client’s original words: reproduces each reported problem the way the client would, and records it. Stitches a walkthrough video for the release email.
- Validator B · Sonnet Verification Confirms each change survived the merge, compares it with the ask and the plan, runs its tests alone and tries an edge case the implementer missed.
- Gate Both pass on every card Then I press Publish.
- Orchestrator Release Manager publishes to beta Merges to main, tags, and publishes to the beta update channel.
- Human Beta users run it; I mark it complete A hook stops any agent from marking a release complete. Only then does the Release Manager promote it to every user.
The graph decides who pays
Graph 03Graphs branch. When a bug comes in, an origin check decides whether our own change introduced it. That answer routes the card down one of two paths.
- Orchestrator Technical Support Engineer Traces the failing procedure through git history and against a snapshot of the original source, condition by condition.
- Gate I accept or reject the verdict “Inconclusive” is an accepted answer.
-
- Our change Warranty Fixed at no charge, and goes straight to Plan.
- Older bug or new feature Solutions Architect estimates Checks for related cards, writes a self-contained plan and prices it against the nearest past fixed-price task. The client approves the price.
- Orchestrator Technical Lead plans Writes the design, the steps, the tests that prove each step and the screen states to capture, then hands off to Graph 01.
Design principles
Made impossible, not discouragedGuardrails come from permissions.
The Database Administrator connects with an account that lacks DROP, so the database refuses a mistaken drop whatever the model decides. Investigators get a read-only account. A hook stops every agent reading credentials: the tools use them, the models never see them.
Validation is blind.
The QA Analyst ignores the implementer’s report and commit reasoning, even when a brief includes them. Its only anchor is what the client asked for.
Cheap models do mechanical work.
Haiku extracts, tidies, runs suites and polls. Sonnet plans, implements and reviews. Opus is allowed only when an orchestrator writes a one-line justification, such as a data-loss risk.
Every agent does one job.
Engineers report a second bug rather than fixing it. Suite runners never edit. The relay never analyses, so all real work lands in the right role and in the ledger.
Every run is costed.
Each session is a ledger row with its role, model, tokens and cost. A card’s timeline gets one entry per agent run, so what people said and what agents did read side by side.
One lesson cost real money.
Watching a suite with an event-streaming monitor woke the agent on every progress line and made it re-read its transcript, about 60k tokens per event. Three suites watched that way used around 13 million tokens. A hook now blocks the pattern, and a Haiku watcher polls instead.