Today we're launching Mastra Factory in beta.
This is the open-source software factory we built to automate our own issues, that's now writing 25-35% of our PRs and closing 50-60% of our issues. It's built on our own Mastra primitives and has fundamentally changed our contribution and collaboration process.
How the factory works
Mastra Factory connects GitHub, Linear, and Slack to configurable boards. For us, that's Intake → Triage → Planning → Build → Review → Done, but you can configure your own, and run each step on manual or auto mode.
At each step, agents work in sandboxed environments and follow rules for starting tasks, reviewing changes, and moving work forward. You can inspect diffs, join discussions, approve actions, and see which tasks need your attention. Each work item opens into an agent session with chat, tool activity, and workspace files.
Here's the demo:
What we've seen so far
Mastra is an active open-source project, with contributions from the community and maintenance by a core team. We see over 100 opened issues per week, and merge around 200-250 PRs. Since we introduced Factory in alpha in July, it's automated 25-35% of our PRs and closed 50-60% of our issues.
PRs merged:
Issues closed:
With Factory, we're seeing more maintenance capacity with fewer engineers and flattened issue growth.
Improving triage with investigation
So what's driving these improvements?
One example: improving the way we do issue intake. Users in our community raise a variety of issues on GitHub. Many are real, but many have to do with users not following setup instructions, or are too vague for us to reproduce.
We'd previously built a bot that supplied labels and a welcome comment. But Factory gives us an investigation the next person can use, with a diagnosis, supporting evidence, assumptions, and reproduction results. For example, its A2A investigation documented six failing reproduction assertions and identified the server integration as the owner.
The reason Factory is able to do this accurately is because of Mastra's observational memory. A coding investigation generates lots of disposable text — file contents, searches, test output — which gets compressed into a line-by-line log of the important stuff.
Building a fully configurable issue pipeline
We initially started with "full automatic" mode. Once an issue started up, it would run through each stage until review. We ran into a few different issues with that. It was bursty when importing backlogs, causing infra issues and generating a lot of difficult-to-review work. We found ourselves moving into manual mode, and decided to ultimately make each stage configurable.
For example, triage can run automatically while planning, implementation, and review remain manual. Or bugfixes could automatically flow through the process, but not feature requests.
The key challenge: incorrect assumptions upstream causing problems downstream. As Mark Twain said: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."
In one instance, our agentic observability tool sent an incorrect alert. In another, a triage agent mis-identified revenue loss, generating PRs that needed to be closed.
Giving agents a wiki, managing the session, steering, sandboxes
Powering the factory is our new knowledge base, a graph-based wiki. The nodes are entities — facts with citations and links to source sessions. The edges are entity relationships. Each page has a name, a kind string, content, and links to other pages. It's built by a specialized knowledge curator agent.
We're going to be releasing the knowledge graph soon as a free-standing primitive.
The Mastra AgentController class manages the live agent session around the model–tool loop. It gives Factory a consistent way to start work, deliver updates, pause for input, and continue with the right state.
Steering happens via Signals. A user can correct the scope, a collaborator can add context, or another agent can send a finding while the worker is running. The worker can incorporate the update as execution proceeds, without starting a separate conversation.
The Factory supports both local and cloud execution. And even if running locally, you can use remote sandboxes for code writing and execution if desired.
Our changing contribution model
We've been running open-source projects for over a decade. Small issues have always been a way to enable new contributors to help build the project. Sometimes there's some back and forth, where the contributor fixed it in a way you wouldn't expect.
With Factory, the cost of fixing these bugs has dropped so low, this no longer makes sense as a contribution model. We're shifting from encouraging community PRs to encouraging highly detailed issue repros, and we're crediting issue authors on merged PRs.
Getting started
Install Factory with:
npm create factory@latestIf you want a walkthrough, join Abhi and Alex for the Build and Own Your Software Factory workshop.
