A rough idea becomes a shipped pull request.

The loop

draft → refining → ready → in_progress → in_review → done

You write the task and refine it with the agent in a back-and-forth thread. Before it commits to an approach, it investigates: starting read-only, escalating only as far as the question needs (a throwaway sandbox experiment, or, if a repo allows it, a real branch and draft PR you can watch run), then reports back complexity, risks, and a recommended path, and waits. Only a person can tag a task ready. That tag is the actual consent to start building, never assumed. Once it’s ready, the agent implements on its own branch and opens a pull request. If CI comes back red, or a human leaves review feedback, the agent treats that as first-class work: it reproduces the failure, fixes it on the same branch, and replies with what changed. Merging is what moves a task to done. Nothing else does.

It builds itself

Most of what’s on this page, including this page, was built by the factory working on its own tracker.

Build-kind tasks that shipped as real, reviewed pull requests, and dogfood-kind tasks where the agent signs into its own deployed app and reports what it finds. This isn’t a demo environment: the loop above runs in production, against this project’s own repository, the same way it would run against yours.

What the agent decides

Two things about a task are decided by the agent, not assumed from a person’s first guess: whether the work is a build (it ships a pull request) or a dogfood (it drives a browser against a deployed app and files a findings report instead), and how much model capability the task actually needs. Both are classified once a task is marked ready, with a one-line reason posted to the thread. A person can set either by hand, and the agent will only push back, never silently overrule, if the spec clearly says otherwise.

That decision logic is itself checked in CI: a small suite of deterministic evaluations runs against a mock model on every change, so a change to how the agent decides has to pass before it ships.

What it costs

Every repo can set a per-task dollar budget. Cross it and dispatch pauses automatically, with a plain-language note on the task thread; a person has to resume it, and the next pause waits for the next multiple of the budget, not the first dollar after. Spend is tracked from the provider-reported dollar figures the model gateway returns, never estimated from token counts, and attributed down to which model ran which task. The full breakdown, by task, by kind, by model, lives on /costs.

Each repo can override this menu with its own vetted models. The agent only ever picks the tier, never the exact model.

A human still has to say yes

When the agent needs a decision only a person should make, merging a pull request, running something destructive, anything a repo’s config marks as gated, it stops and posts a structured card to the task thread instead of guessing. A click answers it. Each repo sets its own policy per tool, from never-ask to always-ask, and merging a pull request is always gated no matter how the rest is configured. A repo can also name exactly which people are allowed to answer.

What it writes down

Sessions that don’t lose the thread

Each task runs as one long-lived agent session, not a fresh conversation per message. Every comment you write is a turn that gets queued and answered in order, even if the agent is mid-reply when you send it. Sessions rotate cleanly when they need to, carrying a handoff summary forward; if one ever stalls, the factory notices and settles it on its own. And if a task’s session predates the agent’s own latest build, the task page says so, so nobody debugs against a stale version by accident.

Credentials never enter the sandbox

The agent’s sandbox never holds a real GitHub token, model API key, or app password. Requests that need one, cloning a repo, calling the model gateway, reaching a deployed app for QA, get the credential injected as a header at the network boundary on the way out, by the firewall, not by the agent. The agent can use a credential without ever being able to read it.

Skills, two tiers

Skills are how the agent learns a process or a stack’s conventions without it being hardcoded into the agent itself. The skills that shape how the agent behaves, how it refines a spec, investigates an approach, implements, reviews, are written in-house only; nothing that steers the agent’s judgment comes from a registry. Skills that carry a target repo’s stack knowledge, a framework’s conventions, an auth library’s setup, can come from a third-party registry, but only through review: pinned to an exact version, installed with a person’s explicit approval, and committed to the repo so the text that runs is the text that was reviewed. A given session only ever sees the skills relevant to the task in front of it, not the whole library at once.

Some of the stack-knowledge skills behind this project’s own design work, not judgment over what to build, but craft in how it looks and moves, came from outside maintainers we’re glad to credit: mattpocock/skills, emilkowalski/skill, and Leonxlnx/taste-skill. Each is reviewed and pinned like any other third-party skill, per the policy above.

Two ways to write the code

By default, the agent writes code itself, directly in its sandbox, with its own file and shell tools. That needs no setup. A repo can opt into a second engine instead: a headless Claude Code process running inside the same sandbox, with an explicit, narrow list of tools it’s allowed to use for that run. Either way, the model credential involved is injected at the network boundary, not handed to the process directly.

MCP access

Everything above is also reachable outside the browser. A bearer-key HTTP endpoint speaks the Model Context Protocol and exposes the factory’s own data, tasks, releases, the diary, to any MCP client, under the same reviewer rules that gate the web UI. The endpoint, the tool list, and how to mint a key are on /mcp.

Take over any task

The agent having a task doesn’t mean you can’t. Every active task’s page carries a copyable pickup prompt: the spec, the working branch, and how to close out. The agent pushes after every commit, so its branch is always there to fetch, and a pull request opened from your own machine binds back to the task by a single line in its body, whatever the branch is called. Status changes and approval answers work over MCP too, so taking over never requires the browser.