What Software Factory is
Software Factory is the automation layer on the Vulnetix GitHub App and the Pix Sandbox. A trigger starts a run: a scanner finding, an issue label, a webhook event, a schedule or a board change. The run gathers context, scans, decides, works, passes the gates, waits for a person where you require one, hands back its output and writes down what it did.
It runs on a Pix Sandbox, which Vulnetix operates around the clock, or on a machine you host Belai on and connect with belai rc. It does not merge code. The workflows that change code end in a draft pull request, and a person merges.
The loop, step by step
Six steps take a finding to a pull request and put a person at the points that matter.
- Findings in: A scanner finding, an issue label, a webhook event, a schedule or a board change starts a run.
- Agents work: 31 built-in agents in 6 crews patch, test and review on a Pix Sandbox, or on a machine you host.
- Gates decide: The quality gate and the release jail are plain rules with no model in the loop.
- People approve: Plans, merge reviews and publish reviews wait for a person. Checkpoints queue everything that needs you, and the cockpit shows the head of the queue.
- Pull request out: A draft pull request arrives with the run trace, the decision rationale and the evidence files.
- Call Pix: Phone Pix to ask how runs are going. Pix reads a plan back before it starts or stops a session, and acts on a plain yes.
31 built-in agents in 6 crews
Each built-in agent has one job. The 6 crews group the agents that work together: belai:bug, belai:delivery, belai:feature, belai:maintenance, belai:security, belai:ui. A security crew has a scout, patchers and a verifier. A feature crew has a planner, builders and a reviewer, and a person approves the plan before any code is written. The agent builder defines your own agents, with a model tier and handoff rules for each.
The 11 quick-start workflow templates cover patching, bug fixes, features, dependency upkeep, malware and secret response, release provenance, triage and delivery sweeps.
- Security fixes: A scout runs the Vulnetix scanners, patchers fix each finding on its own branch, and a verifier re-checks every verdict with the scanner before it is recorded.
- Features, bugs and interface: A planner splits a request into small build items, a designer specifies interface changes as user journeys, a bug investigator names the root cause, and builders and reviewers do the rest.
- Upkeep: Agents that fix failing tests and lint drift, review a named pull request read only, and resolve merge conflicts.
- Dependencies by ecosystem: 12 agents, each triaging the dependency findings of one group of package ecosystems: Go modules, npm and Deno, Python, Maven and Gradle, Cargo, Composer, Bundler, NuGet, SwiftPM and CocoaPods, CI pipelines, containers and infrastructure files, and the rest.
- General purpose: Reproduce and fix a failure, split an objective into independent read-only questions, or execute a written plan step by step.
What waits on a person
There are 10 kinds of item that wait on a person: approvals, questions from agents, cards to confirm, lapsed claims, offline hosts, draft and ready pull requests, blocked and held cards, and outside issues with no reply. Checkpoints lists them in one queue, oldest first, and the Needs you panel at the top of the cockpit shows the head of it.
A pull request that conflicts with its base can go to belai:conflict-resolver. One card carries the job. The agent merges the base into a fresh checkout, keeps both sides where it can, tests the result, and tries up to 5 sets of choices. It pushes the first that passes. A pull request from a fork gets the result as a comment, and a card that cannot be resolved waits for a person.
Limits you set
Maximum autonomy has four levels: observe, suggest, draft pr, approve when ready. The top level approves a pull request that is ready, and a person still merges. Token budgets cap spend per run, step, workflow, day, month and repository, and each budget names what happens at its limit: pause the run, downgrade to a fast model, switch to the pix allocation, escalate to a person, hard stop, alert only. One kill switch stops the factory.
Plans, merge reviews and publish reviews can pause a run until a person you chose answers. The approver and the answer go into the run trace, and ledger entries are chained to each other so the record can be verified.
What it delivered, and how each figure was reached
Delivery reports, for a range you choose, the outcomes the factory reached, the agent time and model spend behind them, the decisions it scored and the people it needed. Every figure is marked measured, derived or assumed. A figure that has not been recorded yet reads "Not recorded yet", and a real zero reads as zero.
The estimate of what a team doing the same work by hand would have needed depends on the roles and rates in your settings. It is labelled assumed, and it is no industry benchmark.
What happened to the Pix chat drawer
The chat drawer and its three modes are retired. Rubber Duck, Kremvax and Dark Avenger live on as the names of three built-in agents: belai:vuln-scout, belai:patcher and belai:verifier. They now scan, patch and verify in sessions on a Pix Sandbox.
Pix is now the voice of the factory. Phone Pix from the console header or the installed app to ask how runs and sessions are going, or to start or stop a session. Pix reads the repository, branch, host and task back to you and acts only when your next answer is a plain yes. While a session runs, Pix tells you when it finishes and passes on an agent's question for you to answer.
Where it runs and what it costs
A Pix Sandbox is priced by size, and the size sets how many agents can work at once: Small $85 a month with up to 7 agents, Medium $180 a month with up to 14 agents and Large $350 a month with up to 28 agents. System One decisions are included at no charge on every size.
A team that needs the work to stay on its own infrastructure hosts Belai itself and connects it with belai rc. The factory treats both the same way.
See the line run on one of your repositories
A demo starts one quick-start template on a single repository with autonomy at draft pull request. You read the first run trace, with every decision and its rationale, before anything widens.