Frequently asked questions

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.

It is built for engineering organisations large enough that changes cross team boundaries, and that are already running AI-assisted development at some volume. The people who get the most from it are the engineering leader who has to answer for AI-generated change, the manager who wants to know when work lands on another team, and the security stakeholder who needs an evidence trail. A small team shipping quickly with a coding assistant does not need this yet.

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.

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.

That is the honest failure mode for products in this category, and the design answer is that most engineers should rarely open it. For an engineer, FactoryOS is a check on their pull request and a message in Slack. The web application is mainly for the people doing approvals, governance and investigation. If your engineers are logging in daily, something has gone wrong.

There are four working roles rather than one general assistant. One drafts a specification with a product manager in Slack. One proposes an architecture and breaks it into tickets, citing decisions your organisation has already made. One implements a single ticket and opens a pull request. One reviews pull requests and reports back as a check on GitHub. Each role has its own limits on what it may spend and what it may touch.

Two things build up as you use it. A map of your organisation, inferred from GitHub, Jira and Slack, recording which services exist, who owns them and what depends on what. And a record of architectural decisions: what was chosen, what was rejected and why, captured when architectures are approved and when reviews are given. Agents read both before proposing anything, so their work reflects decisions you have already made rather than generic best practice.

Multiple people can run multiple pieces of work at the same time. Each piece of work runs independently and survives restarts, each ticket is implemented on its own branch, and tickets that depend on each other are ordered so the later ones wait for the earlier ones. Each organisation is fully separated from every other organisation.

Because each ticket is implemented on its own branch, two agents never write to the same place at the same time. If their changes genuinely conflict, that surfaces as an ordinary conflict on the pull request, and a person resolves it exactly as they would for two engineers. Nothing is force merged to make a conflict go away.

Three points, and we would rather be precise about where each one happens. A product manager approves the specification, in Slack. An engineer approves, rejects or requests changes to the proposed architecture, in the FactoryOS review workspace. An engineer reviews and merges the pull request, in GitHub through your normal review process. Only the architecture decision lives in FactoryOS itself; the other two stay in the tools your team already uses.

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.

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.

Every action that changes state produces an audit record. The log is append-only and each entry is linked to the one before it, so an altered or missing record is detectable rather than silent. You can search it in the application and verify a range of it, and pull requests carry the specification, architecture and reasoning the change was made under.

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.

No, and we treat that as a design constraint rather than a policy promise. What the platform learns is scoped to services and architecture, not to individuals, and we do not build per-person productivity metrics. The reason is self-interested as well as principled: the moment this data enters a performance review, people stop being candid in decision records, and the thing that makes the product valuable stops working.

Each agent is scored against a fixed set of examples with a published rubric before any change to its behaviour ships. An architecture, for instance, is scored on whether the options it considered are genuine rather than strawmen, whether the consequences name specific services instead of generalities, whether its citations are load bearing, and whether the resulting tickets are small enough to implement and testable. If a change to an agent drops the score, it does not ship.

Yes, in a specific and limited sense. Decisions accumulate: when an architecture is approved, what was chosen and what was rejected is recorded and is available to later work. So the longer you use it, the more of your organisation’s actual reasoning agents have in front of them. This is your accumulated context improving. It is not the underlying models learning from your code.

Not in the sense of shipping prebuilt knowledge about insurance, finance or construction. What it learns is your organisation’s own decisions, terminology and architecture, which in practice is more specific than an industry template would be. The trade-off is real: it starts without domain knowledge and builds it as you use it, rather than arriving with opinions about your sector.

Connecting GitHub, Jira, Slack and Confluence and getting to a first reviewed pull request is a short setup. Becoming genuinely useful takes longer, because the map of your organisation and the record of your decisions have to be populated and confirmed by people who know the answers. We do that with you rather than handing you a setup wizard. We would rather say so plainly than have you discover it in week three.

Relevant parts of your code and context are sent to a model provider to produce a change, through our gateway, which records what was sent and what it cost. Data in transit uses TLS 1.2 or above, and data at rest is encrypted on AWS. We provide the list of providers we rely on when you ask, and we tell you before that list changes.

Read the security overview

We do not use your data to train models. You keep ownership of your data, and the licence you grant us is limited to operating the service. If you connect your own model provider account, usage is billed to you by that provider under your own agreement with them.

Read the terms

Yes. You can connect your own provider key, which is held in a secrets vault, never stored in our database and never shown again once saved. Usage is then billed to you by your provider at your negotiated rate rather than resold by us. This is supported rather than required: if you do not configure one, the platform default is used.

Every record carries the organisation it belongs to, every query filters on it, and the database itself enforces the separation across the identity, tenancy, integration, policy, intelligence, cost, audit and registry data. Each organisation’s agent work runs in its own isolated execution space, and provider keys are held per organisation.

Access is through your existing single sign-on provider, so FactoryOS never stores your passwords. Roles determine what a person can do, from read-only through to the security administrator role required to change how much autonomy agents have, and permissions are denied unless a rule allows them. If you are running a security review, contact us and we will work through your questionnaire directly.

Read the security overview

FactoryOS connects to GitHub, Jira, Confluence and Slack today. Specifications are drafted in Slack and published to Confluence, work is tracked as Jira issues, and review arrives as a check on the GitHub pull request your engineers already look at. The intent is that most of your team meets FactoryOS inside tools they are already in.

For most of them, very little. Specifications are discussed in Slack, work stays in Jira, and review arrives as a check on the pull request in GitHub. The deliberate design goal is that a low-risk change passes through with no added friction at all. The people whose workflow changes most are those doing architecture approvals, because that step becomes explicit rather than implicit.

Yes, and we recommend it. You can begin with review only, where FactoryOS reviews pull requests your team and your existing agents already produce, without it running any work itself. Every gate starts human required, so nothing proceeds without approval until you decide otherwise, and you can enable it per repository and per team.

Keep them. FactoryOS deliberately does not run your builds, scan for vulnerabilities, manage incidents or replace your developer portal, and we have no plans to. Those categories already have good products in them, and a tool that inserts itself into your build pipeline becomes a dependency you have to think about every day.

FactoryOS is in beta, running as a hosted service on AWS. We are onboarding a small number of engineering organisations and shaping the product around what actually happens when agents write a meaningful share of the code. Pricing is not settled, so there is nothing to sign up to yet; we would rather agree it with the first teams than guess at it. One thing we can be clear about now is that a subscription does not bundle your AI usage: spend is attributed per organisation, per agent and per run, and hard caps stop a run before it overspends.