Solutions · Software Factory
Your development process, enforced for coding agents
Software Factory writes how your team ships software into an operating model, and coding agents do the work inside it. They plan, build and test on their own branch, a different agent reviews every change, and the merge stays with your engineers.
01How a change moves
Six stages, each one enforced by the platform
Each stage is a step in your operating model. An agent cannot jump ahead, and a step that needs a person waits for one.
Stage 01
Request
A software request reaches Kate in Console and becomes a work unit: a scoped piece of work on a known starting commit.
the platform scopes itStage 02
Plan
The coding agent writes its plan before it touches any code. The planning step cannot change anything.
agentStage 03
Build
The agent commits to its own branch in an isolated workspace. If a required check keeps failing, it gets a fixed number of attempts and then escalates to a person.
agentStage 04
Verify
Required checks come from your repository’s branch protection. The platform reads the real results from your CI and records a verification receipt that cannot be edited or deleted.
the platform checks itStage 05
Review
A different agent reviews for correctness, security and fit with your codebase’s conventions, and returns approved or changes requested. It never fixes what it finds.
a second agentStage 06
Merge
Marking the change ready waits for a person’s approval, and a person on your team merges it. Agents cannot merge.
your engineers02The rules
The rules a coding agent works under
The rules live in your operating model, not in a prompt. A clever instruction or a new model cannot loosen them.
Runs
- Write a plan
- Run the checks
- Commit to its own branch
- Open a draft pull request
- Escalate when stuck
Waits for a person
- Mark a change ready to merge
- Edit CI configuration, code owners, review thresholds or the gates themselves
Never, for any agent
- Merge a pull request
An agent that tries to edit the thing that checks its work is always sent to a person, however much it has been trusted with elsewhere.
03Worked example
Can a real engineering organization's rules be written down?
To find out, we used public material from Kubernetes, one of the largest open-source projects. We encoded the change-approval rules for one part of it, the scheduler, from six months of public history and its published OWNERS files: a reviewer's sign-off, an owner's approval, and no hold. Then we sealed those rules and replayed the following six months, which we had not looked at.
Three of those patterns now ship in our software delivery model: merging takes two independent sign-offs, a new revision sends the change back through approval, and a hold stops the merge.
Kubernetes is an open-source project. We used its public repository and process documents as a test case. The Kubernetes project is not a customer and has not reviewed or endorsed this work.
Replay of the unseen six months
One part of one project over six months. The replay tested the rules themselves, with no AI model involved. It shows a real process can be written down and enforced by machine, not that every process can.
04Your process
We write down your development process the same way
We start from how your engineers already work and write that down, rather than handing you our process.
Start with a thin slice.
One repository and one kind of change first. The process widens as it proves itself, and each widening is a reviewed change to your operating model.
Your specifics stay yours.
Who holds merge authority and who approves protected files are set in your configuration, and changing either one is itself a pull request your people review.
A deployment of your own.
Software Factory runs on a dedicated deployment with a GitHub organization of its own, and your people are the reviewers and the mergers.
05Questions
What engineering leaders ask first
Can an agent merge its own work?
No. Merging is reserved for people, and no setting changes that. An agent can open a draft pull request and propose that it is ready, and that proposal waits for a person. A different agent reviews every change, and the reviewer cannot fix what it finds.
What stops an agent from loosening its own checks?
Edits to CI configuration, code owners, review thresholds or the gates themselves always wait for a person, however much an agent has been trusted with elsewhere. The rules live in your operating model, not in a prompt, so a clever instruction or a new model cannot lift them.
Does it work with our repositories and CI?
It works with GitHub today. Required checks are read from your repository’s branch protection, and the platform reads the real check results from your CI before a change can move on. The work happens in a GitHub organization dedicated to your deployment, and your people are the reviewers and the mergers.
Which coding model does it use?
Software Factory governs the process rather than depending on one model. The coding agent works inside the gates your operating model declares, so the same rules apply if the model underneath changes.
Where does it run?
On a dedicated deployment of Authentica with its own GitHub organization. We do not offer Software Factory on shared environments.
Can we see what an agent did?
Yes. Each commit carries signed provenance tying it to its work unit, each check result is recorded as a receipt that cannot be edited, and each approval records who gave it.
Start with one repository and one kind of change
We map the process your engineers already trust, then widen it as it proves itself.