Building a Software Factory with AI Agents at Scale

cursor · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: AI-assisted software development

Cursor needed a practical operating model for scaling from individual pair-programming agents toward software-factory workflows where fleets of agents can build, test, review, and learn across codebases.

Constraints:

• Agents need codebase structure, rules, tests, and accessible tooling before they can operate safely with high autonomy.
• Sensitive areas such as authentication, payments, databases, and security should remain under human decision control.
• Parallel agents need isolated, reproducible environments to avoid cross-branch side effects.
• As humans review less code directly, they need outcome artifacts, memories, and guardrails to manage many agents.

Architecture

Cursor's software-factory model combines codebase primitives, dynamically emerging rules, tests, skills, MCP-accessible tools, isolated VM-based cloud agents, automated review, feature flags, code-owner automation, daily review, and continual learning. The factory moves humans from synchronous coding toward asynchronous management of scoped work, agent fleets, artifacts, guardrails, and accumulated context.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  human-manager[Human Manager] --> agent-fleet[Agent Fleet]
  human-manager --> rules-and-guardrails[Rules and Guardrails]
  agent-fleet --> codebase-primitives[Codebase Primitives]
  agent-fleet --> rules-and-guardrails
  agent-fleet --> skills-and-mcp-tools[Skills and MCP Tools]
  agent-fleet --> isolated-cloud-vms[Isolated Cloud VMs]
  isolated-cloud-vms --> verification-harness[Verification Harness]
  agent-fleet --> verification-harness
  agent-fleet --> review-automation[Review Automation]
  review-automation --> artifact-review[Artifact Review]
  verification-harness --> artifact-review
  artifact-review --> human-manager
  review-automation --> learning-memory[Learning Memory]
  learning-memory --> agent-fleet

Components

Data flow

A human provides intent and scope, agents use codebase primitives, rules, skills, and MCP/tool context to implement in isolated environments, tests or UI automation verify work, review automations inspect changes, feature flags make rollout reversible, and feedback from PR comments or transcripts becomes rules/memory for later runs.

Why this architecture

Cursor argues that factory-scale agent work needs the same management stack as a human organization: structured work units, guardrails, verifiable outputs, parallel environments, learning loops, and human control over high-risk decisions.

Scale

• Cursor described a progression from level-two/three pair-programming workflows to level-four delegation and eventual software factory operation.
  “most people uh adopting the AI tools um are like at somewhere between level two and level three where you have a pair programmer”transcript, stated
• The proposed factory goal is 24/7 agent work with more code from fewer resources.
  “throughput you probably want to create more code with like less resources. Um you can run agents 247. You don't have to uh rely on humans that need sleep and food and eat and all that. Um you can just like have more agents. Um another like thing with the factory is like you”transcript, stated
• The speaker framed scaling as moving from five to ten to fifty to one hundred agents.
  “all this. Um so how do you like actually take it from like five agents to 10 agents to 50 to 100 uh agents and um the thing is again um not looking at code is going to be a real thing if the models get better and they are getting”transcript, stated
• Cursor cloud agents used separate VMs, enabling large-scale parallelism once environment setup is solved.
  “support this. But once you have it set up properly, you can scale this to like 100 or a thousand agents. I'm not sure how many we are running today, but I bet it's like multiple thousands a day. Um just agents running in the same or like copies of the codebase.”transcript, stated
• Cursor was likely running multiple thousands of agents per day.
  “100 or a thousand agents. I'm not sure how many we are running today, but I bet it's like multiple thousands a day. Um just agents running in the same or like copies of the codebase.”transcript, stated
• An agentic code-owner flow was designed around code-owner precision being right about 80% of the time and bottlenecking the remaining 20%.
  “we had code owners in our codebase and they were kind of right most of the time like 80% of the time but for these 20% of the time they caused a lot of bottlenecks”transcript, stated

Alternatives considered (roads not taken)

Let agents operate freely without rules, checks, or hooks

Rejected because: The speaker says probabilistic, off-the-rails behavior signals that the factory needs stronger guardrails.

Install every available Cursor rule for the stack

Rejected because: Rules should emerge from observed agent failure modes rather than being blindly copied into every project.

Shared local workspace for many parallel agents

Rejected because: Separate VMs avoid side effects across branches, databases, caches, and user-management state.

Humans personally remembering to turn every correction into a rule

Rejected because: Continual-learning automation extracts memories and learnings from transcripts and stores them as rules.

Patterns

multi-agent-orchestration (agent architecture)

Cursor frames factory work as scoping and parallelizing many agents, then aggregating and managing their outputs at higher abstraction.

tool-use-orchestration (agent architecture)

Agents are given skills and MCP/tool access so they can use feature flags, external context, Slack, Datadog, Notion, Linear, and other systems.

guardrails-io-filtering (governance)

Rules, hooks, checks, sensitive-code restrictions, tests, and feature flags constrain what agents can safely change.

eval-driven-development (quality)

The factory depends on verifiable systems where agents run unit, integration, UI, browser, and review checks against their own work.

agent-memory (learning)

Transcript- and PR-comment-derived memories/rules preserve human feedback for future agent behavior.

Tradeoffs

Autonomy controls

Chose Rules, checks, hooks, tests, and sensitive-area restrictions over Unbounded agent freedom.

Rationale: The factory still wants agent freedom, but high-risk areas and off-the-rails behavior need explicit control points.

Parallel execution environment

Chose Separate cloud VMs per agent over Shared local workspace with git worktrees and shared services.

Rationale: VM isolation costs more setup work but avoids shared-state side effects and scales to many concurrent agents.

Human role at factory scale

Chose Manager/architect reviewing outcomes and scoping work over Worker reviewing every code diff synchronously.

Rationale: The factory's throughput comes from moving human judgment to intent, scope, guardrails, and outcome artifacts rather than raw implementation.

Code-owner bottleneck handling

Chose Agentic code owner risk assessment over Blocking every code-owner-owned PR on a human in another timezone.

Rationale: Low-risk PRs can be unblocked automatically while high-risk PRs can still pull in people with relevant prior context.

Gotchas (what bit them)

Agents become probabilistic and go off the rails when the factory lacks guardrails.

Root cause: Free-form agent autonomy without rules, hooks, checks, and known codebase patterns loses determinism.

Resolution: Build dynamic rules from observed failures and pair them with tests, hooks, and verifiable outputs.

Parallel agents can interfere with each other's state when they share workspaces or services.

Root cause: Branches, databases, caches, and user-management state need separation to keep concurrent work reproducible.

Resolution: Spawn agents in separate cloud VMs with their own app, database, internal tooling, and codebase copy.

Agents have completion bias and can finish local tasks without preserving long-term architecture quality.

Root cause: Models continue existing references and optimize for completing the immediate task rather than reasoning about future evolution.

Resolution: Keep humans in architectural planning/review, point agents to good references, and use later refactoring/abstraction passes.

Humans become unable to understand every agent's work as agent count rises.

Root cause: Asynchronous background work and many parallel agents outstrip direct code-following.

Resolution: Aggregate changes upward, review artifacts and outcomes, and manage scope like a growing organization.

Evaluation

Cursor's factory guidance emphasizes verifiable systems: tests, browser/UI interaction, automated PR review, Bugbot, videos of agents testing work, daily review summaries, code-owner risk checks, and feedback-derived learning.

Metrics: Unit/integration/UI test pass/fail · Browser interaction/video verification · PR review comments · Risk level of code-owner changes · Human review comments · Number of parallel agents

Outcomes

• Cursor had parts of the product and company running fairly autonomously, but the speaker was explicit that the full factory was still a work in progress.
• Cloud agents, separate VMs, self-testing, automated review, code-owner automation, daily review, and continual learning were presented as concrete pieces of the factory.
• The speaker reported likely multiple thousands of agents running per day.

The talk is practical guidance rather than a single completed deployment report; its strongest scale evidence is Cursor's own cloud-agent use and the speaker's estimate of multiple thousands of agents per day.