Build & Review Automation
Agent-run builds, checked by a person
I use AI agents for design and build work. I write the brief, decide what counts as done, and review what comes back. This case follows one run from brief to revision.
The run, in short
The run behind the Favente before/after pair: two headline numbers that didn’t match, traced by an agent, decided by me.
1 · Me
The brief
Trace 1.9M and 1.8M to the exact sample inputs and the calculation code. Explain them, recapture both, or crop the pair.
2 · Agent
The trace
Checked which sample data and setup made each capture, then followed each number to the code that computes it.
3 · Agent
The evidence
Same data, a different calculation: the lifetime sum of submitted counts (1,938,000) before, the views actually observed (1,838,120) after.
4 · Me
The decision
The explanation met my rule, so the pair stays, with a plain caption.
5 · Result
The revision
One sentence beside the pair on the Favente case says why the numbers differ.
- Role
- Workflow design & review
- Timeframe
- Oct 2026 – Present
- Team
- Solo, with AI agents in Agent Orchestrator
- Tools / stack
- Agent Orchestrator, Claude Code, Playwright, axe-core, Git
- Status
- In use on this portfolio · the GitHub handoff is in development
The problem
AI agents can produce a lot of work quickly. The hard part is deciding what to ask for and checking what comes back.
I built this portfolio that way. Every change started as a brief I wrote, ran as an AI agent on its own branch, and came back with screenshots, recordings and test results. Nothing moved on, and nothing was published, until I had looked at it.
One run, from brief to revision
The brief: two numbers that did not match
The Favente before/after pair showed 1.9M on the old screen and 1.8M on the new one, a smaller number on the improved side. I wasn’t going to keep a comparison I couldn’t explain, so my brief asked the agent to trace both numbers to the exact sample data and to the code that calculates them, then do one of three things: explain them with a plain caption beside the pair, recapture both if the inputs differed, or crop the pair down to the design decision if it stayed unclear.
Evidence · My brief, 6 Nov 2026
What the agent returned: same data, a different calculation
Both captures used the same sample data and the same capture setup. The old screen showed the lifetime sum of creator-submitted counts on approved claims (1,938,000). The new one shows only views actually observed since readings began: 1,838,120 across three connected accounts, reproduced from the sample data. The change came from the update that moved the headline to an honest metric, not from the aggregation fix.
Evidence · The agent’s trace note, with file paths, line numbers and the reproduced sum
The first number: 1.9M (synthetic data) 
The second number: 1.8M (synthetic data). Crops of the two headlines, not a design comparison. What I decided
I set the rule before any work started: explain it, recapture it or crop it, and any explanation had to point to files and lines. The trace met the first condition, so the pair stays. I approved the caption as written, and it now sits beside the pair on the Favente case.
The revision: a plain caption beside the pair
The pair now carries one sentence that says why the numbers differ, so a reader does not have to guess. The pair and its caption live on the Favente case, under “A track record that never shows missing as zero”.
What the tools automated
- Agent Orchestrator: one AI agent per brief, each on its own branch and worktree, reporting back when done.
- Captures of the real builds with synthetic data only (Playwright), stills and real-time recordings.
- Checks on every pass: axe-core accessibility audits, a framing check for the star formations, frame timing, and a fresh-checkout crawl for missing files.
What stayed with me
The brief and its rules, every visual judgement, and the approval of anything public: copy, media, wording from my résumé, and publishing. The agents report their results; they don’t approve their own work, and nothing is pushed or deployed without my yes.
In development: handing tasks from GitHub to Agent Orchestrator
The idea
A private GitHub issue queue for tasks I’ve approved, and a small receiver on my Mac that hands each one to Agent Orchestrator. A task runs only after I approve that exact text on GitHub; anything edited or unapproved is refused. The agent reports back, and only I can mark the work verified.
What has been demonstrated
The receiver’s logic passes its 128 tests on my Mac. Two supervised probes passed: the first showed the report path and that a session can be stopped; the second showed that stopping a session ends a command that is still running. In dry runs the receiver turned away an approval that didn’t come from me and a task whose text changed after approval.
The first live run, 5 November
According to the receiver’s log, it ran live on my Mac for about ten minutes against one test mission. It started a first session; that session’s task report and cycle report were validated, and the session was ended. It then started a second session. When the STOP file was set, it sent a stop and held, and it was still holding when the log ends. The run stopped there, before its planned cycles were complete.
Where it stops for a person
Approving a task, checking the result and marking it verified are my steps on GitHub. A STOP file halts the receiver immediately; it’s in place now, so nothing is running. The full supervised test over several cycles still needs my go-ahead, with me watching.