Control what your AI coding agents ship.
FactoryOS is the governance layer for AI-assisted engineering. Every change an agent makes is checked against your architecture and past decisions, rated for risk, approved by a person and kept on the record.
- Agents never merge
- Starts advisory, you decide when it blocks
- Bring your own model key
Why now
AI made writing code cheap. Deciding what to merge did not get any cheaper.
Once agents write a meaningful share of your code, the constraint is no longer how fast work gets written. It is whether anyone can still answer for it.
More change than anyone can review
Agents open pull requests faster than senior engineers can read them. Review becomes the bottleneck, or it quietly becomes a rubber stamp.
Agents do not know your architecture
They cannot see the decisions your team made, the approaches it already rejected, or who owns the service they just changed. The code looks right and still breaks the rules.
Nobody can say who approved it
When an auditor, a customer or an incident review asks why a change was made and who signed off, the answer is scattered across a thread, a ticket and a pull request.
FactoryOS keeps these answers attached to every change:
- Who approved this change, and on what basis?
- Does it follow the architecture we agreed?
- Which services and teams does it touch?
- Why did we decide this the last time it came up?
What FactoryOS is
Keep your coding agents. Add the control plane they are missing.
Coding agents make an engineer faster at writing a change. FactoryOS decides whether the change should exist, who signs off, and what it affects.
It is not another coding agent, and it is not a new place for your engineers to work. It sits between the tools where intent is agreed and the agents that write the code, and it reviews a pull request the same way whether an agent, an assistant or an engineer opened it.
Tools your teams already use
- ChatSlackorDiscord
- Work trackingJiraorLinear
- DocsConfluenceorNotion
FactoryOS
The control plane every change passes through
- ContextSpec snapshots, architecture, past decisions, service owners
- PolicyGates, written risk rules, earned autonomy
- ApprovalA person decides at design and at merge
- RecordHash-chained audit trail and cost per run
Who writes the code
Claude Code, driven by FactoryOS, or any other agent or engineer. A pull request is reviewed on the same path whoever opened it.
Where it lands
factory-review runs as a Check on the pull request, and merging stays a human action.
How it works
From a Slack thread to a merged pull request, with people at every decision
Six steps. Agents do the drafting, designing and building. Three steps stop until a person decides, and merging is always one of them.
- 01
Slack
Intent raised
Human - 02
Spec
PM agent drafts
Agent - 03
Confluence · Jira
Spec published, epic opened
Agent - 04
Architecture
Architect proposes, cites decisions
Agent - 05
Sandbox
Coding agent works each ticket
Agent - 06
Pull request
factory-review Check
Agent
- Gate 1 · PM approves the spec
- Gate 2 · Architecture approved, tickets created
- Gate 3 · Merge, always human
FactoryOS
The control plane under every step
- Snapshot before action
- OPA policy at every gate
- Org Graph routing and impact
- Explainable risk tiers
- Change requests, loops broken at depth 3
- Hash-chained audit log
Integrations
Runs in the tools your teams already use
Pick one tool per category for each workspace. There is no new place for your engineers to go.
Chat
SlackorDiscordWhere work is requested, and where people are asked to approve it.
Work tracking
JiraorLinearWhere the work items for an approved design are created and tracked.
Docs
ConfluenceorNotionWhere specs and architecture documents are published for your team to read.
Code
GitHubWhere pull requests open and factory-review runs as a Check.
Capabilities
Governance that comes from the work, not from forms
Nothing here asks an engineer to fill anything in. It is captured as people approve a design, open a pull request and merge it.
Architecture review before code
An architect agent proposes the design and the ticket breakdown, citing the decisions that bear on it. Your engineers approve, request changes or reject.
Acceptance criteria, one at a time
factory-review reports whether each criterion is met, contradicted, or cannot be verified from the diff alone. It informs the reviewer and does not decide the Check.
Risk you can argue with
Low, medium or high from written rules, never a score. Every rating shows the rule and the evidence, and an override is recorded beside the original.
Cross-team impact
The Org Graph learns which services call which. When a change reaches a service another team owns, those owners hear about it during review, not after release.
Decision memory
Approvals and rejections become decision records, recalled and cited the next time a change touches the same ground. Rejected approaches are kept too.
Honest authorship
Each change is marked agent-authored, AI-assisted, human or unknown, from the evidence available. It is never guessed at.
Human gates, earned autonomy
Every gate starts required. Relaxing one is a policy change, weighed on measured evidence and approved by a second security admin.
A record you can hand over
Every action lands in an append-only, hash-chained log: which agent, which model, who approved, what it cost. Hard caps stop a run before it overspends.
Flagship
Architecture review, before the code exists
An agent can write a working change that quietly contradicts a decision your team made two years ago. Caught at design, that is a conversation. Caught after merge, it is debt.
- The proposal is grounded in your repositories and cites the past decisions that apply.
- Affected services, their owners and the risk tier are shown beside it.
- An agent-authored proposal cannot approve itself. The decision becomes a record the next change will cite.
Why FactoryOS
Most AI tools help you write more code. FactoryOS helps you decide what to keep.
Use them together. They answer different questions.
AI coding agents
How do I write this change?
AI code reviewers
Is this code well written?
FactoryOS
Should this change exist, does it fit our architecture, and who approved it?
Neutral across vendors
Your review layer should not belong to whichever vendor wrote the code. FactoryOS drives Claude Code and reviews pull requests whoever opened them: one check and one record across all of them.
Memory that compounds
Every approval and rejection becomes a decision the next review can cite. The longer your teams use it, the more of your own engineering history it brings to each change.
Evidence over opinion
Risk comes from written rules with ids you can quote. Acceptance-criteria citations are checked against the diff by code with no model in it, and anything the evidence does not support is marked unverified.
Who it is for
Built for the people who answer for the change
Each role meets FactoryOS somewhere different. For engineers that surface is deliberately almost nothing.
Head of Engineering
Can we use far more AI without lowering the bar?
Gates, approvals, spend and an audit record across every team, whichever agents they use.
Engineering Manager
What needs a decision from my team today?
Approvals waiting, runs in flight, the risk on each open change, and which ones cross into another team.
Architect / Tech Lead
Is an agent about to undo a decision we already made?
Architecture review before code is written, with the decisions that bear on it cited in place.
Security & Compliance
Can we prove who approved this, and what the agent could touch?
Sandboxed runs with scoped credentials, a tamper-evident record per action, and gate changes that need a second admin.
Engineers
Is this another tool I have to learn?
No. A ticket that carries its own context, and a check on your pull request that reads architecture rather than style.
- Join the beta
Your team
See it on your own pull requests.
Trust and security
Built to be trusted with your code
A governance product has to be the most careful system in the room.
Agents never merge
Merging is always a human action. There is no setting that changes that.
Advisory first
factory-review starts advisory. You make it a required check when you trust it.
Sandboxed agent runs
Coding agents work in a sandbox with scoped credentials and a budget cap.
Tenant isolation
Enforced in the database with row-level security, not only in application code.
Keys held in Vault
Your model key is held per tenant in HashiCorp Vault, never in our database.
Managed sign-in
Sign-in runs through a dedicated identity provider with SSO, so FactoryOS never stores your passwords.
Tamper-evident audit
Append-only and hash-chained per tenant, and exportable when you need it.
Your data stays yours
We do not use your data to train models. SOC 2 Type I is in progress.
Bring your own AI model
Connect a key for Anthropic, OpenAI, DeepSeek, OpenRouter or Z.ai and model usage is billed to you by your provider, at your negotiated rate. Choose which model handles which step. If you would rather not manage a key during the beta, the platform default runs on Claude.
A FactoryOS subscription is not bundled AI usage
We do not resell model usage. Spend is attributed per tenant, per agent and per run, so you can see exactly where it goes.
Questions
What engineering leaders ask first
How it sits alongside the coding tools you already use, and who stays in control.
What is FactoryOS?
FactoryOS is a control plane for engineering work that AI agents help produce. It runs the process around the code: drafting a specification, reviewing the architecture, recording who approved what, and checking each change against the decisions your organisation has already made. It exists to answer four questions about any change, which a pull request on its own has never answered: who approved it and on what basis, whether it follows the architecture you agreed, which services and teams it touches, and what you decided last time this came up.
We already use Claude Code, Copilot or Cursor. Why would we need this?
Those tools make an engineer faster at writing a change. That is a different problem from deciding whether the change should exist, who signed off, and what else it affects. FactoryOS sits around your coding tools rather than replacing them: it invokes a coding agent to do the work, and it reviews pull requests whoever wrote them, including ones your own engineers opened. Your review layer should not belong to whichever vendor produced the code.
Does FactoryOS replace our engineers?
No, and we do not sell it that way. Engineers approve the architecture, review the pull request, and merge. What changes is where their attention goes: less time reconstructing why a change exists and what it touches, more time on the judgement calls. We make no claim that FactoryOS reduces headcount, because we have no evidence for it and it would make every engineer at your company an opponent of the tool.
Can an AI agent merge code that nobody has read?
No. Agents open pull requests and nothing more. The platform has no mechanism to merge code, and the connection to GitHub does not expose a merge operation at all, so this is a structural property rather than a setting somebody can switch off later. A human merges, every time.
How much control do we keep over what agents are allowed to do?
Every approval gate starts as human required, for every customer. Relaxing one is a policy decision that needs a second security administrator to approve, and the change is itself recorded in the audit log. You can also pin a gate to human required permanently, regardless of how well the agents perform, which is how regulated teams keep architecture and code review human by rule rather than by preference.
What happens when an agent gets something wrong?
We assume it will. An agent proposes an architecture and a person approves, rejects or asks for changes before any code is written; an agent opens a pull request and a person reviews and merges it. Every run has a hard spending cap and stops rather than continuing past it. Agents also cite the past decisions they relied on, and we measure how accurate those citations are in the test suite that gates any change to agent behaviour. The gates are designed around an agent being wrong sometimes, rather than around it being reliably right.
Does it work with the tools we already use?
FactoryOS works with Slack or Discord for chat, Jira or Linear for work tracking, Confluence or Notion for documents, and GitHub for code. Each workspace connects one tool per category. Requests and approvals happen in chat, specs and architecture are published to your docs tool, work items land in your tracker, and review arrives as a check on the GitHub pull request your engineers already look at.
See all questions covering how it works, quality, security and getting started.
Beta
Put one team's AI-written changes under control
FactoryOS is in beta. We are onboarding a small number of engineering organisations and working closely with each of them.
- 01Start with one teamConnect GitHub and the tools that team already uses. We set it up with you.
- 02Run it advisoryfactory-review reports on pull requests without blocking anything until you choose.
- 03Shape it with usWork directly with the founders. Pricing is agreed with the first teams, not guessed at.
Need SCIM provisioning, a security review or a rollout across many teams? Talk to us. Already have an account? Log in