Skip to main content

Using the factory

Mastra Factory provides an opinionated workflow for moving work from an issue to a reviewed implementation. Each stage shows what the agent is doing and where your input is needed. It also gives you a clear place to continue the conversation.

The Factory uses different items for implementation work and pull request reviews. An issue moves through the work board. Its pull request opens as a linked item on the review board with its own agent session.

Intake

Intake collects new work from connected sources such as GitHub and Linear. It receives GitHub issues and pull requests, along with Linear issues, before an agent begins working on them.

Some items can skip Intake. For example, the default rules can send a new issue from a trusted GitHub contributor directly to Triage and a new pull request directly to Review. Other items remain in Intake until you choose an action.

For an issue, select Investigate when you want the agent to understand the problem and prepare a plan. Select Build when the task is already clear enough to begin implementation. For a pull request, select Review to start a review session.

Triage

The Triage stage begins with an investigation of the issue and its available context. The agent may inspect the repository or review related discussions. It also identifies details that are missing from the original issue.

The agent may ask you questions when it can't make a reliable assumption. Continue the conversation in the associated session and provide any product or technical decisions it needs. Once the problem is sufficiently understood, the work can move into Planning.

Planning

The agent uses its investigation to create a concrete implementation plan. The plan should explain the intended changes and important constraints. It should also describe how the result will be verified.

Review the plan before implementation begins and ask any questions before deciding. Approve it when the approach is ready, or request revisions when it needs more work. Approval automatically moves the work to Building so the agent can begin implementing it.

Building

After approval, the work agent follows the plan and changes the code. It then runs the relevant checks. The agent continues using the workspace and branch associated with the work item, so the implementation retains the context gathered during earlier stages.

The agent should finish by opening a pull request for the completed changes. If you selected Build directly from Intake, the agent performs the necessary investigation as part of the implementation instead of waiting for a separate plan.

Review

When a pull request is ready, the Factory tracks it as a linked review item. The review item has its own session and review agent, distinct from the session that implemented the change.

The review agent checks the pull request and its tests. It also considers the surrounding context. You can open the review session to follow the investigation or provide additional direction. Pull request activity can be delivered to the subscribed agent session, allowing the agent to respond to review comments and make follow-up changes.

Review remains a human-controlled gate. Inspect the pull request and merge it when you are satisfied with the result.

Done

Merging a pull request doesn't automatically mark the original work item as Done. A single work item can require more than one pull request, so the Factory first asks the work agent to assess whether the requested work is actually complete.

After the implementation has been verified and no further work remains, the agent or a user can move the work item to Done.

Canceled

Move a work item to Canceled when the requested work should no longer continue. This may happen when an issue is no longer relevant or another approach replaces it. You may also cancel an issue that was closed without an implementation.

Closing a linked GitHub issue or pull request doesn't automatically cancel the Factory work item. Move it to Canceled explicitly so the board records the final decision.