# What Is an AI Software Factory? Lessons from 3 Client Deployments > Source: > Published: 2026-09-23 09:57:06+00:00 I’m writing this in bed after a long day of trying to explain something that seems obvious, but every time I articulate it, it feels vague. I think the current blog article the best one on explaining what a software factory is! But you tell me… **An AI software factory is a managed system (like cloud servers are managed hardware) for turning defined requirements into validated software changes using AI agents, connected tools, automated checks, and human oversight.** If you are comparing the best AI software factory platforms, do not start with the number of agents or the interface. Start with whether the system connects intent, context, execution, verification, approval, release, and feedback. Jeez, that was a lot… Let’s hold our breath for a little bit more. It includes the agent workflow: how work starts, what context is available, what actions are permitted, and how results are accepted. At Camplight, we have spent the last nine months building software factories and have deployed **three for clients**. Those implementations are covered by NDAs. We cannot publish the client systems yet. Instead, we have generalized our implementation experience into **Nest**: a public model that makes the operating questions and building blocks visible without revealing confidential deployments. It’s based on our [open-source OrgOps infra](https://github.com/camplight/orgops). This is not a prediction about something we might eventually build. It is a way to explain work we are already doing. The screenshots below present a unified, generalized model rather than any of the three confidential client environments. They do not imply that every deployment contains every interface shown. I want to add a disclaimer that the names, budgets, timings, and performance figures are illustrative, not published client results. When comparing leading AI software factory platforms, treat these screens as an evaluation framework rather than a universal product checklist. I guess I will have to write another blog article in couple of months because the space is moving so quick… The useful question is not whether your company needs an interface identical to Nest. It is whether you can answer the operational questions behind it. This practical guide builds on our analysis of [Uber’s AI software factory](https://camplight.net/ai/ubers-ai-software-factory-lessons-business-leaders-2026/) and our examination of [dark-factory readiness](https://camplight.net/ai-powered-development/your-team-isnt-ready-for-the-dark-factory/). Here, we focus on what the system contains, how work moves through it, and what leaders need to govern. ## What makes an AI software factory different from a coding agent? A coding agent can perform substantial development work. For example, [GitHub’s Copilot cloud agent](https://docs.github.com/en/copilot/concepts/coding-agent/coding-agent) can investigate a repository, plan changes, modify code, and run tests in a development environment. A software factory therefore cannot be distinguished simply by saying, “Our AI does more than autocomplete.” The distinction is the **system around the execution**. In the model we use, a software factory connects a business request to the context, tools, people, validation, and release process needed to deliver it. **Defined intent -> relevant context -> execution -> verification -> required approval -> release -> feedback** Different parts of that flow can use different mechanisms. Some require an agent. Others are better handled by ordinary code, an existing pipeline, or a person. (hint: usually the bottle neck is around verification because evals and guardrails are a moving target) An AI software factory also does not replace continuous integration and delivery. [CI/CD already provides mechanisms](https://docs.gitlab.com/ci/) for building, testing, and deploying changes; the factory needs to connect agent-generated work to those mechanisms. **A coding agent performs work. A software factory defines how that work becomes an accepted, accountable software change that anyone can trigger.** The important bit here is “anyone” but we’ll come back to this later. The term itself is used in different ways. [Cortex describes an organizational software-delivery system](https://www.cortex.io/post/what-is-an-ai-software-factory), while [StrongDM describes a deliberately non-interactive approach](https://factory.strongdm.ai/) without human code review. Our scope is a **human-led AI software factory**, with explicit decisions about autonomy, verification, and intervention. This is because nobody has reached [full dark state](https://camplight.net/ai-powered-development/dark-factory-test-verification/) ## What the best AI software factories have in common: seven building blocks We organized Nest around seven areas that leaders can use to compare AI software factory platforms: operational visibility, agent management, configuration, projects, team assembly, reusable capabilities, and human collaboration. These are evaluation criteria for a leading AI software factory, not a requirement to build seven new applications. ### 1. An operational dashboard: what is happening, and what needs attention? The dashboard is where a person should be able to understand the state of the factory without reconstructing it from conversations. I loved my millennial days with mIRC but chatting is super tiring. What is running? What has finished? What is waiting for review? Which issues need intervention? What has execution cost? asl pls? Nest brings those questions together through **Spend, Tasks, Issues, Active Projects, and Community**. The important design choice is to connect visibility to action! A blocked task should lead to its context. A spending anomaly should lead to the relevant workflow. A review request should lead to the artifact and the criteria for accepting it. For an executive, I would also distinguish **activity metrics** from **delivery metrics**. “Agents completed 100 tasks” describes activity. It does not establish that the company received 100 useful outcomes. My preferred evaluation would combine accepted changes, elapsed delivery time, review effort, rework, and execution cost. For comparable work, one useful measure is: **Cost per accepted change = total execution and review cost for a defined batch of work / accepted changes in that batch** That calculation should include failed attempts and retries, not only the successful final run. The dashboard also includes small celebrations and shared work from the community. That is deliberate. I want this environment to show what people are accomplishing together, not just a growing queue of machine activity. **The management question:** Can someone see where their attention would be most useful right now? ### 2. Agent management: organize capabilities around the work An agent directory should do more than list names and avatars. It should make responsibilities understandable. What does each agent do? Where does it operate? Who owns its configuration? Is it active, paused, or waiting for help? This is where the question of **horizontal versus vertical agents** becomes useful, provided we define it. A horizontal capability might support several teams, such as a reusable research workflow. A domain-specific capability might operate within one product, repository, or business process. These are design choices, not competing religions. A shared capability can reduce duplicated work. A capability close to one domain can have a clearer context and tighter boundaries. The right choice depends on the work and the organization. [*Team Topologies* provides a useful reference](https://teamtopologies.com/key-concepts) for thinking about team boundaries, shared platforms, and interaction modes. Applying those ideas to agents is an architectural analogy, not a claim that its human team types map directly onto AI roles. I would not begin by recreating the company’s org chart as a collection of bots. I would begin with an outcome, identify the capabilities it requires, and decide where those capabilities should live. **The management question:** Does each agent have a clear responsibility and a human owner? ### 3. Agent configuration: instructions are only part of the system The Agent Details screen makes an important distinction visible: an agent is more than its prompt. In Nest, its configuration includes a description of its responsibility, model selection, tool connections, skills, workspace, and additional instructions. Consider an implementation agent. “Write good code” is not a sufficient operating instruction. It needs a defined change, relevant repository context, acceptance criteria, access to the appropriate tools, and an expected output. That output might be a proposed code change accompanied by test results, rather than permission to release directly. There is also a boundary that deserves particular attention: **Instructions describe what an agent should do. Authorization controls determine what it can do.** “Do not touch production” should not be the only thing preventing production access. Permissions need enforcement outside the model, with access scoped to the task and high-impact actions subject to appropriate approval. [OWASP’s agent-security guidance](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) explicitly addresses least privilege, tool authorization, and human approval controls. That is why configuration is an operating concern, not just a prompt-writing exercise. **The management question:** What can this agent access and change, and who is accountable for that decision? ### 4. Projects: keep the context attached to the outcome The Projects screen shows how the pieces come together around a specific piece of work. In the illustrated example, a person asks the team to validate a pricing strategy. A research agent supplies analysis. A strategy agent proposes a direction. The person selects an option. A design agent starts the pricing-page mockup. The important part is not that several agents appear in one conversation. It is that the request, evidence, recommendation, human decision, and next artifact belong to the **same project context**. That creates a clearer handoff than asking each participant to reconstruct the work from a fresh prompt. The project also carries a budget, status, files, and the agents involved. A new participant should be able to understand what has been decided and what remains unresolved. For an actual software release, the workflow would need to continue beyond the mockup: implementation, testing, review, and the organization’s release controls. A convincing design artifact is not the same thing as a validated production change. This is what I mean by organizing work around outcomes rather than isolated conversations. **The management question:** Can you trace a delivered change back to the request, evidence, and decisions that produced it? ### 5. Team assembly: start with the capabilities the task requires “Meet your team” is how Nest presents the initial collection of agents. The screenshot includes strategy, research, product, design, and engineering capabilities. The user can keep or customize the proposed team. This is a way to make configuration approachable. It is not a prescription that every workflow needs five agents. A documentation update and a new product initiative should not automatically receive the same execution structure. Our design principle is to assemble the smallest useful set of capabilities around the problem. Add specialization where it improves quality, control, or clarity, not simply because more agents look impressive. That is consistent with [Anthropic’s engineering guidance](https://www.anthropic.com/engineering/building-effective-agents) to start with the simplest workable solution and introduce more elaborate agentic structures only when their benefits justify the additional cost and latency. The avatars help distinguish capabilities. They do not transfer accountability away from the people operating the system. **The management question:** What does this work actually need, and what complexity can we leave out? ### 6. Shared skills and automations: make useful work reusable A completed project can produce more than its immediate deliverable. It can also leave behind a useful workflow, connector, instruction set, or agent skill. Nest’s Community area makes those capabilities discoverable. The illustrated examples include a weekly product pulse and a recurring project digest: automations another team could discover and adapt rather than rebuild. That is the distinction between sharing an answer and sharing the ability to produce useful answers repeatedly. But reuse needs ownership. For a shared capability, I would want to know what it does, who maintains it, what inputs it expects, which systems it accesses, and how changes to it are tested. Teams also need a way to understand whether they are using the same version. And sharing a workflow should not mean silently sharing the creator’s credentials or access rights. **Reuse the capability. Reauthorize its access.** The Community screen is a visible expression of this idea: useful work should be able to travel beyond the person who first created it. **The management question:** When one team improves a workflow, can other teams benefit without losing control of how it runs? ### 7. Human-agent huddles: make intervention focused and practical The Huddle screen brings people and agents into a focused session around the current work. In the illustrated onboarding redesign, a person reviews the artifact and gives spoken feedback. Speech-to-text turns that feedback into messages the agents can work with. The idea is not to put every agent task inside another meeting. It is to create an effective intervention point when the work needs clarification, a tradeoff, or a decision. Imagine a redesign that has passed its checks but still misses what the product owner intended. Rather than continuing a chain of disconnected corrections, the relevant people can inspect the current artifact, clarify the issue, and direct the next change in one session. The resulting decision should stay attached to the project. A huddle should reduce ambiguity, not create another place where context disappears. For consequential actions, spoken feedback also needs to remain distinct from authorization. Discussing a deployment is not necessarily approving one. **The management question:** When execution reaches a judgment call, can the right people intervene without restarting the work? ## What sits underneath the interface: verification and release controls A dashboard, agent roster, and shared conversation do not by themselves make a software factory. The output still needs to be checked. For software changes, I would expect the implementation to define acceptance criteria, run appropriate tests and security checks, retain execution evidence, and connect to a controlled release process. The exact controls should reflect the potential impact of the change. The agent reporting “completed” is an event in that process, not the final authority on whether the result is acceptable. [StrongDM’s published software-factory work](https://factory.strongdm.ai/) makes this distinction particularly concrete: its team describes using separate scenarios and simulated service environments to evaluate generated software, including concerns about agents satisfying tests without satisfying the intended behavior. That is one implementation approach, not a requirement to copy its entire architecture. Our human-led framing leaves room for different levels of automation. Some work can proceed through automated checks. Other work needs an explicit decision from an engineer, product owner, or another accountable person. **Autonomy is a policy choice for a particular workflow, not a blanket promise that everything should happen without people.** ## How to start building an AI software factory inside your organization I would not start by commissioning the entire Nest interface. Start with one bounded, recurring software-delivery workflow where success can be evaluated. That might be a well-defined category of maintenance changes, test improvements, or internal-tool updates. Establish how that work happens today: its volume, elapsed time, review effort, and common failure points. Then define the operating boundaries before increasing autonomy. What can the agent read? What may it change? What evidence must it produce? When does it stop? Who accepts the result? Connect the workflow to the tools you already use wherever that is practical. A factory does not become more valuable simply because every component is new. Run a limited evaluation, inspect the outputs, and compare accepted results with the baseline. Expand only when the evidence supports expansion. This also keeps the business conversation concrete. **Which recurring outcome could we deliver more effectively if execution, context, and verification were connected?** Three deployments in nine months is our implementation experience. It is not a standard delivery timeline or a promise that every organization will need the same scope. ## Questions executives ask about AI software factories ### Is an AI software factory the same as an AI factory? Not necessarily. Infrastructure companies such as [NVIDIA use “AI factory” to describe computing infrastructure](https://blogs.nvidia.com/blog/ai-factory/) optimized for AI workloads, including training and inference. This article concerns a different subject: the operating system for producing software with agents, tools, and people. ### Does a software factory replace engineers? That is not the model presented here. Engineers remain responsible for architecture, technical standards, verification, and the reliability of the delivery system. We are describing how execution can be delegated, not how accountability disappears. ### Does every company need a multi-agent platform? No. Our recommendation is to match the system to the work. A narrow workflow may need one agent or ordinary automation. Additional agents and coordination mechanisms should earn their place through a demonstrable benefit. ### What should you compare when evaluating top AI software factory platforms? Compare seven capabilities: operational visibility, clear agent ownership, governed configuration, project context, right-sized team assembly, reusable skills and automations, and focused human intervention. The strongest platform is not the one with the most agents. It is the one that can turn defined intent into verified, traceable outcomes within your organization’s access, review, and release controls. ### How much does an AI software factory cost? A credible estimate needs a defined workflow and operating boundary. We would scope integration work, model and tool usage, execution environments, verification, human review, and ongoing maintenance. The sample budgets in the Nest screenshots are not pricing benchmarks or client cost disclosures. But a word from the kitchen – it can cost anyware between 40k to 250k EUR. ### Is Nest one of the client deployments? Nest is the generalized public model we use to explain the operating patterns. It is not a public replica of any one client’s system. The actual deployments remain confidential. ## From three deployments to a model we can share After nine months of building and deploying software factories, the public story we can tell is not a tour of a client environment. It is the operating model. How work enters the system. How agents receive context. How access is controlled. How people review results. How useful capabilities are reused. How the organization understands what it is getting back. Nest makes those questions visible. The central idea is simple: **The software factory is not the collection of agents. It is the system that turns their work into outcomes your organization can accept and stand behind.** Explore the complete **Nest – Human-Led, AI-Powered Work** case study on Behance: [Btw you can view the Nest case study on Behance](https://www.behance.net/gallery/256020685/Nest-Human-Led-AI-Powered-Work) ### Exploring a software factory inside your organization? Talk to Camplight about the software-delivery workflow you want to improve. We take on only 1-2 engagements each quarter.