Would I Trust Agents to QA My Daily Driver?

TL;DR: Omarchy announced that ThePrimeagen is joining Omarchy Core to run “Agentic QA”: a swarm of agents that boots every release in a fresh VM and clicks through it like a person would. I run Omarchy on two machines and update within days of release, so this swarm is, in practice, my QA gate. My answer is yes, for what it’s built to catch: installer and update regressions across a platform matrix no human team could click through by hand. It won’t catch a behavior that works as designed but shouldn’t. And there’s one open question about the diagnose step’s permissions once this stops being a month-old experiment.

Why this matters to me specifically

I run Omarchy on two machines: an M1 MacBook Pro via Asahi, dual-booting macOS, and an x86_64 desktop dual-booting Windows 11. I install updates within days of release on both. Whatever QA sits between a release being cut and it landing on my machines is the testing those two machines get before I do.

The announcement, written by DHH on September 26, 2026, lays out why this needed to change. Omarchy is headed to x86, Apple hardware, Snapdragon, Nvidia, and Pi. DHH’s framing of the problem is blunt: “No human QA team could click through all of that for every release.” Count architectures times install paths times update paths and the arithmetic backs him up. A small core team either automates that matrix or ships releases nobody fully verified.

The tool Prime built for this, called Oligarchy, has been in the works for about a month according to the announcement; the repo was created August 28, 2026. It boots Omarchy in QEMU virtual machines and drives them the way a person would: keystrokes, mouse movement, screenshots, then a record of whether things did what they were supposed to. Each test is a ticket that boots from a freshly minted disk, and a fleet of automation clients running on DigitalOcean Droplets picks up the work and reports back. The stated goal, per the announcement, is to turn Oligarchy “from a fun experiment into a routine part of how we build, test, and ship Omarchy.”

What does agentic QA catch?

It catches the class of regression a person testing by hand would catch: the installer breaking partway through, an update leaving the system in a state it wasn’t supposed to be in, a keybinding that stopped firing, a menu that stopped opening. On a clean disk, per platform, every release.

That’s the category my own first M1 install hit. The install failed on aquamarine, and I downgraded to an older build from the local pacman cache to get moving, as I wrote up in the Asahi install post. It wasn’t an Apple problem. A dependency moved faster than the installer consuming it, which happens on x86 too, and that install ran on the community omarchy-mac installer rather than an official release. I’m not claiming Oligarchy would have caught it; I have no evidence either way. A fresh-disk install on every platform, every release, is built to surface that kind of break.

The design behind it, from the repo at commit 378a1982, separates two kinds of agent. A developing agent changes code. A driving agent does something narrower: it uses ./client to drive a guest and ./ctrl to record the result for a task given in Linear. “It never reads or changes code.”

The driving agent’s entire toolset, per client.md, is a CLI: reserve, start, and stop a guest; take a screenshot; read the serial console; send keystrokes; move, click, drag, and scroll the mouse; start and end an intent; save the result. That’s the same surface a QA tester has: a screen and input devices. And the harness enforces it rather than trusting the model to comply. For a drive, Oligarchy runs its own loop, and per command.ts each model reply is one tool call, a client action or Done. Only the diagnose step, below, runs a general-purpose agent.

What can’t agentic QA catch?

Anything working as designed. A test passes when the thing being tested did what it was supposed to, and someone defines what it was supposed to do in a Linear ticket before the swarm runs. Behavior that’s intentional, even when the intention itself is the risk, reads as green on every run, because green is what it’s built to say.

I’ve made this argument about Omarchy before: the default agent launcher skips approval prompts for most agents, by design. Agentic QA will report that behavior as correct on every release, because it is correct relative to the spec someone wrote. Whether that’s the right default for a security-conscious install is a separate question, one functional QA has no mechanism to ask. Security properties, privacy defaults, and whether a default should exist at all need their own tickets, written by a human who’s thinking about something other than whether the menu opened.

The security read of the harness itself

Judged as infrastructure that now sits between a release and my machines, Oligarchy holds up on its own terms. The driving agent’s blast radius is capped by design: keyboard, mouse, and screenshots, enforced by the harness loop rather than left to the model. Every test boots from a freshly minted disk, so no guest state carries from one run into the next. Results land in a review queue: the flow documented in MUST_FIX.MD runs Linear ticket → job → QEMU guest → driver → result → a Linear status of Needs Review.

The repo also writes down its own weak points. That same file maps 16 named failure points in the pipeline, things like a server dying mid-claim and leaving a running row with no owner, or a QEMU guest dying without the session state getting reconciled. NEED_FIXING.md shows 1334 unit tests green and lists further fixes by impact, including that a failed drive currently can’t be rerun from the board.

The one open question sits in the diagnose step, the only part of the test pipeline that runs a general-purpose agent. Per opencode.ts, it runs OpenCode headless with --auto and sets two permissions that default to ask, external_directory and doom_loop, to allow for every session. The comment gives the reason: “A headless run has nobody to answer a permission prompt.” It’s specific, too. --auto covers the root session but a subagent’s prompt deadlocks the run, the two grants exist for a screenshot read outside the working directory and a screenshot call repeated while a guest boots, and explicit denies still apply.

For a month-old experiment that’s a sound call, and it’s the same --auto flag Omarchy’s own launcher passes to OpenCode. An unattended run gets either a smaller blast radius or a human in the loop, the tradeoff behind when to trust an agent. Here there’s no human, so the blast radius is what to look at. Per GOING_LIVE.md, the automation client, where the diagnose step runs, holds an OPENROUTER_API_KEY and a DATABASE_URL.

So the question for whoever scopes this next: as Oligarchy becomes a routine part of shipping Omarchy, does the external_directory grant narrow to the screenshot path it exists for, and does the diagnose run get a sandbox away from the client’s credentials? Both are cheap to decide while the pipeline is a month old.

What I’d want in release notes before I update

Given that I take these updates within days, what I want before I update is a record of what the swarm did. Three lines would cover it: which platforms the swarm ran on for this release, which tickets passed or failed, and which checks, if any, a human reviewed rather than the swarm alone. That’s the patch-cadence gap from the SOC 2 laptop post moved upstream: omarchy update hands an auditor nothing, and a release note naming what the swarm ran would be the first artifact in that chain. Trust widens as it’s earned, the argument in trust is the operating system, and a three-line record is how a release earns it.

Questions people search for

Is Omarchy’s agentic QA a security feature or a testing feature? Testing. It verifies that Omarchy behaves the way its own spec says it should, across the platforms it tests. It has no mechanism to ask whether that spec is the safe default; that’s a separate, human question.

Does Prime’s Oligarchy read or modify Omarchy’s source code? The driving agent doesn’t. Its documentation states “It never reads or changes code,” and the harness limits each model reply to one tool call from a screenshot, keystroke, and mouse CLI inside a VM. The diagnose step is different: it runs OpenCode, a general-purpose agent, headless.

The verdict

Yes, I’d trust it for what it’s built to catch. A swarm that boots a fresh VM per platform and clicks through the real install and update path is a stronger gate than any human team clicking through that same matrix by hand, and the harness has a capped blast radius and its own list of known weak points on the record. What it can’t do is decide whether a default that works as intended is the right default. That’s still on people who read the repo and write the safety posts. The one thing worth watching as this goes from experiment to routine is whether the diagnose step’s auto-allowed permissions and credentials get scoped down once the experiment label comes off.

If you’re weighing questions like this one for your own stack, what an automated gate proves versus what still needs a human, that’s the kind of scoping conversation I take on for AI-first teams.

Read this next: the AGENTS.md source read for how Omarchy’s own agent config reads line by line, or DHH’s Rails World keynote for where he laid out Omarchy’s progress on stage before this announcement. More in the Omarchy hub.