Four agents turn one task into a reviewed draft pull request
Foreman takes a GitHub issue, Linear delegation, mention, local TUI request, failed CI run, or newly opened pull request and routes it to a specific workflow. For implementation tasks, a classifier decides whether the request is actionable, an analyst writes acceptance criteria, an implementer changes code in a sandbox, and a reviewer judges the pushed branch.
The separation is meaningful. The reviewer sees the diff rather than the implementer's private reasoning, and every station has its own instructions, tools, and sandbox. A shared factory brain carries repository notes between runs. Long research or planning documents can live in Vercel Blob as handoff artifacts, so later stations receive an identifier instead of forcing the orchestrator to carry the full document in context.
What happened when we ran it
Our sandbox installed 196 pnpm packages in 32 seconds, using 242 MB on disk. The build then failed after 8 seconds while Eve evaluated agent/tools/read_factory_brain.ts. Its error was precise: FACTORY_REPO was not set, with acme/widgets given as the required owner/repo shape. That variable is documented as mandatory, so the failure confirms that even the repository build is tied to a configured target.
No tests script or target existed, and the lab therefore skipped tests. The commit 0d630a2 checkout had 92 files, roughly 3,617 lines of source, and occupied 1.7 MB before dependencies. Our scan found no CI workflow files, Dockerfile, or tests directory. The project uses pnpm workspaces, but its small source tree should be read as template glue around Eve and Vercel services, not as a standalone factory engine.
The measurement does not say the pipeline fails after deployment. It says a fresh checkout cannot complete its build without naming a repository, and it offers no standard test command for us to run. Teams evaluating agent behavior must create their own scratch target and acceptance set rather than relying on a portable local check supplied by the template.
Vercel Connect is a dependency, not an optional deployment flavor
The deploy button provisions a GitHub connector, Linear connector, and public Vercel Blob store, then asks for FACTORY_REPO and an issue label. The selected GitHub App must be installed with access to that exact repository. Deployment clones the target up front to prewarm station sandboxes, so an inaccessible or misspelled repository stops the deployment before agents begin work.
Local development also starts from a deployed project: vercel link, vercel env pull, then pnpm dev. This is not an offline daemon that happens to support Vercel. Connector identities broker GitHub and Linear access, Blob stores memory and handoffs, and Vercel sandboxes isolate station work. Teams with existing Kubernetes or another cloud platform would be adopting a second operating model for this template.
One target repository keeps the boundary understandable
FACTORY_REPO is a single required owner/repo value. A label, defaulting to factory, hands an issue to the pipeline. The factory uses its own branch prefix, and automated CI repair touches only branches created by the factory. This narrow target makes permissions and cleanup easier to reason about than an installation that can roam across every repository in an organization.
It also limits consolidation. A company with 20 repositories would need separate projects or a customization that changes the template's assumptions. Each target may need its own FACTORY_SETUP_COMMAND to install dependencies during sandbox prewarming. Repositories with private package registries, generated credentials, large build assets, or unusual system packages should prove that setup path before allowing unattended intake.
Human approval remains part of the design
A labeled issue can run without a person watching, but Foreman finishes with a reviewed draft pull request. The README says people make the judgment calls, mark the result ready, and merge it. Local TUI runs treat GitHub mutations as untrusted and wait for approval. Red CI on factory branches can trigger diagnosis and another push, while branches outside the factory prefix are excluded from that automation.
These are good defaults for code-writing agents. They reduce the chance that one mistaken classification becomes an unreviewed production change. They do not prove the change is safe. The reviewer is another model operating from a diff, and the checkout provides no test target for the template itself. Repository checks, branch protection, required human review, and a scratch rollout still carry the safety case.
The factory brain needs a poisoning policy
Every run starts with shared notes about the repository. Interactive sessions can update that factory brain, while unattended issue intake cannot write it directly. Project history explains the reason: an issue body should not be able to poison shared context. An unattended run can suggest a memory note in its final reply, leaving a maintainer to decide whether the fact belongs in future sessions.
That boundary is more careful than silently treating every issue as durable truth. Teams should still define what may enter memory, how corrections work, and whether generated notes can contain secrets or outdated setup commands. Handoff artifacts use reserved Blob namespaces and constrained identifiers, but the human meaning of a stored instruction remains a governance problem rather than a storage one.
August 2026 activity is recent, while release evidence is absent
GitHub recorded 1,087 stars, 0 combined open issues and pull requests, and a last push on August 20, 2026. The repository was created only on August 12 and had no GitHub release returned by the latest-release endpoint. Recent merged pull requests addressed repository authorization errors, Eve upgrades, sandbox settings, memory storage, and handoff documents.
Foreman is a focused example of how to structure a coding factory on Eve, and the four stations are easier to inspect than one agent with a huge prompt. Our build failure and missing test target mean adoption starts with deployment, credentials, and a live scratch repository rather than a clean local proof. Choose it when that Vercel-specific path is the point; choose a general coding agent when portability matters.