Note · how every request gets caught, vetted, and built
The Machines Behind Automated Triage and Build
Every bug, feature request, and idea, from a customer or from someone on our own team, lands in the same queue. For most of them, triage and build happen automatically from there, all day, without anyone watching it happen. That runs on two dedicated machines that do nothing else.
Our last note covers the pipeline itself: what a request goes through, and the one thing that always stays a person’s call: shipping it. This one covers something narrower: where the pipeline’s automated steps actually run, and why we gave them two dedicated machines. The rule stays the same: neither machine ever holds a production credential. Dedicated hardware just makes it easier to enforce.
Two intake sources, one queue
A customer and someone on our own team file a request the exact same way, and that shared queue is where these machines pick up.
Our build process blueprint covers this in full: a request lands on one shared board regardless of who filed it, gets checked for duplicates, and is handed off, signed, to a pre-production queue every couple of minutes. That hand-off runs as part of our production deployment, upstream of the machines below, so they only see a request after that hand-off. The machines watch the queue itself, one stream with customer and internal requests mixed together, and work whatever is waiting.
What actually runs on the machines
For most requests, the whole path from triage to a committed, reviewed change happens here, unattended. Higher-risk requests still get a person, working from wherever they are.
- Assess the request: step 4 of the pipeline, same for every request. A Claude Code
/loopsession on Machine 1, wrapped in a launchd agent so macOS restarts it if it ever dies, polls the queue, reads the code a request would actually touch, risk-scores it, and sorts it onto one of two tracks below. Nothing here touches production, so it runs the moment a request arrives, with no one watching.
Fast track
- Step 5, plan review: Claude checks its own plan against the same criteria from step 4 and moves on.
- Step 6, build: writes the code, runs type-checks, lint, and tests, then stops.
- Step 7, code review: reviews its own build and commits automatically.
Careful track
- Step 5, plan review: stops and waits for a person. The plan itself is a Claude Artifact, shared org-wide on our Team plan so anyone can open it without SSHing in; a push notification (Remote Control) or a nudge from the reviewer’s own laptop session (cross-session messaging) is what actually gets their attention.
- Step 6, build: same as the fast track. Writes the code, runs type-checks, lint, and tests, then stops.
- Step 7, code review: stops again the same way, for a person’s independent review before committing.
- Release stays manual, and off these machines. Step 8, same for every request: a person pushes the reviewed branch and deploys by hand. It’s the one step that stays manual everywhere.
Put together: for most requests, the machines own the entire path from triage through a committed, reviewed change, start to finish, with no one watching. Higher-risk requests still get a person at whichever step the risk shows up, from wherever they are. Deploying it stays a person’s call, always, and never happens on these machines.
Why dedicated hardware
Claude Code can already run on a schedule without local hardware at all. We looked at both alternatives before buying anything, and neither replaces this specific job.
| Option | Where it executes | Best for |
|---|---|---|
| Dedicated machines what we run | Our own hardware, our own network. Nothing new sits behind anyone’s infrastructure that wasn’t already true on a laptop. | A queue that needs checking every couple of minutes, and full control over sandboxing and network access. |
| Cloud-scheduled runs | Managed cloud infrastructure. No local files, nothing behind our own network beyond an explicit allowlist. | Read-only, low-stakes checks. Also runs at most once an hour, which is too slow for a queue we want checked every couple of minutes. |
| Managed execution, self-hosted sandbox | Orchestration hosted remotely; the actual code, filesystem, and network access stay inside infrastructure we control. | A future where this needs to scale past what two machines can absorb, or a formal isolation requirement neither of the other two options meets. |
That third row is worth revisiting later. It’s the right answer if the queue ever outgrows two machines. Today it would add orchestration overhead around a job our existing commands already do.
Why two
- Machine 1 runs the pipeline: the standing session against the intake queue, assessing and building requests as described above.
- Machine 2 runs everything else that’s scheduled. We already run other recurring, unattended Claude Code work outside this pipeline, such as the daily check described in catching stale engineering notes. Giving those a dedicated home means they never compete for whichever machine is free, and either box can absorb the other’s job by hand during a reboot or an OS update.
Operating discipline
An unattended machine doesn’t get the benefit of someone sitting in front of it to catch a bad prompt. So it runs under tighter defaults than anyone would set for themselves.
- Zero prod secrets No production credential, ever.
Same rule as the pipeline itself. See the full safeguard list in our build process blueprint. These machines only ever touch the isolated pre-production environment; there is nothing on them capable of writing to production even by mistake. - Centrally managed Team seats.
Each machine authenticates under its own seat on our team plan, and permissions get pushed to it centrally, the same as any other seat. - OS-level sandbox Sandboxed by default.
No one is watching this machine approve prompts, and a request’s own text is untrusted input, because a customer wrote it. So it runs inside OS-level sandboxing scoped to the repo checkout only, narrower than what any of us would allow ourselves on a laptop we’re sitting in front of, regardless of what a request’s text actually says. - Private network only Reachable on our private network only.
Both machines sit on our own Tailscale network so any of us can check on or nudge a stuck session. No port is ever forwarded to the open internet. - Self-healing Auto-restarting.
Sleep and display sleep are disabled, and the standing session is wrapped so it restarts itself if the process or the network drops, with no one needed to notice and reopen a terminal. - Bounded, transparent cost Same plan, same budget as everyone else.
Each machine draws from the team’s normal usage, on its own seat, with the same budget and pricing as an attended session, and the same usage log as any other session if we need to check what it spent.
Before you copy this
Worth knowing
- Base-spec hardware is plenty, since this workload is API calls and git operations.
- The whole setup is two machines and Tailscale. No new service to maintain.
Stays true on purpose
- Deploying to production is never one of these unattended steps, on the fast track or the careful track. That stays a person’s call, every time, off this hardware.
- If it can’t be described as “runs, then either continues on its own or waits for a person,” it doesn’t belong on these machines.
Read together with the build process blueprint, this is the whole path: how a request gets in, where it’s automatically vetted and built, and the one place a person always has to say yes.