The Vulnetix software factory turns findings, issues and failing builds into verified pull requests

Easy on the first call, and deeper every week after

On day one Software Factory does what you expect from a personal assistant and a factory: you call Pix, say what you want and approve what comes back. Keep using it and the plain-language front steps back. Behind it are years of work on the developer experience, with the customisation, autonomy and self-hosting you would expect from open source you run yourself.

1. Ask and approve

   Day one. Ask what needs you, start a sweep of your repositories and approve the pull request that comes back. There is nothing to learn first, and nothing changes without your yes.

2. The depth comes forward

   The first weeks. Shape your own workflows, read and edit what each agent remembers about a repository, set budgets per run and per repository, and raise the maximum autonomy one level at a time.

3. Yours to run

   Months in. Run crews on machines you host with Belai, the Apache-2.0 harness, bring your own model keys, and keep every evidence file in open formats such as CycloneDX and OpenVEX that your team can take anywhere.

Nobody plans every use on the first day. Most of what the factory becomes for your team, you find by using it.

What the security team gets

The controls security teams have asked their tools for, for more than a decade, are part of the line: a hash-linked audit ledger, a quality gate and a release jail that are plain rules with no model in the loop, sandbox egress control, the Package and AI Firewalls on by default in every workflow, signed commits, SLSA levels per repository, and stops that reach from one session to the whole machine. Security and proof in full

Software Factory comes from a team whose roots are in open source intelligence, financial technology and government cyber defence, with more than two decades of real-time data and machine learning work behind it. That experience sits under the plain words, in how the factory reads your data and weighs each decision.

• Talk. Pix opens the call with what is running and what needs you.
• See. What the factory did, counted from its own records: outcomes, sessions, agent time and tool calls.

The building blocks, grouped by the problem each one solves

Software Factory is a set of parts that run as one line. Most teams start with a few and reach for the rest as they need them. Each block below says what it does and names the problem it removes.

Decide what is worth doing

Do the work

Prove it

Stay in control

Avoid the work before a crew picks it up

Safe Harbour moves container images to hardened bases with a written migration plan, built from the SBOM, the Dockerfile CI builds and where the image runs, and pins packages to versions with no known vulnerability, exploit or malware report. Pix works on both sides of that change.

• A container moved to a hardened base. From the migration plan, Pix applies the new Dockerfile in the repository that builds the image, builds it, and opens a draft pull request labelled safe-harbour.
• Failing checks on a Safe Harbour pull request. Pix reads the failing logs, says whether the version changes caused it, and writes a plan to fix it.
• One package, one repository. Pix upgrades a package to the Safe Harbour pick the server worked out, and says what broke if the tests fail.
• An end of life base image. Pix finds where the release comes from, a base image included, and moves it to the recommended release.

How Safe Harbour and Pix work together

One line from trigger to evidence

Every run follows the same line. Something happens, 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. The three diamonds are the places where a run can branch, stop or wait.

1. Trigger: Something happens. A run starts from an event, not from a person watching a dashboard. The trigger decides which repository and which workflow. Cron, Webhook, Issue label, Scanner finding, Kanban change.
2. Context: The run gathers what it needs. Before it decides, the run collects the repository posture, the open issues and pull requests, and the findings so far. Repository posture, Open issues, Pull requests, Scan findings.
3. Scan: Run the Vulnetix scanners. A scan node runs the same scanners as the CLI inside the sandbox and writes findings, an SBOM and SARIF. SCA, SAST, Secrets, IaC, Containers, Licences, Malware, End of life.
4. Decide (switch): A System One model picks an outcome. A decision node returns one outcome from an enum you define, with a confidence. Below your threshold, or on abstain, it takes the action you chose. Classify, Gate (yes or no), Route to a crew, Score.
5. Work: A crew does the job. An agent or crew edits code, writes tests and answers questions in the sandbox. Handoff rules pass work between agents. belai:security, belai:feature, belai:bug, belai:delivery, belai:ui.
6. Gate (switch): Deterministic checks decide pass or stop. Gates are plain rules with no model in the loop. A failing gate returns the work to the crew, ends the run or asks a person. Quality gate, Release jail, Tests, Budget check.
7. Approve (switch): A person says yes. Human approval pauses the run until an approver answers. The approver and the answer go into the trace. Plan approval, Merge review, Publish review.
8. Output: The work leaves the machine. Outputs are what a run hands back to GitHub and to people, and each one is listed in the run. Draft PR, Issue comment, TEA publish, Notify, VEX.
9. Evidence: The run is written down. The trace, the decision rationale, the handoffs and the evidence files are kept, and the ledger entry is chained to the one before it. Run trace, Rationale, Handoffs, Ledger entry.

System One decisions with a threshold you set

A decision node asks a System One model to pick one outcome from a list you define and to report its confidence. An exploited library in a live service becomes a patch today, and a finding in a function nobody calls joins the weekly batch. Below your minimum confidence, or when the model abstains, the run does what you chose: ask a person, try a fallback model, take the safest outcome or stop.

The minimum confidence starts at 80%. Below it, a node can: escalate to a person, try a fallback model, take the safest outcome, end the run. When the model abstains or errors, a node can: escalate to a person, retry once, then escalate, end the run. The outcomes are an enum you define, for example patch_now, batch_weekly, suppress_candidate, escalate.

A decision never replaces a gate. The quality gate and the release jail are plain rules, so a confident model cannot talk its way past them.

Workflows built from triggers, gates and outputs

A workflow is a graph. It begins at a trigger (a schedule, a webhook event, an issue label, a scanner finding or a board change), runs through Vulnetix scanners, System One decisions, crews, quality gates and human approval, and finishes in outputs. Eleven quick-start templates cover the common jobs, so a team starts from a working workflow on one repository.

The 11 templates that change code end in a draft pull request for a person to review. Scan nodes run the same scanners as the Vulnetix code scanner, and the outputs include SBOMs in CycloneDX and statements in OpenVEX.

31 built-in agents, 6 crews and a board they work

Belai, the open source coding harness, ships 31 built-in agents, each with one job, from scanning a repository and patching a finding to reproducing a bug, fixing a failing test and resolving a merge conflict. The board is a kanban those agents work. Cards sit in review, backlog, done, triage and conflicts, and issues mirror to and from GitHub, so the board and GitHub show the same work. The 6 crews group the agents that work together, and the agent builder defines your own agents with handoff rules between them.

Built-in agents by job

The board and the crews

• belai:security: Works findings: patches, suppression candidates, secret and malware response.
• belai:feature: Builds a feature from an issue. A person approves the plan before code is written.
• belai:bug: Reproduces a reported bug, writes the fix and the test that covers it.
• belai:delivery: Moves work to done: stuck pull requests, conflicts and release checks.
• belai:maintenance: Turns failing tests and lint drift into reviewed branches.
• belai:ui: Interface fixes and polish passes, checked before a draft pull request opens.

Agents and crews are kept in your Library. The Pix registry lists the agents, crews, skills and prompts that other organisations publish, and a workflow can follow one by reference.

One queue for everything that waits on a person

Approvals, questions from agents, cards to confirm, lapsed claims, hosts that went offline, draft and ready pull requests, blocked and held cards, and outside issues nobody on your team has answered land in a single list, oldest first. The Needs you panel at the top of the cockpit is the head of that list, so the first screen of the day is the work only a person can do.

• Approvals: A run or session is paused until you approve or reject the plan, merge review or publish review. The button reads "Review".
• Questions: An agent asked something only a person can answer. The button reads "Answer".
• Held capabilities: The AI firewall is holding a tool, MCP server, skill or client nobody has reviewed, and a caller is waiting. The button reads "Review".
• Deployments: A deployment is waiting for an environment's required reviewers to approve it on GitHub. The button reads "Review on GitHub".
• Cards to confirm: A card on the board waits for a person to confirm it. The button reads "Confirm".
• Lapsed claims: An agent's claim on a card lapsed, so the card needs triage. The button reads "Triage".
• Hosts offline: A Pix Sandbox or a machine running belai rc stopped answering. The button reads "Open host".
• Draft PRs: A draft pull request is open and waiting to be marked ready. The button reads "Review".
• Ready PRs: A pull request is ready and waiting for a review. The button reads "Review".
• Blocked cards: A card stopped for a reason it recorded, and a person can unblock it. The button reads "Unblock".
• Held cards: A card is held for a decision before it moves on. The button reads "Decide".
• External issues: An issue from outside your organisation has had no reply from your team. The button reads "Reply".

What the factory 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. It also estimates what a team doing the same work by hand would have needed. That estimate depends on rates and rules you set, so every figure says how it was obtained.

• ● Measured. Recorded as it happened. For example: The length of a Pix call, or the time from opening a checkpoint to deciding it.
• ◐ Derived. Computed from records by a rule the page states. For example: Review time from the lines changed and the comments written.
• ○ Assumed. A value you set. For example: The hourly rate for people time.

A conflicting pull request becomes a card an agent works

Hand a pull request that conflicts with its base to belai:conflict-resolver and one card carries the whole job. The agent merges the base into a fresh checkout, keeps both sides where it can, and builds, lints and tests the result. It tries up to five different sets of choices and pushes the first that passes to the head branch as a fast-forward.

Agents tell each other what they are doing and keep notes you can read

Agents running in parallel on one repository broadcast the branch, files and pull request they are working on, and ask each other questions without interrupting the work. Both sides can read and record notes in repository memory, and a memory page lets a person review, edit or clear what the agents remember.

The factory passes the controls it applies to your code

An auditor, a customer or your own security team can check what ran, on what, under which controls and who said yes. It is the record security teams have wanted from their tools for years. The factory sits inside the Vulnetix security platform, so its own work goes through the same scanners, firewalls and gates.

Provenance is measured against the SLSA specification. Publishing is covered in Transparency Exchange.

Token budgets and autonomy limits you set

Budgets nest. A month holds days, a day holds workflows, a workflow holds runs, a run holds steps, and a per-repository budget cuts across all of them. Each budget names what happens when it is reached, so spend stops where you decided. Separate limits set how far the factory may go without a person.

• Month: The widest window. Everything the factory spends in a month counts toward it.
• Day: A daily window inside the month, so one bad day cannot use a month.
• Workflow: A limit on one workflow across its runs.
• Run: A limit on a single run from trigger to evidence.
• Step: A limit on one step inside a run, such as a crew step.
• Repository: A limit on one repository, whichever workflow spends on it.

When a budget is reached it can: pause the run, downgrade to a fast model, switch to the pix allocation, escalate to a person, hard stop, alert only.

• Pix allowance: The allowance that comes with your plan. It is the default source for System One decisions.
• Provider keys: Keys you store in the Secrets Vault, for models you bring yourself. A key's value is write-only: only its last four characters are ever shown.

Autonomy limits and the kill switch

You set how far the factory may go on its own. Limiting what an agent may do without a person is the control the OWASP Top 10 for LLM applications asks for under excessive agency.

1. Observe. Reads, decides and writes the trace. Changes nothing on GitHub.
2. Suggest. Proposes the change on the card or the issue.
3. Draft PR. Opens a draft pull request for a person to review.
4. Approve when ready. Approves a pull request once it is ready: checks green, reviews settled, nothing sensitive touched. A person merges.

• Concurrency: A cap on how many runs go at once.
• Stop the line: A workflow stops after the number of failed attempts you choose.
• Kill switch: One switch stops the factory.

Everything is on record

Events, decisions, handoffs and approvals are recorded and readable by the people who own the repositories. A reviewer can see why a change was made, and an auditor can verify what ran.

Event stream and run traces

GitHub events, run steps and handoffs arrive on one live stream that filters by run, card, agent, crew, repository or workflow. Each run keeps its decisions with the rationale, the handoffs between agents and the evidence files it wrote.

Tamper-evident audit ledger

Each entry is chained to the one before it, so the whole record can be verified. Editing an entry changes its hash, and hiding that means rewriting every entry after it.

Run the factory by phone

Pix, the factory coordinator, takes calls from the Resolve Platform header and from the installed app. Ask how runs and sessions are going, start or stop a session on a Pix Sandbox or any other Belai host, and answer an agent's question by voice. Pix acts on a session only after it reads the plan back and you say yes.

In your pocket: outcomes, savings and the stops

A call is half of it. The cockpit runs at phone width, so the delivery figures Pix reads to you are on screen, and so is every stop the factory has.

Five ways to stop

From one session by voice to the sandbox container, each stop says what it halts and what keeps working.

1. Voice: Stop a session
2. Cockpit: Pause all automations
3. Cockpit: A2A blackout
4. Settings: Stop the factory
5. Pix Sandboxes: Stop machine

• Stop a session (By voice on a call): Ask Pix. It reads back which session it will stop and acts on a plain yes. Halts: One agent session, wherever it runs. Keeps working: Every other session, workflow and host.
• Pause all automations (One press in the cockpit): The red button at the top of the cockpit, with a reason for the ledger. Halts: Every trigger is held and no new step starts. Keeps working: Steps already running finish. Interactive Belai sessions are not touched.
• Stop the factory (One press in Settings): The factory kill switch at the top of Settings, with a reason for the ledger. Halts: Running steps are cancelled, board leases released, forge tokens revoked and pending wakes cancelled. Keeps working: Interactive Belai sessions keep working. Resume the factory is one press.
• Stop machine (One press on Pix Sandboxes): Stop machine on the Pix Sandboxes page. Halts: Belai stops and the sandbox container is destroyed, so nothing is left running. Running sessions end and uncommitted work in the clones is lost. Keeps working: Your repositories and everything already pushed. Start machine brings up a fresh one and clones the repositories again.
• A2A blackout (One press in the cockpit): Beside the pause in the cockpit, and in Settings, with a reason for the ledger. Halts: Vulnetix stops relaying agent broadcasts, direct messages and replies between hosts. Keeps working: Each host keeps coordinating its own sessions and logs every message. Memory notes are not part of the blackout: review or clear them on the memory page.

Read the Pix Personal Assistant story

Runs anywhere Belai is hosted

Crews run wherever you host Belai, and every agent step, scan and test executes on that machine. A Pix Sandbox is Belai hosted for you: Vulnetix runs it around the clock with egress control. A team that needs the work to stay on its own infrastructure hosts Belai itself, on a build server, a workstation or any other machine, and connects it with belai rc. The factory treats both the same way. A sandbox or host also runs single agent sessions with no workflow, and Software Factory adds the triggers, decisions, gates, budgets and the record. Start on a Pix Sandbox and move crews to your own machines later, and the workflows stay the same.

The Pix Sandbox · Announcing the Pix Sandbox · Announcing Pix · Package Firewall · AI Firewall

Questions teams ask before they turn it on

What is the difference between Software Factory and the Pix Sandbox?

The Pix Sandbox is the isolated machine that every agent step, scan and test can run on. Software Factory is the feature set you run on it: the cockpit, event stream, board, workforce, workflows, budgets, trust pages and audit ledger. A sandbox can also run a single agent session with no workflow.

Where does the code run, and can we host it ourselves?

Crews run anywhere Belai is hosted. That can be a Pix Sandbox, the managed machine Vulnetix operates around the clock with controlled egress, or a machine you host Belai on yourself and connect with belai rc, when the work has to stay on your own infrastructure.

Which repositories can a workflow touch?

Only repositories in a GitHub organisation you chose to manage. Inside one, the cockpit lists every repository you have scanned or attached, and a workflow names the repositories it may use. The API refuses a repository outside your managed organisations.

Who approves a change?

People you choose. A workflow can pause for human approval at a plan, a merge review or a publish review, and the approver and the answer go into the run trace. A System One decision never replaces a gate, and the quality gate and release jail are plain rules.

Will it merge code without me?

No. The factory has no merge, auto-merge or write access to contents. Maximum autonomy is a setting with four levels: observe, suggest, draft PR and approve when ready. The top level lets it approve a pull request that is ready, and a person still merges. The workflows that change code end in a draft pull request.

What happens when a System One model is unsure?

You decide in advance. A decision node has a minimum confidence. Below it the node can escalate to a person, try a fallback model, take the outcome you marked safest or end the run. A separate setting covers an abstain or an error.

How is spend capped?

Token budgets apply per run, step, workflow, day, month and repository. Each budget names an action at its limit: pause the run, downgrade to a fast model, switch to the Pix allocation, ask a person, stop hard or alert only. A System One decision uses the default model from your Pix allocation, and crews can use the Pix tiers or models you bring through provider keys.

How do I stop it?

There are four ways. Lower the maximum autonomy, set a budget whose action at the limit is a hard stop, cap concurrent runs, or throw the kill switch.

Do agents talk to each other?

Yes, over A2A messaging. Each session broadcasts what it is working on, and an agent that hears about its own repository can change course, add a task, wait or send the other agent a direct question, which is answered without interrupting it. Every message is kept in both transcripts and linked between the sessions. Both agents in a conversation can read and record notes in the repository's memory, which you can review, edit or clear on the memory page. Sessions on one machine coordinate without signing in, and an A2A blackout stops relay between hosts.

Can I run the factory from my phone?

Yes. Tap the phone icon in the Resolve Platform header, or the Call Pix shortcut in the installed app, and talk to Pix. It answers questions about your runs, sessions and hosts, looks up vulnerabilities and exploits, and remembers preferences you give it. To start or stop a session it reads the plan back (repository, branch, host and task) and acts only when your next answer is a plain yes. While a session runs, Pix stays on the line, tells you when it finishes and passes on an agent's questions for you to answer. Everything it did and every table it read stays on the call screen.

How many agents come built in?

Belai ships 31 built-in agents, grouped into 6 crews: belai:bug, belai:delivery, belai:feature, belai:maintenance, belai:security, belai:ui. Of these, 12 each triage the dependency findings of one group of package ecosystems. You can follow agents from the Pix registry and define your own in the agent builder, with a model tier and handoff rules for each.

What waits on a person, and where do I see it?

There are 12 kinds of item that wait on a person: approvals, questions from agents, AI capabilities held for review, deployments waiting for reviewers, 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.

What happens when a pull request has a merge conflict?

You can hand it to belai:conflict-resolver from Checkpoints or from the Pix Sandbox pull requests tab, and a default workflow can do it for you. One card carries the job. The agent tries up to 5 sets of choices, tests each one, and pushes the first that passes to the head branch. A fork gets the result as a comment, and a card that cannot be resolved waits for a person.

Are the Delivery figures benchmarks?

No. Delivery reports what your factory did in a range you choose, and marks every figure measured, derived or assumed. The comparison with a team doing the same work by hand is an estimate built from the roles and rates in your settings, and it is labelled assumed.

What does an auditor see?

Each run keeps its decisions with the rationale, the handoffs between agents, the approvals and the evidence files it wrote. Ledger entries are chained to each other, so the whole record can be verified, and a SLSA level is reported for each repository.

How do we start?

Choose a GitHub organisation to manage and start from one of the eleven quick-start templates on a single repository. Leave autonomy at draft PR and read the first run trace before you add more.

See the line run on one of your repositories

Start one quick-start template on a single repository with autonomy at draft pull request, and read the first run trace, with every decision and its rationale, before anything widens. Community includes one self-hosted Belai host at no charge, and its crews run on your own model keys. A Pix Sandbox runs it for you instead, from $85 a month.

Run it free on your machine Pix Sandbox from $85 a month Request a demo Pricing Documentation