An orchestrator for the Agent Development Life Cycle. Your GitHub repo holds the facts: the process, the branches, the pull requests and the CI results. Tickets move through that process, AI agents do the work of each step, and people approve at gates.
A control plane on GitHub
Factorial is a control plane on top of the systems a team already uses. It reads tickets, branches, PRs and CI from GitHub, and it writes status back. On an E2B runtime, it starts each agent in its own sandboxed VM. Agents deliver their work to the source repo as a branch and a PR, and you control how that code flows and gets merged into main and your release branches. Before approving, a reviewer can open a preview of the plan or of the running app.
Who does what
Three kinds of people work with Factorial. Each one uses the system in a different place.
- Operators
- Run the factory. They register runtimes, connect repositories and set the allowlists. They work in the dashboard or in an MCP client.
- Product owners
- File the issues. The issue is the brief that the agent works from.
- Reviewers
- Review the pull requests at the gates. A reviewer can open a preview first. Tickets and gates explains how a reviewer decides.
What stays in GitHub
Your work stays in GitHub, in the places your team already uses.
- Issues are the tickets.
- Labels and assignees show where each ticket is and who acts next.
- Every change reaches the repository as a branch and a pull request.
- CI runs on every pull request.
- Your branch rules decide the merge.
Where agents run
Each run gets its own place to work. On a hosted runtime, that place is a sandbox. On a host runtime, it is a separate git worktree. The agent pushes a branch and opens a pull request, and then the run ends. Factorial starts, watches and stops every run through one runtime contract. Runtimes lists the four runtimes and what each one can do.