We built an agent harness, a mini-version of Claude Tag (and with its name inspired by Stripe's Minions). A version that's not built for a company with thousands of engineers and millions in budget. We built it just for the sake of learning how to build a software factory.
You start an interaction in Slack: "make the app look modern," "change the header," or something that reaches into the backend like "add a merchant column to the recent transactions table." Then a few minutes later, the thing gets deployed to production following rigorous standards.
We believe on the thesis that software is about to show up in companies and places we never imagined, and those companies will need a responsible way to vibe-code. A small harness is the answer. It's Slack-first, it handles spec disambiguation, PR authoring, CI/CD, code review, and production deployment on its own. Nobody has to teach non-technical people about Claude Code, CLIs, or git.
Here's how it works:
A Slack message (e.g., "add a dark theme to the app") kicks things off.
Slack hands it to a Docker container running a terminal, the workspace where the coding agent lives. We fall back across Claude Code, Codex, and Kimi K2: If one runs out of credits or has an outage, the other two cover for it.
The agent runs OpenSpec, a lightweight spec-driven-development library. (Based on my experience using these SDD libraries in my job, SpecKit wins for greenfield and OpenSpec for brownfield, but OpenSpec's far lower token cost made the call for us.) It first turns the raw Slack message plus our guardrails, coding standards and destructive-op rules, into a clear spec, then applies that spec as code (runs
/opsx:proposeand/opsx:applyrespectively).
Guardrails in action
A PR is authored and then torn apart. LLMs are sycophantic, which makes them great at writing code and terrible at judging their own. So a second, adversarial reviewer agent grades the PR. Adversarial review works.
The reviewer agent uses DSPy to to optimize the reviewer against a hardcoded labeled dataset. That is, if this part of the architecture is extended, this harness can become a better reviewer as more examples of which PRs where approved/rejected are provided.
Ship or flag. If the reviewer approves, the PR merges and CI/CD deploys it to Fly. If not, it's flagged for a human. Guardrails block destructive operations throughout (no dropping SQL tables, no deletions). The Slack bot narrates every step until the PR is merged or handed off.
The guardrails
Both the writer and the reviewer share the same engineering constitution (Robustness Principle), so its safety rules are enforced twice. Once at write time, once at review time. The non-negotiable ones are about not letting an autonomous agent destroy data: no DROP TABLE/DROP DATABASE/TRUNCATE, no unconditional DELETE, no dropping columns or tables that hold data. Schema migrations must be additive and reversible (the agent is forbidden from running prisma migrate reset, db push - force-reset, or anything that wipes a database). On top of that: Never commit secrets, keep the change as small as the request allows, and if the app doesn't build or render, don't open or approve the PR. These are the difference between "an agent that helps" and "an agent that one day runs a DELETE with no WHERE."
Why this was built on Fly
Each terminal maps 1-to-1 to a Slack interaction and runs as an ephemeral Fly Machine that's created when the interaction starts and destroyed when it ends (flyctl machine run - rm). That keeps context clean between runs (LLMs get lost in the middle), isolates concurrent interactions from one another, sandboxes the untrusted code the agent executes, and scales to zero so you only pay per run.
We tried Vercel, Railway, FastAPI Cloud, and the like first. They can't do this. Serverless platforms are request-scoped functions with short timeouts and no real shell, but a coding agent run takes minutes and needs to run git, Docker builds, and flyctl. Container platforms (Railway, Render) happily run one long-lived container, but give you no API to spin up and tear down an isolated machine per interaction, so every concurrent request would share one box, with no clean isolation and no per-run lifecycle.
Fly Machines is the one primitive that fits: Disposable Firecracker microVMs you boot and kill on demand via an API. That is the ephemeral-per-interaction model. (Locally, the same shape runs as Docker sibling containers via the mounted Docker socket, which is also why you can't just drop it on a platform that doesn't hand you one.)
A friend of mine told me something like https://box.ascii.dev/ could work as well.
Why not just a Claude Code /loop or /schedule?
You could build a more basic version of such using these tools. However this architecture keeps execution and deployment rigurous, without relying that the person who prompts takes all of it into account.
Try it yourself
The repo is open source, with a two-tier on-ramp so you can go as deep as you want
Top comments (0)