{"slug": "what-is-an-ai-software-factory-lessons-from-3-client-deployments", "title": "What Is an AI Software Factory? Lessons from 3 Client Deployments", "summary": "Camplight has deployed three AI software factories for clients over the past nine months, generalizing that implementation experience into a public model called Nest, built on the company's open-source OrgOps infrastructure. Camplight states the three client deployments are covered by NDAs and that the names, budgets, timings, and performance figures shown in Nest's screenshots are illustrative rather than published client results. Camplight defines an AI software factory as a managed system that turns defined requirements into validated software changes using AI agents, connected tools, automated checks, and human oversight, and argues the distinction from a coding agent such as GitHub's Copilot cloud agent is the system around execution.", "body_md": "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…\n\n**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.**\n\nIf 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.\n\nJeez, that was a lot… Let’s hold our breath for a little bit more.\n\nIt includes the agent workflow: how work starts, what context is available, what actions are permitted, and how results are accepted.\n\nAt Camplight, we have spent the last nine months building software factories and have deployed **three for clients**.\n\nThose implementations are covered by NDAs. We cannot publish the client systems yet.\n\nInstead, 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).\n\nThis is not a prediction about something we might eventually build. It is a way to explain work we are already doing.\n\nThe 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.\n\nWhen 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…\n\nThe useful question is not whether your company needs an interface identical to Nest.\n\nIt is whether you can answer the operational questions behind it.\n\nThis 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.\n\n## What makes an AI software factory different from a coding agent?\n\nA 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.”\n\nThe distinction is the **system around the execution**.\n\nIn the model we use, a software factory connects a business request to the context, tools, people, validation, and release process needed to deliver it.\n\n**Defined intent -> relevant context -> execution -> verification -> required approval -> release -> feedback**\n\nDifferent 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)\n\nAn 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.\n\n**A coding agent performs work. A software factory defines how that work becomes an accepted, accountable software change that anyone can trigger.**\n\nThe important bit here is “anyone” but we’ll come back to this later.\n\nThe 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/)\n\n## What the best AI software factories have in common: seven building blocks\n\nWe 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.\n\nThese are evaluation criteria for a leading AI software factory, not a requirement to build seven new applications.\n\n### 1. An operational dashboard: what is happening, and what needs attention?\n\nThe 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.\n\nWhat is running? What has finished? What is waiting for review? Which issues need intervention? What has execution cost? asl pls?\n\nNest brings those questions together through **Spend, Tasks, Issues, Active Projects, and Community**.\n\nThe 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.\n\nFor an executive, I would also distinguish **activity metrics** from **delivery metrics**.\n\n“Agents completed 100 tasks” describes activity. It does not establish that the company received 100 useful outcomes.\n\nMy preferred evaluation would combine accepted changes, elapsed delivery time, review effort, rework, and execution cost. For comparable work, one useful measure is:\n\n**Cost per accepted change = total execution and review cost for a defined batch of work / accepted changes in that batch**\n\nThat calculation should include failed attempts and retries, not only the successful final run.\n\nThe 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.\n\n**The management question:** Can someone see where their attention would be most useful right now?\n\n### 2. Agent management: organize capabilities around the work\n\nAn agent directory should do more than list names and avatars. It should make responsibilities understandable.\n\nWhat does each agent do? Where does it operate? Who owns its configuration? Is it active, paused, or waiting for help?\n\nThis is where the question of **horizontal versus vertical agents** becomes useful, provided we define it.\n\nA 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.\n\nThese are design choices, not competing religions.\n\nA 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.\n\n[*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.\n\nI would not begin by recreating the company’s org chart as a collection of bots.\n\nI would begin with an outcome, identify the capabilities it requires, and decide where those capabilities should live.\n\n**The management question:** Does each agent have a clear responsibility and a human owner?\n\n### 3. Agent configuration: instructions are only part of the system\n\nThe Agent Details screen makes an important distinction visible: an agent is more than its prompt.\n\nIn Nest, its configuration includes a description of its responsibility, model selection, tool connections, skills, workspace, and additional instructions.\n\nConsider an implementation agent. “Write good code” is not a sufficient operating instruction.\n\nIt 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.\n\nThere is also a boundary that deserves particular attention:\n\n**Instructions describe what an agent should do. Authorization controls determine what it can do.**\n\n“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.\n\nThat is why configuration is an operating concern, not just a prompt-writing exercise.\n\n**The management question:** What can this agent access and change, and who is accountable for that decision?\n\n### 4. Projects: keep the context attached to the outcome\n\nThe Projects screen shows how the pieces come together around a specific piece of work.\n\nIn 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.\n\nThe important part is not that several agents appear in one conversation.\n\nIt is that the request, evidence, recommendation, human decision, and next artifact belong to the **same project context**.\n\nThat creates a clearer handoff than asking each participant to reconstruct the work from a fresh prompt.\n\nThe 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.\n\nFor 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.\n\nThis is what I mean by organizing work around outcomes rather than isolated conversations.\n\n**The management question:** Can you trace a delivered change back to the request, evidence, and decisions that produced it?\n\n### 5. Team assembly: start with the capabilities the task requires\n\n“Meet your team” is how Nest presents the initial collection of agents.\n\nThe screenshot includes strategy, research, product, design, and engineering capabilities. The user can keep or customize the proposed team.\n\nThis is a way to make configuration approachable. It is not a prescription that every workflow needs five agents.\n\nA documentation update and a new product initiative should not automatically receive the same execution structure.\n\nOur 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.\n\nThat 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.\n\nThe avatars help distinguish capabilities. They do not transfer accountability away from the people operating the system.\n\n**The management question:** What does this work actually need, and what complexity can we leave out?\n\n### 6. Shared skills and automations: make useful work reusable\n\nA completed project can produce more than its immediate deliverable.\n\nIt can also leave behind a useful workflow, connector, instruction set, or agent skill.\n\nNest’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.\n\nThat is the distinction between sharing an answer and sharing the ability to produce useful answers repeatedly.\n\nBut reuse needs ownership.\n\nFor 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.\n\nAnd sharing a workflow should not mean silently sharing the creator’s credentials or access rights.\n\n**Reuse the capability. Reauthorize its access.**\n\nThe Community screen is a visible expression of this idea: useful work should be able to travel beyond the person who first created it.\n\n**The management question:** When one team improves a workflow, can other teams benefit without losing control of how it runs?\n\n### 7. Human-agent huddles: make intervention focused and practical\n\nThe Huddle screen brings people and agents into a focused session around the current work.\n\nIn 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.\n\nThe idea is not to put every agent task inside another meeting.\n\nIt is to create an effective intervention point when the work needs clarification, a tradeoff, or a decision.\n\nImagine 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.\n\nThe resulting decision should stay attached to the project. A huddle should reduce ambiguity, not create another place where context disappears.\n\nFor consequential actions, spoken feedback also needs to remain distinct from authorization. Discussing a deployment is not necessarily approving one.\n\n**The management question:** When execution reaches a judgment call, can the right people intervene without restarting the work?\n\n## What sits underneath the interface: verification and release controls\n\nA dashboard, agent roster, and shared conversation do not by themselves make a software factory.\n\nThe output still needs to be checked.\n\nFor 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.\n\nThe agent reporting “completed” is an event in that process, not the final authority on whether the result is acceptable.\n\n[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.\n\nOur human-led framing leaves room for different levels of automation.\n\nSome work can proceed through automated checks. Other work needs an explicit decision from an engineer, product owner, or another accountable person.\n\n**Autonomy is a policy choice for a particular workflow, not a blanket promise that everything should happen without people.**\n\n## How to start building an AI software factory inside your organization\n\nI would not start by commissioning the entire Nest interface.\n\nStart with one bounded, recurring software-delivery workflow where success can be evaluated.\n\nThat 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.\n\nThen 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?\n\nConnect 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.\n\nRun a limited evaluation, inspect the outputs, and compare accepted results with the baseline. Expand only when the evidence supports expansion.\n\nThis also keeps the business conversation concrete.\n\n**Which recurring outcome could we deliver more effectively if execution, context, and verification were connected?**\n\nThree 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.\n\n## Questions executives ask about AI software factories\n\n### Is an AI software factory the same as an AI factory?\n\nNot 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.\n\n### Does a software factory replace engineers?\n\nThat 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.\n\n### Does every company need a multi-agent platform?\n\nNo. 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.\n\n### What should you compare when evaluating top AI software factory platforms?\n\nCompare 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.\n\n### How much does an AI software factory cost?\n\nA 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.\n\nBut a word from the kitchen – it can cost anyware between 40k to 250k EUR.\n\n### Is Nest one of the client deployments?\n\nNest 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.\n\n## From three deployments to a model we can share\n\nAfter nine months of building and deploying software factories, the public story we can tell is not a tour of a client environment.\n\nIt is the operating model.\n\nHow 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.\n\nNest makes those questions visible.\n\nThe central idea is simple:\n\n**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.**\n\nExplore the complete **Nest – Human-Led, AI-Powered Work** case study on Behance:\n\n[Btw you can view the Nest case study on Behance](https://www.behance.net/gallery/256020685/Nest-Human-Led-AI-Powered-Work)\n\n### Exploring a software factory inside your organization?\n\nTalk to Camplight about the software-delivery workflow you want to improve. We take on only 1-2 engagements each quarter.", "url": "https://wpnews.pro/news/what-is-an-ai-software-factory-lessons-from-3-client-deployments", "canonical_source": "https://camplight.net/ai/ai-software-factory/", "published_at": "2026-09-23 09:57:06+00:00", "updated_at": "2026-09-23 10:30:24.535700+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools", "developer-tools"], "entities": ["Camplight", "Nest", "OrgOps", "GitHub", "Copilot cloud agent", "GitLab"], "alternates": {"html": "https://wpnews.pro/news/what-is-an-ai-software-factory-lessons-from-3-client-deployments", "markdown": "https://wpnews.pro/news/what-is-an-ai-software-factory-lessons-from-3-client-deployments.md", "text": "https://wpnews.pro/news/what-is-an-ai-software-factory-lessons-from-3-client-deployments.txt", "jsonld": "https://wpnews.pro/news/what-is-an-ai-software-factory-lessons-from-3-client-deployments.jsonld"}}