Mastra has opened Factory in beta after using the agent-powered software-delivery system on its own repositories. Factory turns software work into a staged pipeline in which agents inspect an issue, plan a change, implement it in an isolated environment and send the result through review. The important part of the launch is that Mastra says it stopped treating that entire chain as one automatic action.
That reversal matters for teams evaluating coding-agent factories. Mastra says early fully automatic runs created bursty workloads that stressed infrastructure, while incorrect alerts or triage assumptions could propagate into poor downstream pull requests. Factory therefore lets teams decide separately which stages run automatically and which stop for human action. Mastra's launch post and the open-source template make that control boundary visible.
Autonomy is configured by stage
Factory organizes work across intake, triage, planning, build, review and completion. Each work item gets its own agent session, and teams can configure stage transitions as automatic or manual. The Factory site also describes graph-based repository knowledge and isolated execution for agent work.
That changes how autonomy should be evaluated. Generating a plausible patch is only one part of the system. The harder question is which decisions may become inputs to later stages without another check. If a wrong assumption survives triage and planning, the cost of correcting it can move from one decision to a larger body of generated work.
Mastra's numbers are useful, but not a benchmark
Mastra says that since its internal alpha began in July, Factory has automated 25–35% of pull requests and closed 50–60% of issues. The same post includes aggregate charts showing 1,627 merged pull requests, of which 277, or 17.0%, were authored by Factory, and 778 closed issues, of which 222, or 28.5%, were attributed to Factory.
Those figures should not be collapsed into one productivity measure. Mastra does not establish that the prose percentages and chart totals cover identical periods, repositories or denominators. They are also company-reported results, not an independent evaluation. What they establish is that Factory has been used on real internal repositories at enough volume for Mastra to observe operational failure modes.
Full automation exposed an upstream-error problem
Mastra says its first approach was a largely automatic path from incoming work toward completed changes. Large backlog imports could arrive in bursts and put pressure on infrastructure and review capacity. More importantly, a bad alert or incorrect early assumption could make the system produce a pull request that should never have been built.
The beta design turns those failures into an architecture decision. Teams can keep low-risk steps automatic but stop at boundaries where intent, scope or evidence needs confirmation. The constraint therefore lives in the workflow around the model, not only in instructions asking the model to be cautious.
Self-hostable does not mean fully local by default
Mastra publishes the Factory template under Apache-2.0 and documents a self-hostable server that can run as a Node.js service, container or virtual machine. The repository exposes configuration for authentication, storage, PostgreSQL and sandbox providers, including a local sandbox option.
The default new-project path, however, uses Mastra platform services for authentication, storage and sandboxes. Teams evaluating data boundaries or vendor dependency should distinguish a self-hostable server from a deployment whose entire control plane is local.
The broader lesson is that coding-agent scale shifts the scarce resource from code generation toward delegated authority, triage and review. For engineering leaders, a useful architecture test is to ask where an agent can be stopped, not only what it can do. Mastra's experience does not prove that stage-specific gates eliminate failures, but it provides direct evidence for why those gates exist.