An agentic software factory is a system where AI agents build, test, and deliver software through a repeatable workflow. People define what to build and the checks it must pass before release. For data products and internal tools, agents also need business context: what key terms mean, which data to use, and which policies apply. Atlan, the Context Layer for AI, supplies that context to coding agents.
In practice, an agentic software factory needs five connected components:
- Specification: Defines what to build, the expected result, the boundaries of the task, and how success will be judged.
- Agent harness: Coordinates the agents, models, tools, permissions, execution steps, and checkpoints required to complete the task.
- Context and memory: Supplies current code and business context while preserving validated decisions, corrections, and lessons from earlier work.
- Verification and observability: Tests the output and records tool calls, changes, failures, costs, and other evidence needed to understand each run.
- Controlled learning loop: Uses outcomes and human feedback to improve specifications, context, evaluations, and harness rules for future tasks.
What does an agentic software factory do from end to end?
An agentic software factory is an end-to-end delivery model where AI coding agents move work from specification through planning, coding, testing, review, and release. Teams define the outcome, acceptance criteria, risk limits, and release rules. The factory supplies the tools, context, permissions, and checks needed to complete the work within those boundaries.
BCG Platinion describes a similar division: agents build, test, and ship software, while people define business intent and review outcomes. It treats codified institutional knowledge, including business rules, as a requirement: agents are only as effective as the knowledge they can access.
Spotify shows the bounded version in production. By November 2025, its background coding agent, used mainly for code migrations, had produced more than 1,500 merged pull requests, and the existing review and merge process stayed the same. That is evidence for agent-written changes under human review, on tasks where the repository holds most of the context.
For data products and internal tools, agents also need approved definitions, trusted sources, dependencies, owners, and policies. Atlan, the Context Layer for AI, can supply this governed context through a context layer for the SDLC, helping an agent find the correct revenue definition and source before writing a model.
The factory extends AI agents across the SDLC, but not every release has to be autonomous. The ADLC vs. SDLC distinction covers how teams organize agent work alongside the software lifecycle.
How does a software factory differ from a dark factory?
Both models can use similar agents, tools, and delivery pipelines. A software factory may retain human approval at specification, exception, or release gates. A dark factory removes people from routine implementation and code review.
Dan Shapiro, CEO of Glowforge, describes the dark factory as the highest level in his January 2026 automation model: “It’s a black box that turns specs into software.” This is a practitioner model, not a formal industry maturity standard.
In a dark factory, control shifts into specifications, the agent harness, independent evaluations, permissions, telemetry, exception handling, and rollback mechanisms. Harness engineering maintains these controls as models, tools, and workflows change.
The division of responsibility looks like this:
| Model | Agent responsibility | Human responsibility |
|---|---|---|
| Coding assistant | Complete bounded tasks within a developer-led workflow | Direct the work and review changes |
| Agentic software factory | Execute a staged workflow from an approved specification to a release candidate | Define intent, approve risk boundaries, inspect release evidence |
| Dark factory | Turn approved specifications into verified software without routine human code review | Design specifications, validation systems, and exception rules |
The practical question is which gates can be automated and what evidence can replace line-by-line review.
What does an agentic software factory workflow look like?
An agentic software factory moves an approved request through intake, specification, agent execution, verification, and merge approval. For a dbt model that reports net revenue by region, the workflow carries the request, business rules, code changes, and evidence to the merge decision.
Each stage produces an output that the next stage can use:
| Stage | What the factory does | Human decision |
|---|---|---|
| Work intake | Records the request, owner, scope, priority, and affected systems | Decides whether the task is suitable for agent execution |
| Specification | Converts the request into expected outputs, constraints, and acceptance criteria | Approves revenue rules, regional boundaries, and the expected result |
| Agent execution | Retrieves the relevant code and approved business context, writes or modifies the code, and runs tests and other checks in an isolated environment | Resolves missing definitions, conflicting context, or unexpected scope changes |
| Verification | Runs code, dependency, security, and business-outcome checks, then assembles the evidence | Reviews failures and decides whether the evidence is sufficient |
| Merge gate | Presents the code diff, test results, retrieved context, dependencies, and rollback plan | Authorizes the merge or allows it under a previously approved automation policy |
With an event-driven architecture for AI agents, a predefined signal can automatically start the workflow. A production error may trigger a debugging task, while a security alert, a dependency release, or a platform change may queue an update. The event scopes the task but does not authorize a merge or deployment; the change must still pass the required checks and merge gate. Deduplicate repeated alerts, cap how many tasks one signal can open, and set a spend limit per run, or a noisy incident turns into a queue of duplicate patches.
The workflow may use one agent or several. Agent composability can separate planning, implementation, and verification, and ReAct and Plan-and-Execute agents organize the steps differently. Every agent still needs approved inputs and release rules.
What inputs does an agentic software factory need for each task?
A task that touches business data needs three connected inputs: a specification, code context, and enterprise context. A dependency bump or a formatting fix may need only the first two. Keeping them distinct helps teams identify an unclear request, an incomplete code context, or a missing business meaning. Selecting the right information for each stage is part of context engineering.
Specifications define the expected result
A specification defines the outcome, constraints, and acceptance criteria. For the net-revenue model, it should state the reporting grain, expected output, required checks, and approved rules for refunds, credits, dates, and exclusions.
Birgitta Böckeler’s analysis of spec-driven development distinguishes specifications for a particular change from codebase context used across tasks.
Code context explains how the project works
Code context covers the repository structure, existing models, dependencies, conventions, test patterns, and build commands. It helps the agent find the right files and make a compatible change.
Tools differ in how they assemble code context for agents. Repository context often doesn’t record why Finance approved one revenue definition or source, and where it does, the agent still has to know which file is the authority. This is the context gap coding agents encounter in enterprise data work.
Enterprise context establishes business correctness
Enterprise context supplies approved definitions, sources, owners, dependencies, and policies. It tells the agent which definition and data to use, who resolves ambiguity, and which downstream assets may be affected.
A context layer beneath the agent harness makes this information reusable across tasks. Without one of these inputs, the factory can produce code that runs but delivers the wrong result.
Why do data products expose gaps in the factory?
A data product can run cleanly and still answer the wrong business question, even when the factory built it exactly to spec.
Consider a task to build a dbt model that reports net revenue by region. The first correct step is usually to find and reuse the certified net-revenue metric, not to derive a new one. If the factory cannot retrieve the approved definition or certified source, the agent cannot reliably choose the data or revenue logic, and it may build a duplicate metric.
A dbt build confirms that the model runs. Generic tests check unique keys and non-null values, and dbt unit tests, available from dbt v1.8, check the SQL logic against mock inputs and expected outputs. All of them can pass while the model reads an unapproved source, because a unit test proves only the refund and credit rules its author believed were approved. If the same incomplete context informs both the code and the tests, they encode the same error.
Enterprise data work requires agents to interpret metadata, documentation, and project code, not simply generate valid SQL. According to the Spider 2.0 paper (revised March 2025), an o1-preview code-agent framework solved 21.3% of 632 workflow problems derived from enterprise database use cases, compared with 91.2% on Spider 1.0. The Spider 2.0 leaderboard now lists specialized agent systems above 90% on its Snowflake setting, so read the paper’s figure as a measure of task difficulty, not a model ceiling. That gap is why enterprise text-to-SQL requires more than schema access.
A semantic layer for AI agents can provide metric definitions, and an MCP server for dbt can expose supported operations. Neither, by itself, records whether a definition or source is approved for this task. In many teams that approval lives in a reviewed pull request with a named code owner, so the factory has to check whichever record is authoritative.
What does a factory with reliable enterprise context look like?
A factory has reliable enterprise context when agents can retrieve approved definitions, sources, dependencies, owners, and policies. An enterprise context layer makes this information reusable across tasks.
For the net-revenue model, that context holds four elements:
- Approved meaning and source: The definition, exclusions, effective date, and certified dataset.
- Dependencies: Data lineage for AI shows upstream and downstream relationships, while data contracts record structural and quality expectations.
- Ownership: The person or team that resolves ambiguity and approves definition changes.
- Policy controls: Classification, permitted-use, and access rules, including requirements for handling PII in AI pipelines. Retrieved descriptions are data for the agent, never instructions that change its permissions.
Model Context Protocol provides a standard interface for resources and tools. MCP for data lineage can expose a dependency graph, but identity and permissions are enforced by the server and the source systems, not by the protocol.
In context management across multi-agent systems, each agent receives a role-scoped slice of the same approved definitions, so the planner and the implementer don’t drift apart. The verifier’s expected results are the exception. They come from the definition owner and sit outside the implementation agent’s retrieval path, because a verifier that reads the same mistaken definition will agree with the mistake. Shared definitions without per-agent copies are one reason why agents need an enterprise context layer.
The factory should record the context each run retrieved (the payload and when), tool results, decisions, and corrections. The distinction between a context graph and a knowledge graph is useful here: business facts record what is known, while decision traces show how it was applied. A correction becomes context only after the definition owner approves it. If review finds credits counted twice, the fix lands as a new owner-maintained test case and a proposed definition change, and agents can’t retrieve the new definition until the owner signs off.
How do you verify business correctness alongside code correctness?
Code tests show whether the dbt model compiles, runs, and passes technical assertions. Business verification asks whether it used the approved definition and source to produce the expected result. Test that result against cases approved independently of the implementation agent.
Justin McCarthy, then co-founder and CTO of StrongDM, describes the risk in StrongDM’s software factory account: “A test, stored in the codebase, can be lazily rewritten to match the code.” His team uses end-to-end scenarios outside the codebase as a holdout set. This practitioner approach keeps the implementation agent from changing the expected outcome simply to pass. What matters is that the agent can neither edit nor read the oracle; where the scenarios are stored is secondary.
Passing checks is still not proof. In September 2026, Spotify reported that an automated dependency upgrade passed its checks and still failed in production. Tyson Singer, its head of technology and platforms, wrote that once AI raised the volume of change, verification became the constraint.
For the net-revenue model, the release checks should require the following evidence:
| Check | Evidence required before approval |
|---|---|
| Business result | Region- and period-level results match an owner-maintained fixture set that includes refunds, credits, late adjustments, and boundary dates |
| Source and definition | The model uses the certified source and the net-revenue definition in force when the run started |
| Dependency impact | Lineage lists known affected models and dashboards, and consumers outside connected systems are assessed separately |
| Policy behavior | The new model doesn’t expose restricted columns through a view or join that bypasses existing masking |
| Failure handling | Missing, outdated, or conflicting definitions stop the task and route it to the responsible owner |
Run these checks against context as well as code. Context testing for AI agents verifies that the agent retrieved current definitions, sources, and tool results. Rerun it after a source or definition changes because context drift can make unchanged code incorrect.
The release record should capture the code, specification, retrieved context, tool results, tests, policy decisions, and approvals. These enterprise agent guardrails let reviewers reconstruct the run; the merge decision stays at the gate.
How does Atlan supply the context layer for an agentic software factory?
Atlan supplies governed business context before code is written and impact evidence when the change is reviewed. For the net-revenue task, it connects the approved definition to relevant data, dependencies, owners, and policies, then makes that context available to agents.
| Factory requirement | Atlan capability | Practical contribution |
|---|---|---|
| Find the approved source and assess downstream impact | Enterprise Data Graph and Data Lineage | Connect definitions and owners to assets and column-level dependencies. For pull requests that change dbt models, Atlan can list affected downstream assets in GitHub or GitLab. |
| Create missing documentation for review | Context Agents | Use query history, lineage, and BI activity to draft descriptions, READMEs, and SQL intelligence. Drafts stay drafts until an owner reviews them. |
| Assemble and test task-specific context | Context Engineering Studio | Build a context repository and evaluate it against business questions and verified answers before deployment. |
| Reuse approved business meaning | Context Repos | Package linked assets and a use-case-specific semantic model as a reusable context repository for agents. |
| Deliver context to agents | Context Lakehouse and Atlan MCP | Deliver governed context through MCP, SQL, and APIs. Atlan MCP scopes every call to the connected identity’s Atlan permissions. |
Context Engineering Studio requires tenant enablement through an Atlan account team. After a linked source changes, teams regenerate and retest the Context Repo, and they confirm support for the required deployment target and interface.
These capabilities govern and deliver context, while the agent harness controls execution, tests, and release gates. Atlan permissions govern metadata; the warehouse still enforces its own grants when the agent runs a query. In Context Engineering Studio, a repository’s Activity tab shows what changed upstream since it was last built, and who changed it. The run record should still store the payload the agent actually retrieved and when, so a reviewer can reconstruct the change after the definition moves on.
Which workflows should enter an agentic software factory first?
Start with a bounded, reversible task whose correct result is known, such as generating documentation, adding tests from approved examples, or modifying a low-risk transformation in development. More consequential data engineering workflows for agents, such as repairing production pipelines, need stronger evidence and recovery controls before they qualify.
Before giving a workflow more autonomy, move it through five steps:
- Choose a verifiable outcome: Name the owner, approved result, and rollback path.
- Pin the inputs and permissions: Record the specification, code revision, retrieved context, tools, and allowed actions.
- Bound the execution: Restrict the repository, environment, credentials, and systems the agent can change.
- Review the evidence: Check the code, business result, dependency impact, policy behavior, and rollback readiness.
- Improve the next run: Use failures and corrections to update specifications, context, evaluations, or harness rules.
The guide to implementing an enterprise context layer covers storage, delivery, lifecycle management, and governance.
Expand only when the first workflow consistently meets its criteria and recovers safely from failure.
Real stories from real customers: Context layers behind enterprise agents
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
Joe DosSantos, VP, Enterprise Data and Analytics, Workday
"Atlan is our context operating system to cover every type of context in every system including our operational systems."
Sridher Arumugham, Chief Data Analytics Officer, DigiKey
FAQs about agentic software factories
1. What is an agentic software factory, in one sentence?
An agentic software factory is a software delivery model where AI agents build and verify software and features from specifications while people define outcomes, constraints, and approval rules.
2. How is a software factory different from a dark factory?
An agentic software factory keeps people at specification, exception, or release gates. A dark factory aims to automate routine implementation and code review after the specification is approved. People still define specifications, validation systems, risk limits, and exception rules.
3. What are the stages of an agentic software factory, and where do humans approve?
A practical workflow moves from intake and specification to agent execution, verification, and a merge gate. People approve the task, expected result, risk limits, and any ambiguity the agents cannot resolve. The final merge may require direct approval or proceed under a previously approved policy for low-risk changes.
4. How is it different from CI/CD or a platform engineering team?
An agentic factory runs on top of CI/CD rather than replacing it. The agent interprets the task and writes or revises the change, and the existing pipeline still builds, tests, and gates it. A platform engineering team may build and operate the shared infrastructure, controls, and interfaces that make this possible.
5. Who coined the term, and is anyone running one in production?
The available sources do not establish a single inventor of the phrase. Dan Shapiro described a dark-factory end state in January 2026, StrongDM published its factory approach in February, and BCG Platinion described an enterprise operating model in March. Spotify’s production background-agent work demonstrates bounded agent delivery with existing review controls.
6. What context do coding agents need beyond the codebase?
Agents need the approved business definitions, certified sources, owners, dependencies, and policies relevant to their task. They also need the current versions of those inputs and evidence of which context was retrieved. Repository instructions and schema names alone may not contain that meaning.
7. Can a software factory build data pipelines, dbt models, and data products safely?
For bounded dbt work, yes, when its inputs, permissions, independent tests, and a tested recovery path are in place. It should verify business results as well as schema and code properties. Stateful streaming jobs and production backfills are a poor first fit, because rolling back code doesn’t undo emitted events or rewritten tables.
8. How do you verify agent output when no human reads the code?
Run independently maintained scenarios, expected-result checks, security tests, and operational monitoring. Preserve the code, specification, retrieved context, tool results, and approvals needed to investigate a failure. Passing these checks supports a scoped release decision, but it cannot prove every possible behavior is correct.
9. What are the main risks?
Agents can select the wrong source, apply stale business rules, generate tests that repeat the same error, or receive excessive permissions. A high volume of generated changes can also hide failures and increase downstream impact. Reduce these risks by restricting access, testing business outcomes independently, logging each run, and routing exceptions to the appropriate people.
Sources
- BCG Platinion: The Agentic Software Factory, March 2026
- StrongDM: Software Factories and the Agentic Moment, February 2026
- Dan Shapiro: The Five Levels: from Spicy Autocomplete to the Dark Factory, January 2026
- Spotify Engineering: 1,500+ PRs Later, November 2025
- Spider 2.0, November 2024, revised March 2025
- Birgitta Böckeler: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl, October 2025
- Spotify Engineering: AI Changed How Spotify Builds, September 2026
- dbt Labs: Unit tests, current docs
- Spider 2.0 leaderboard, accessed October 2026
