If we focus only on the technical aspects of a CI/CD delivery flow, cloud container platform and a set of agents, then this is a promising start. They are not, by themselves, an industrialised AI Product Development Lifecycle though.
I am seeing a trend across the industry of AI-enabled delivery which is increasingly framed as an “AI software factory or SDLC or PDLC”. For example QuantumBlack’s two-shift software factory, Thoughtworks’ AI Factory and builder harness, Accenture AI Refinery, and IBM and Red Hat’s AI Factory platforms all promise to industrialise the use of AI agents. Not all describe software delivery specifically; several address enterprise AI more broadly, but they share the same proposition: specialised agents and shared platforms can turn work into outcomes at industrial speed. This post wants to highlight that this is is only one part of the challenge and draw on the world of physical manufacturing. A factory is not simply a collection of workers and a conveyor belt; it is an engineered production system, designed, controlled and continually adapted for the products it is expected to make. There is a lot that needs to go into it before it can scale and be continuously adaptive.
TL;DR#
A physical manufacturing line is not built in the abstract. It is designed around real customer needs, a product family, expected variation, volume, tooling, materials, tolerances, inspection points, maintenance model and changeover process. Change the product or its quality requirements and the line must be adjusted. We have to be careful to not believe we have a really efficient hammer, when we do not even need nails!
The same is true for an Agentic xDLC. If a pipeline that moves a Jira requirement through specification, implementation and verification agents has a production-execution and process-control system: the local flow that gets work done. To operate it safely and at scale, it also needs product and production-system engineering, what we traditionally call Manufacturing Engineers, so software folks, you have not invented anything new here… sorry: the discipline that designs the flow for its intended product family, manages the shared platform primitives, and continuously improves it through live evidence.
So if we have the basic setup of something I can put an input in and get an output, we really do not have something that can scale yet. It is a early production cell yes, but there is more we need to consider. The architectural and operational work that turns it into a dependable production system that can scale still matters.
Learn from Manufacturing#
Most problems in life already have solutions. I have spent nearly three decades in FMCG and Oil & Gas. There is a great deal software and process engineering can learn from adjacent industries. This is not a new idea: software supply-chain risk, for example, borrowed heavily from supply-chain resilience. for example Yossi Sheffi’s The Resilient Enterprise remains an excellent reminder that systems become dependable through design for disruption, feedback and recovery, not by assuming every step will work first time.
Manufacturing does not say, “we have a conveyor belt?” and declare itself industrialised. It it a bit more complex and a more useful set of questions would be:
- What am I trying to Achieve (problem or oportunity) and for who (customer)?
- What family of products is this line intended to produce?
- What variation, demand rate and tolerances must it absorb?
- Where are the quality gates, buffers and points of human intervention?
- How will defects be detected, contained, traced and prevented from recurring?
- How will the line be balanced, changed over, maintained and improved?
I was trying to draw some parallels with Software and there are single-model, batch-model and mixed-model lines. As variation increases, changeover, scheduling and line balancing get harder. A line optimised for a stable, repeatable product is not automatically a good line for a high-variation product family. Actually this week I spent some time with Elena a friend that works for a company that manufactures small springs and I asked her if they close down in August for maintenance and and she said, 2 weeks, used to adjust the machines, maintenance (Tech debt) etc.
That is the useful analogy for AI xDLCs. There is no one universal “AI software factory” and push every product through it. A regulated payments change, a customer-facing journey, a low-risk internal service and a data migration do not carry the same context, evidence, risk appetite, approval needs or definition of done. They need different lifecycle harnesses (harness engineering: https://martinfowler.com/articles/harness-engineering.html), built from a common platform, not identical agent flows. Having said this, this is ideal for Platform thinking and creating the primitives that can be reused to scale.
There is one further distinction worth making. A paced line is only one production design. A stable, repeatable product family can justify a single-model lifecycle harness; controlled variants may need a batch or mixed-model harness with explicit changeovers. Where work is uncertain, discovery-led or highly variable, an asynchronous flow—with buffers, clear readiness criteria and human escalation—is more appropriate than forcing everything through one synchronised pipeline. Flexibility is not the absence of design; it is a deliberately designed capability. Stop here and thinking if you have any parallels with software?
What basic looks like#
A current pattern that is clear and valuable:
- A product manager captures a requirement in a work-management tool.
- A CI/CD delivery flow triggers an agentic workflow, running on a cloud container platform.
- Requirement agents turn the ticket into specifications.
- Specialist agents implement work from those specifications.
- Verification agents check the output.
- Some basic policies and guidance provide grounding.
This is more than a chatbot or someone prompting Kiro or Claude, It is a real flow of work, with specialised stations. But it is still mainly the production-execution architecture of an agentic system: agent runtime, orchestration, context/memory, tool use, model invocation, sandboxing and in-flow evaluation.
The risk is to mistake the visible sequence for the complete system. In manufacturing terms, we can see the stations and conveyor. We have not yet demonstrated the systematic quality system, maintenance regime, control room, traceability model, safety controls, engineering-change process or factory-wide operating model. Interesting sometimes we hight even entertain building the control room before we know what we controlling… which might have common components or not.
Nor should we describe this as a fully autonomous factory. It is closer to a mixed human–machine assembly system: agents can perform constrained work at particular stations, while people design the system, supply missing context, handle exceptions, authorise consequential actions and judge quality where automated evaluation is not sufficient. That is not a temporary embarrassment on the way to autonomy; it is part of the production design.
Manufacturing also gives us more useful language than the generic word bottleneck. A station can be starved: waiting for a usable requirement, missing context, a decision, access, data or an environment. Or it can be blocked: unable to hand its work to testing, assurance, deployment, evidence capture or operations. Both conditions are visible in agentic flows today. A faster implementation agent does not solve either problem; it can simply create a larger queue of work in progress downstream.
Reference architectures#
There are high level approaches and reference architectures for multi-agent setups that distinguishes the architecture of an individual agent and workflow from the platform capabilities required for many agents to operate together. These normally call out the production flow and the engineering system around it, which are both necessary, but they are different things.
| Manufacturing capability | AI xDLC equivalent | Current position | What must become systematic to scale | Example of what this means in practice |
|---|---|---|---|---|
| Workstations and process routing | Agent runtimes, orchestration and hand-offs | Present in the CI/CD and cloud-container flow | Explicit task, hand-off, retry, conflict-resolution and rollback semantics | A requirements agent emits a versioned specification; an implementation agent may accept only that schema; failed verification returns a structured defect, with a limited retry and an escalation path. |
| Tooling and fixtures | APIs, agent/tool connectors, CI/CD, work-management, test and deployment tools | Connected directly | Tool catalogue/registry, approved interfaces, scoped access and a policy-enforced tool gateway | An agent can query an approved source-control or knowledge service, but cannot deploy, alter a production record or call an unregistered tool without an explicit policy decision. |
| Product specification and work instructions | Requirements, specifications, prompts, standards and context | Requirement-to-specification conversion; basic guidance | Versioned, curated context layer; provenance; ownership; product-specific definitions of done | A payments change automatically receives the current API standard, data classification rules and required test evidence, not a generic bundle of unowned documents. |
| Safety interlocks | Runtime authorisation and guardrails | Early policy grounding | Agent and tool identities; just-in-time, just-enough access; action-level policy decision and enforcement points | A test agent may create an ephemeral environment; a release action requires a separate identity, evidence of passed controls and named approval where required. |
| Inspection stations and quality control | Runtime and offline evaluation | Verification agents | Representative test/evaluation suites, quality thresholds, in-line stopping rules and independent sampling of production traces | A proposed code change must pass functional, security and architecture checks; poor evaluator agreement or a high-risk finding stops the flow and routes it to a human. |
| Factory control room | Agent control plane | Largely absent as a coherent capability | Lifecycle management, central configuration, deployment standards, kill switches, circuit breakers, anomaly management and incident response | Operators can see which agent and model version ran, suspend a faulty workflow across products, and apply a tested configuration change centrally. |
| Traceability and batch records | Telemetry and immutable audit trail | Pipeline logs may exist | End-to-end trace of requirement, context, prompts, model/tool calls, decisions, approvals, artefacts and accountable owner | An auditor can trace a released change from the originating requirement through the evidence, agent decisions, human approvals and deployed artefact. |
| Maintenance and continuous improvement | Observability, learning and workflow redesign | Ad hoc | Measured defect analysis, controlled changes, regression evaluation, prompt/tool/flow improvement and retirement of unsafe agents | Repeated specification defects lead to a controlled update to the context, evaluator or routing rule, followed by regression testing against prior cases. |
| Capacity and cost control | Agent FinOps | Not systematic | Per-session and per-agent token/resource budgets, attribution, thresholds and controlled degradation | A complex task has a cost and time budget; exceeding it triggers a smaller fallback flow or human review rather than uncontrolled agent recursion. |
The primitives to consider inter alia are the platform building blocks: an agent control plane; runtime authorisation(IAM); AI asset registries; observability; evaluations; and guardrails. Its data plane includes agent and tool gateways, multi-agent coordination and model gateways. These are not optional enterprise decoration. They are the common primitives that let independent agent flows operate predictably, securely and with evidence.
NOTE: for a future post I would like to mention we need to to start considersing “Agentic Collaboration Surfaces” as place or points at which agents meet with humans or humans with humans or agents with agents… and all combos. Birgitta Böckeler from Thought work mentions as an aspirtation is to see how we can cust down MD by 50% given there is just too much to review and we have a the false sense of security. Listen to this podcast as it shows how complex this is: https://www.thoughtworks.com/en-gb/insights/podcasts/technology-podcasts/what-harness-engineering
Difference between a feature change and the design of a new system#
There is a material difference between extending an existing application and creating a new system that happens to include an AI xDLC or “factory” component.
If a team asks for a new field and a drop-down in an established application, much of the consequential design has already been done. The change sits within known boundaries: perhaps a three-tier architecture, established API patterns, infrastructure-as-code, a CI/CD delivery flow, managed data services and an API management layer. The feature still needs good product, UX, data and security design, but it is primarily design within an established system. The team can draw on existing contracts, patterns, controls and deployment pathways.
Now compare that with an idea to build a bank-wide system that optimises controls, some automated and some deliberately involving human judgement, using AI-xDLC primitives where they add value. That is not a feature request with a pipeline attached. It is system and production-system design. Before agents can efficiently execute, someone must decide the operating model, control taxonomy and evidence model; the system boundaries and integrations; the trusted facts and human decision points; which primitives must be deterministic; what may be probabilistic; and how the system will be operated, assured and improved.
The distinction matters because a well-built AI delivery flow cannot supply this missing architecture by itself. It can accelerate execution after the key design decisions are sufficiently made. Asking agents or a large number of engineers to discover that architecture independently during implementation creates rework, inconsistent decisions and the illusion of progress.
Execution and engineering#
The production-execution and process-control system executes a particular change:
requirement → specification → build → verify → deploy or return for rework
That loop should be deliberately narrow, product-aware and measurable. It needs a clear contract at every station: inputs, permitted tools, expected outputs, acceptance criteria, escalation conditions and a named accountable human.
The key question is not whether every agent is productive in isolation. It is whether the whole lifecycle is balanced across requirement clarification, design, generation, testing, security, release, observation and remediation. Improving a generation station that is already faster than design assurance, test-environment provisioning or production validation increases queueing; it does not necessarily increase trustworthy delivery.
Product and production-system engineering designs, improves and governs the line itself:
observe → evaluate → learn → change the harness → validate the change → operate again
Gartner describes this as interconnected observability and evaluation, quality and alignment, continuous learning, FinOps, and security/guardrail loops. Crucially, these are not reports produced after the fact. Their findings should alter the next action in a run when necessary, and drive a controlled redesign of the flow between releases. We not there yet folks.
For example, a verification agent that frequently catches architectural violations should not simply create more tickets. The engineering system should determine whether the defect came from poor requirement translation, missing enterprise context, an inadequate architectural gate, an unsafe tool path or a weak model/tool combination. It should then change the relevant work instruction, context, policy, evaluator or flow design, and prove that the change improves outcomes without creating regressions.
That is maintenance (Remember the 2 weeks downtime in a factory?). It is also Day 2 operations. Separating a team that builds the line from a team that runs it would recreate the communication cost and broken feedback loops that DevOps was meant to remove. The people responsible for the lifecycle harness must see its production behaviour and be accountable for improving it. Read that again please. What we have been trying to pull together, Dev and Ops for the last decades, we can very easily pull apart again… if we not careful. Having said this I strongly believe that needs to be designed as a true platform where certain primitives are composible and where are opniated yet flexible to unlock innovation.
Architect the line before scaling it.#
I read this post by Paul Graham " Do things that don’t Scale" unfortunately too late in my career, but better late than never. https://www.paulgraham.com/ds.html. Basically spend some time testing out the problem space and solution. Design? Architecture? come to mind!
This is not about a person who merely chains agents together. It is an architect (or architectural thinking) and process engineer for an AI production-and-operations system.
This is close to Fred Brooks’s argument in The Mythical Man-Month. His principle of conceptual integrity, sometimes expressed as an “aristocracy of architects”, is that a small group must hold the whole-system view and make the consequential design decisions. Otherwise, many capable implementers each make locally reasonable choices and the result becomes fragmented.
The lesson is not to create a distant architecture committee, nor to complete design once and throw it over the wall. It is to ensure a small, accountable cross-functional capability holds the system view, turns it into clear contracts and reusable primitives, and stays connected to production evidence. Only then should a broader execution capability, engineers and agents, be asked to work at speed. That is how we avoid wasting scarce engineering capacity, or expensive agent capacity, on repeatedly rediscovering architecture, policy and intent.
This role, or more realistically, a small cross-functional capability, designs the product-family lifecycle harness: the work decomposition, boundaries between agents, context contracts, human decision points, quality measures, permissions, recovery paths and evidence model. It decides which elements must be deterministic, which may be probabilistic, and where autonomy ends.
Three complementary responsibilities emerge (more post to come on this one):
- Agentic solution/process architect: designs the end-to-end flow for a product family, including quality gates, failure handling, human approval and changeover between kinds of work.
- Agent platform architect/engineer: provides the shared platform primitives: control plane, gateways, workload identity, registries, observability, evaluation services and guardrails, so each new flow does not reinvent safety and operations.
- Quality, controls and reliability engineer: engineers evaluation datasets, acceptance tests, policy-as-code, traceability, operational SLOs and evidence; uses production signals to drive corrective action. Basically a AI Reliability Engineer (tm)!
These are ordinary but evolving architectural and engineering disciplines, combined with product and domain knowledge. They are not “AI unicorn” roles. The crucial point is that they architect both the flow and the operating system around the flow. Today they unicorns and these are the roles of the future?
A practical definition of ready to scale#
We should say an AI xDLC is ready to scale only when it can answer, with evidence (look familiar… same as physical manufacturing lines):
- Fit: Which product families and risk classes is this flow designed for, and which are out of scope?
- Control: Which agent used which identity, context and tool; under which policy; and who approved high-impact actions?
- Quality: How do we know the output is correct, secure, architecturally compliant and useful, not just syntactically plausible?
- Resilience: How does the flow stop, recover, retry, escalate and contain a bad or runaway action?
- Learning: Which production signals lead to an actual, tested improvement in context, tools, policies, evaluations or the flow?
- Economics: What did a completed outcome cost, including its subagents and rework, and what happens when a budget is breached?
- Accountability: Can we reconstruct the end-to-end decision and artefact trail for an auditor, an incident review or a customer-impacting defect?
- Flow: Where is the lifecycle starved, blocked or unbalanced, and what evidence shows that a local improvement has increased end-to-end trustworthy throughput rather than merely moved the queue downstream?
If the answer is “we have CI/CD, a cloud container platform and agents,” we have the beginnings of a production-execution flow. That is worth celebrating, but it is not the end state.
The goal is a portfolio of product-family lifecycle harnesses, running on a shared, governed agent platform and managed as an observable production-and-operations system. Architect the line for the product. Operate it as part of the product lifecycle. Then let evidence, not novelty, tell us where to increase autonomy.
Sources#
- Gartner, Reference Architecture Brief: LLM-Based AI Agent (Inner Architecture), 7 November 2025, ID G00835094; and Reference Architecture Brief: Multi-Agent Platform (Outer Architecture), 27 May 2026, ID G00843422. These informed the distinction between agent/workflow design and the shared platform capabilities required to operate multiple agents. The terminology and argument in this post are the author’s own.
- Microsoft, Multi-agent Reference Architecture: orchestration, agent registry and lifecycle history, versioned knowledge, state, monitoring, tool authentication and authorisation, error handling and agent refactoring as the estate grows.
- Frederick P. Brooks Jr., The Mythical Man-Month, anniversary edition: conceptual integrity and the role of system architects.
- Automation in Manufacturing (provided reference material): automated flow lines, inspection, maintenance, changeover and line-balancing concepts.
- McKinsey QuantumBlack, The symbiotic enterprise: A new model for growth, 18 June 2026: the “two-shift software factory.”
- Thoughtworks, The operating system for enterprise AI, 10 July 2026: AI Factory and the builder harness.
- Accenture, AI Refinery: a platform for developing and running multi-agent AI solutions.
- Red Hat, Red Hat AI Factory with NVIDIA: a hybrid-cloud platform for building, deploying and managing AI at scale; see also IBM’s expanded NVIDIA collaboration, 16 March 2026.