The problem
Delegating small work is easy. Judging it is not.
My business site was on Squarespace, which has no content API. Every update was me, in a browser, at night. The backlog was not hard work, it was small work that never made the top of a list: a project write-up, a stale bio, a talk I gave in March that never got a page.
I could have hired that out. What I wanted was to find out whether I could delegate it to agents instead, on my own systems, at a cost I would actually pay.
The first attempt failed in a way worth reporting. I pointed a coding agent at the site and asked it to make changes. It made them. Some were right. I had no way to tell which, so I read every diff, which is the same work as doing it myself plus the reading. The agent was not the bottleneck. The absence of anything that could judge its output was.
What I built
A portable crew that works any repository, and a gate that decides what ships.
Plasmid is a Python repository that runs outside every repository it maintains. It lives on scheduled cloud infrastructure, scaling to zero between runs and triggered by a work queue rather than by a cron for each agent, so adding an eleventh role is a config change, not new infrastructure.
Ten agents, specialized by the kind of change they make rather than the technology they touch, because change class is what determines which tests have to pass. Roles group into Plan, which routes work and holds the roster; Build, which writes the change; and Guard, which decides whether it ships. A Builder claims exactly one task and works it to a pull request. A Reviewer with a fresh context, no memory of the reasoning, and no authorship reads the diff and can block it. Triage owns anything red and may not write a fix before it has written a failing test. A Warden watches spend and holds the kill switch.
The crew’s craft and each repository’s local rules are separate things, kept in separate places. The ten role skills travel with the crew, because they describe how a job is done regardless of where. Each repository ships its own skills at a shared path that every major coding agent already scans, and those describe what that particular site expects: how a heading is punctuated, which files are off limits, what the gate chain looks like today. When Plasmid opens a workspace it reads those repository skills as freely as its own, so a rule I wrote yesterday is in effect this morning without a release.
How it works
One task, one role, a cold start, and a gate the fleet cannot rewrite.
The loop is bounded and cold-started. Every run starts with an empty context window, opens a fresh workspace, and does exactly one thing. One task, one role, no memory of the previous run. The role that gets assigned inherits nothing about how the last similar task went. This is the same reason the coordinator on the wedding side of this portfolio starts every run from a briefing rather than a conversation: if a run cannot be reconstructed from what is written down, what is written down is wrong, and that shows up immediately rather than three weeks later.
The gate is deterministic and enforced by the repository, not by prompt. Eleven deterministic checks, including a browser test suite that runs against a real per-pull-request preview deployment rather than a local dev server, an accessibility pass, and a visual diff. Every check is a script. No agent can merge, loosen a threshold, edit the CI workflow, or regenerate its own visual baselines, and those denials are enforced by repository rules rather than by asking nicely in a prompt. Zero self-merges is a property of the substrate, not a policy the fleet agrees to follow.
Memory is files in git. No vector database, no graph service. Agents read a run journal, a decision log, and the commit history, which are auditable, revertable, and free. The interface a person uses to review the fleet is a directory listing.
What changed
Three surprises that changed the build.
Most of what I had specified as agents should be scripts. My first roster had an agent that monitored for package releases. A dependency bot already does that deterministically and for nothing. The valuable agent is the one that wakes up when the bot’s pull request is red and works out why. Cutting the roster and moving several jobs off model-driven work took a substantial slice off the projected monthly cost.
Green tests are not a safety control. In March 2026 a compromised version of a widely used npm package reached production in under an hour across hundreds of repositories, most of them merged by bots with passing CI. What stops that is a waiting period before a new package version is eligible, not a test suite. It is the least interesting line in my config and the one doing the most work.
One dependency upgrade would have broken everything quietly.
TypeScript 7 does not support .astro files, and the type checker
reports “TypeScript is not installed” rather than failing loudly. A
naive autonomous upgrade passes CI and leaves you with a dead
toolchain. That single finding is why the plan starts with a phase
that writes no agent code at all.
What I’d do differently
Two orderings I would flip if I started again.
I designed the whole organization before proving one agent could open one acceptable pull request. Ten role definitions, a memory architecture, and a cost model all exist for a system whose first phase is a single agent on my laptop. The design was worth writing, and the order was wrong: the second phase should have been the first thing I built, and the roster should have followed from what that taught me.
I also spent real time evaluating four agent memory products before concluding that files in git were the answer. The company that invented the tiered-memory approach had already moved to git-backed files. I could have read that first and saved myself the survey.