Vercel eve Software Factory, Explained

Vercel Labs published the eve software factory template on 12 August 2026, and three days later it sits at 604 stars. The Vercel eve software factory is a template you deploy rather than a service you sign up for: you clone it, connect GitHub and Linear, label an issue factory, and an agent called Foreman comes back with a draft pull request that a different agent has already reviewed. Two decisions stay with you, which the project states plainly on its homepage: what to hand it, and whether the result ships.

Key Takeaways

• vercel-labs/eve-software-factory-template is MIT-licensed and sat at 604 stars on 15 August 2026, three days after its first commit. It deploys Foreman, an agent that turns a labelled issue into a reviewed draft PR.
• Work moves through four stations in fixed order: Classifier, Analyst, Implementer, Reviewer. The orchestrator routes between them and, per the pipeline docs, "never skips a station and never does a station's job itself."
• The Reviewer sees only the pushed branch, never the Implementer's reasoning. That makes the review a second opinion instead of a self-assessment.
• A "factory brain" carries repository-specific facts between runs, and because stations can't read it themselves, the orchestrator decides what each one gets told.
• Nothing merges by itself. Foreman opens drafts, and the merge button stays human.

What the Vercel eve software factory actually is

Strip the branding and you get a Next.js template with a Deploy with Vercel button, two connectors, and a Blob store. Deploying it asks for exactly one required variable, FACTORY_REPO, the owner/repo the factory works on; the build fails without it. Everything else has a default. The issue label that hands work to the factory is factory, the branch prefix it claims for its own PRs is factory/, and the bot's @mention name resolves from the GitHub connector when you leave it unset.

The word "factory" is doing real work here, and not in the sense that enterprise consultancies used it in 2015. An older software factory meant standardised tooling and templates so that human teams produced code more uniformly. Foreman's version means something narrower and more literal: a fixed line of stations, each one a separate agent with its own instructions, sandbox, and tools, with a work item moving down it in one direction.

The four stations, and the rule that keeps them apart

Every work item takes the same route. The Classifier triages first, running on what the docs call a fast, cheap model, working from the message alone with no repository checkout to consult. It returns a structured verdict covering type, priority, complexity, affected area, and whether the item is actionable at all. When something isn't actionable, Foreman goes back to the requester instead of building the wrong thing, which is a more useful behaviour than it sounds; most of the waste in an automated pipeline comes from confidently executing a bad ticket.

The Analyst turns the classification into a plan with acceptance criteria, and unlike the Classifier it works from a live checkout of your repository. The Implementer then executes that plan inside its own sandbox, verifies the result using your repo's own checks rather than some generic test harness, and pushes a branch.

Then comes the part worth stealing even if you never deploy this template. The Reviewer judges everything against the real diff, with evidence required for each verdict, and it sees only the pushed branch, never the Implementer's reasoning. An agent that reads its own justification before grading its own work will grade it generously. Withholding the reasoning turns the fourth station into an actual second opinion.

One line in the pipeline docs governs the whole arrangement: the orchestrator "never skips a station and never does a station's job itself." There's a companion rule for the Classifier that reads like it was written after someone got burned, which is that the orchestrator must never skip a station even for work that looks trivial, because the Classifier decides what's trivial, not the orchestrator.

The factory brain, and why stations can't read it

Between runs, Foreman keeps notes about your repository: build quirks, verification gotchas, review findings that keep recurring. The orchestrator loads this through a read_factory_brain call at the start of a run, alongside get_user_preferences for the requester's standing notes, things like a default base branch or how they like pull request descriptions structured.

The design decision underneath is that stations cannot read the brain themselves. The orchestrator has to weave the relevant facts into the messages it sends each station. That's more work to build and it constrains what a station can wander off and do, which is the point; a station that could read all accumulated repository memory would also be a station that could rationalise its way past any of it.

Memory like this only compounds if it outlives the process that wrote it, which is why the template leans on a Vercel Blob store rather than local disk. Agents you assemble yourself hit the same wall in a less convenient form, since a brain that lives on your machine forgets everything the moment that machine sleeps. MoClaw gives that state somewhere durable to sit, as a hosted cloud AI computer whose memory isn't tied to whichever laptop you happened to open.

Six ways work gets in

Foreman's entry points are more varied than the "label an issue" pitch suggests, and the range says something about where this fits in a real team's day:

• Label an issue factory and the pipeline runs unattended, posting progress as each station completes and ending with a draft PR linked back to the issue.
• @mention it on an issue or PR, which starts an interactive session. Only repo owners, members, and collaborators can trigger this.
• Delegate in Linear, where Agent Sessions run the same pipeline and report progress back inside Linear.
• Hand it a task locally through the dev TUI. Local runs are treated as untrusted, so anything touching GitHub waits for your approval.
• Red CI on a factory PR. Foreman diagnoses the failure and pushes a fix, and it only ever touches branches under its own prefix, never yours.
• When a human opens a pull request, Foreman posts one orienting comment for reviewers: a summary, explicitly not a review.

That last distinction is a small thing that a lot of PR bots get wrong. A summary helps a reviewer start; a machine-generated "review" on a human's PR mostly trains people to scroll past bot comments.

Where "keep humans on the judgment calls" actually lands

The claim is easy to make and hard to honour, so it's worth checking against the code's behaviour rather than the tagline. Foreman produces draft pull requests. It doesn't merge, it doesn't mark ready, and its CI self-repair is fenced to factory/ branches. Local TUI runs treat themselves as untrusted by default. Taken together, that's a system whose designers assumed their own agent would sometimes be wrong and built the blast radius accordingly.

What it doesn't do is reduce your reviewing load. You're now reviewing a diff written by an agent, annotated by another agent, on a ticket a third agent classified. The judgment call is genuinely still yours, and there will simply be more of them per week than there were before. Anyone adopting this should plan for review throughput to become the bottleneck, because that's the whole design.

There's a second constraint that has nothing to do with agent quality. This pipeline is useful in proportion to how much of it runs when you aren't watching, and the template solves that for itself by deploying to Vercel's infrastructure. Your own agents, the ones you run outside a template like this, usually don't get that for free; they live on a laptop that closes. MoClaw exists for that half of the problem, as a hosted cloud AI computer that keeps running after you shut the lid, sitting alongside whatever you already have installed rather than replacing it.

A software factory compared to a plain CI agent

A CI agent reacts to a commit that already exists. The Vercel eve software factory starts one step earlier, from a ticket, and the four-station split is what separates the two: classification and planning happen before any code gets written, and review happens against a diff by something that didn't write it. That ordering is what people are pointing at when they say ai software factory rather than "coding agent"; the unit of work is a request, not a prompt. Vercel positions the whole thing under its Agent Stack, and the underlying framework, eve, is the layer the stations are built on. The template is one of several Vercel publishes, alongside an eve marketing team and a personal agent.

Compare that to how most teams actually run coding agents today, which is one agent, one long conversation, one branch, and the same model grading its own homework. The station split costs more tokens per ticket and buys separation of concerns. Whether that trade pays depends on how expensive a bad merge is in your repository, which is a question about your team, not about Foreman.

Running four agents per ticket also means four sandboxes, and sandboxes want a machine that isn't the one you're typing on. That's the second place MoClaw fits: it takes the always-on execution off your local hardware, so a long pipeline isn't competing with your editor for CPU. If you want the general version of that argument, we wrote it up in what an agent harness is.

What's still unproven

The Vercel eve software factory template is three days old. There's no public data on how often the Reviewer catches a real defect, no benchmark on classification accuracy, and no cost-per-ticket figure from anyone running it at volume. The star count tells you developers find the idea plausible, not that the pipeline works.

Two things are worth watching. Whether the factory brain stays useful as it accumulates, since repository notes tend to rot, and whether the Reviewer's evidence requirement survives contact with large diffs. Both are the kind of thing that only shows up after a few hundred tickets. For a related pattern that ran into exactly this class of problem, see our writeup on self-improving coding agents.

If you do trial it, the honest test isn't whether Foreman can close an easy ticket; it's whether the Reviewer ever blocks the Implementer on something you'd have missed. Run it on a repo where you know where the bodies are buried, and hand it a ticket that touches one. Doing that properly means letting it grind through a queue overnight, which is again a question of whether you have a machine that stays up. MoClaw handles that shape of work, picking up on your phone what you started on a laptop, without needing the laptop to stay open for the run to finish.

FAQ

Is the eve software factory template free?

Yes. The repository is MIT-licensed, and the homepage describes Foreman as a free, open-source software factory. Running it is not free, though: you pay for the Vercel deployment, the Blob store, and every model call the four stations make.

Does Foreman merge pull requests automatically?

No. It opens draft pull requests and stops. You review, mark ready, and merge. Its automated CI fixes only touch branches under the factory/ prefix, so it can't push to your branches while repairing its own.

What is Vercel's Agent Stack?

It's Vercel's umbrella for running agents on their platform, covering the eve framework, Connect for third-party connectors like GitHub and Linear, and the sandbox and storage pieces the stations use. The eve software factory template is one published example of that stack assembled into a working pipeline.

Can I use it with Linear instead of GitHub?

Both, and the deploy flow sets up both connectors. Linear Agent Sessions run the same four stations and report progress back in Linear, while the resulting draft PR still lands on the GitHub repository named in FACTORY_REPO.

How is this different from a coding agent in my editor?

An editor agent works while you watch it and stops when you close the window. Foreman is triggered by a label or a mention, runs on deployed infrastructure, and reports back asynchronously. The difference is less about model quality than about who's waiting for whom.