TL;DR
An AI software factory moves a request through connected agent stages to a reviewed pull request, with people approving at set points. I read the public docs for five of them in October 2026: Forge, Factory, Augment Cosmos, Kiro and GitHub's Copilot cloud agent. They differ most on one question, which is whether a human signs off before any code exists. This guide defines the term, runs all five through four tests, and ends with demo questions you can reuse.
Getting Started: What an AI Software Factory Is
A coding assistant helps one developer inside one session. You type, it suggests, you accept or reject. A software factory looks after everything around that session: where the request came from, what spec it was built against, who reviewed it and what record it leaves.
Most vendors now use the word, and they mean slightly different things by it. So I stopped comparing feature lists and scored each platform on four tests instead:
- What starts the work. A ticket, a prompt, a spec or a legacy repository.
- Where a human approves. Before code exists, after it, or only at the pull request.
- Where context lives. Whether the next run remembers what the last one decided.
- Where agents run and what they leave behind. Your network or the vendor's, and how much of the trail you can export.
I did not benchmark any of these, so nothing here ranks speed or code quality. Everything below comes from each vendor's own docs and enterprise pages as they stood in October 2026.
To keep the tests concrete, I'll use one hypothetical team throughout: a platform group at a regional bank with a fifteen-year-old Java monolith, about forty developers and an audit team that asks who approved what. It is invented, but the questions it raises are the ones I hear from real enterprise teams.
How the Five Platforms Compare on the Four Tests
Before the detail, here is the shape of the field. Copilot's cloud agent and Factory start from tasks and put the human checkpoint at the end. Augment starts from events such as tickets and alerts, with checkpoints you configure. Kiro starts from a spec and gates it in the editor. Forge starts from intent and gates four stages before any code is written.
None of that makes one of them better. It tells you where each one assumes your process already works, which is the more useful thing to know before a demo.
GitHub Copilot Cloud Agent as the Baseline Most Teams Own
If your bank's code already lives on GitHub, the cloud agent is the lowest-change option, and its guardrails are more specific than I expected. According to GitHub's own risk documentation, only users with write access can trigger it. It pushes to a single branch, either the pull request's own branch or a new copilot/ branch, and it stays subject to branch protection and required checks.
It cannot mark a pull request ready for review, approve it or merge it, and the person who asked for the work cannot approve it either. Workflows do not run until someone with write access clicks Approve and run. By default it also runs CodeQL, checks new dependencies against the GitHub Advisory Database and runs secret scanning on its own output. Commits are signed, name the requester as co-author and link to the session log, and administrators get audit log events.
For our bank, that is a solid answer to "who merged this." What it does not give you is a stage before code. Work starts from an issue or a prompt, and the human checkpoint is the pull request. If the issue was vague, the review is where you find out.
Kiro Puts the Spec Inside the Editor
Kiro, from AWS, is the clearest spec-first tool in this group. A feature spec produces three files: requirements.md, design.md and tasks.md. In the requirements-first workflow you confirm the requirements before Kiro writes the design, and the design leads to a task list you can run one task at a time or all together. When you run everything, Kiro builds a dependency graph and runs independent tasks concurrently.
The detail I would watch is the Quick Spec path. It generates all three files in one pass with no approval gates. It is convenient, and it is the setting I would keep out of regulated work, because it removes the one stage that makes the tool interesting.
Specs run in the Kiro IDE and on the web, where the agent can implement the plan and open a pull request. I did not read Kiro's enterprise administration docs for this piece, so I am treating it as a strong spec workflow rather than a complete factory. For the bank, the open question is how that workflow scales across forty developers, which the public pages do not answer.
Factory Runs Agents Under Managed Settings
Factory's unit of work is the Droid. Its deployment documentation describes three patterns: cloud-managed, where Factory's cloud is the control plane and model traffic can go through your own gateways; hybrid; and fully airgapped, where Factory's cloud is not reachable at runtime. Droids run on laptops, CI runners, VMs, Kubernetes clusters and airgapped networks.
Governance is expressed as a hierarchy of managed settings covering model access, command policies, MCP allowlists, hooks, sandbox policy and retention. Droids emit OpenTelemetry metrics to collectors you own, and Factory lists SOC 2 Type II, ISO 27001 and ISO 42001 on the same pages.
What I did not find is an approved-spec stage before the agent starts. The controls describe what a Droid may do once work is assigned. If the bank's weakness is unclear requirements, they would have to build that stage themselves. If the weakness is control over what agents can touch, this is one of the most detailed runtime policy models I came across.
Augment Cosmos Runs Ticket-to-PR Loops You Configure
Augment describes Cosmos as the layer that connects agents, codebase context and workflows. Requests enter as tickets, pull requests or alerts, and each loop has a trigger, an outcome and a human checkpoint you define. The building blocks include Experts, which are task-specific agents, a Context Engine, a model router called Prism, and either isolated cloud VMs or a self-hosted daemon that runs agents on your machines while Cosmos stays the control plane.
Experts, environments and loops are versioned, and budget controls cap spend per automation or per user. Augment's security pages list SOC 2 Type II and ISO/IEC 42001 and say it never trains on customer proprietary data.
Augment also publishes a case study from its own engineering team and says the figures are observations, not a controlled experiment. I would read any vendor's internal numbers that way, and I will say the same about the figures in the next section. Its advice to start with a code review loop is sound, because a pull request gives you a clear trigger and a natural place for a person to look.
Forge Gates Four Stages Before Any Code Exists
Forge is the one I had to read most carefully, because it is built around the gap the other four leave open. The pattern so far is that nothing before the code is required to be approved. Copilot and Factory begin at a task. Augment begins at an event. Kiro has a spec stage but lets you skip its gates.
Forge's default New Build path runs Intent, PRD-Spec, Architecture, User Stories and Testing, then saves an Application Context snapshot. A modernization project adds an Assessment stage at the front, where Forge reads a Git repository, a local folder or a ZIP and reports the current state before anyone writes a goal. For our bank's monolith, that is the part I would test first.
Here is the number I found most useful. The docs say Intent, requirements, Architecture and User Stories each need an explicit Approve & Continue, while Testing and Assessment need none. Counting from the quick-start guides, that is four of five stages gated in the default New Build journey and four of six in the default modernization journey. All four gates sit before code. Tenants can switch optional stages on and off, so check it against your own configuration.
Two details in the approval model are easy to miss. Approval records a version without locking the artifact. And regenerating an upstream artifact clears the approvals downstream, so a changed requirement cannot quietly keep an old architecture sign-off. For an audit team, that second behaviour is the interesting one.
{INFOGRAPHIC: Horizontal flow of six rounded boxes labelled Intent, PRD-Spec, Architecture, User Stories, Testing, Application Context. Under the first four, a filled circle with a check mark and the words "Approve & Continue". Under Testing, an empty circle and "No approval step". Under Application Context, "Saved snapshot". A thin bracket under the first four boxes reads "Four gates before any code exists". Footer: "Source: Forge documentation, October 2026".}
Code comes from the Coding Agent, which implements an approved user story in a linked Git repository. It pushes a forge/wo-{id} branch and opens a pull request when your Git provider allows it. The connector needs push and pull request permissions, and the run screen lets you skip the test phase or the AI review phase, so I would decide up front who may flip those. If your developers prefer their own editor, the same stories open in an IDE over MCP.
Opsera's own figures for Forge are vendor-reported and I have not verified them. Its site describes a cloud to on-prem Kubernetes conversion at Senao Wireless going from seven months to one week, and a Belcorp workload dropping from two to six weeks to about an hour. Its FAQ also says customer code and architecture data are not used to train foundation models. My demo question would be which stages are enabled in my tenant, since the docs note that policy can hide the optional ones.
How I Would Pick Based on Where Delivery Breaks
If nobody can explain the legacy system, start with a tool that begins with assessment. Forge's modernization journey opens with Assessment and a ForgeScore health report before any goal is set.
If the codebase is healthy and the pain is a pile of tickets, alerts and reviews, look at Factory or Augment, since both start from events and tasks.
If you are on GitHub and want the smallest change, turn on the Copilot cloud agent and tighten branch protection first. If you want specs in the editor and are not ready for a platform, try Kiro on one team.
One position I will defend: if your team has no written specs today, adding agents moves the bottleneck to the review queue. Pick the tool that makes you produce the spec, or build that habit before you buy anything.
Five Questions I Would Ask in Every Demo
- Which stages need a human click, and which run without one?
- If an upstream artifact changes, what happens to approvals downstream?
- Where do the agents run, and what leaves my network?
- Can I pull the full record for one change, from request to merge?
- What stops an agent from reaching production credentials or deploy commands?
Where to Start With Your Own Shortlist
The common thread across all five is that the checkpoint moves earlier as the tool gets more spec-driven. Copilot checks at the pull request, Factory and Augment at configured gates around tasks, Kiro at the spec, and Forge at four stages before code. Which position is right depends on whether your delivery problems begin in requirements or in review.
My suggestion is to pick two tools that sit at different points on that line, run the same small change through both, and compare the record each one leaves. If you want to see the spec-first end up close, the Forge docs introduction walks through the New Build and modernization journeys stage by stage, which is the quickest way to check the approval behaviour yourself.
FAQ
Does a software factory replace Copilot or Cursor?
Forge runs alongside the assistants a team already uses and supplies the intent and context around them. Augment and Factory ship their own agents, so with those you are choosing between agent runtimes.
Do Forge's approvals lock an artifact once approved?
No, Approval records the current version and moves the journey forward. If you regenerate an upstream artifact, the approvals downstream of it are cleared.
Can an agent merge its own pull request on GitHub?
Not in Copilot's cloud agent. It cannot approve or merge, and the person who requested the work cannot approve it either.
Is Kiro's Quick Spec suitable for regulated teams?
I would not use it there. It generates requirements, design and tasks in one pass with no approval gates, which removes the review step regulated teams rely on.
Which of these can run fully airgapped?
Of the five, Factory documents a fully airgapped deployment. Augment's agents can run on your machines while the control plane stays with the vendor, so it sits in between.
How current is this comparison of the tools?
It reflects public pages read in October 2026. Vendors change these pages often, so confirm any detail your decision depends on.
Top comments (0)