The AI software factory operating model

An AI software factory operating model defines how people, agents and shared platform capabilities work together to deliver and operate software. It establishes who owns outcomes, how work flows, which standards apply, what agents may do independently, and how quality, cost and performance are assessed.

Small, accountable product teams direct the work. A shared factory supplies the capabilities, standards and controls that let agents carry out more of it. Team size follows from the product's complexity and the factory's maturity.

In What is an AI software factory?, I described the lifecycle and the shared capabilities supporting it. The organisational question is who those people are, what decisions they own and how they work together.

What operating model are you starting from?

There isn't one settled AI software factory operating model. But there are existing cloud operating models to build on, with responsibilities for security, delivery and running services already assigned. The starting point is how your organisation does that work today.

Microsoft's Cloud Adoption Framework describes three arrangements. Organisations can combine them across different parts of their business.i

• Centralised: one team manages cloud governance, security and operations for the workloads. That makes consistent controls easier to establish, but delivery can queue behind the central team as demand grows.
• Shared management: platform teams provide shared services and enforce baseline policies. Product or workload teams build and operate their services within those controls. The division of responsibility needs to be clear.
• Decentralised: teams manage their own cloud environments, governance and operations. They have more local control, but each needs the expertise and capacity to maintain those responsibilities.

I would use shared management as the starting point for the factory described here. Product teams own customer outcomes and their services. A platform team provides capabilities they can reuse, while security, architecture and other specialists establish standards with the teams.

This assumes some working foundations. Cloud accounts, identity, networking, delivery pipelines and operational responsibilities need owners. AWS's cloud operating model already covers architecture and patterns, observability, security operations, operational reporting and financial management. These are capabilities to assess and build on.i

What changes when you delegate work to agents?

An AI software factory is a different way to work, with a lot of focus on governance, preparation and measurement. People define the outcome and the constraints, agents carry out more of the work, and the team assesses the evidence before accepting the result.

That changes where people spend their time. Before delegating, they need to make the requirements, domain knowledge and engineering standards clear enough for an agent to use. During execution, the factory needs to control which systems the agent can access and which actions it can take. Afterwards, the team needs evidence that the work meets the requirements and produces the intended outcome.

Governance includes the quality of the design, the architecture, the engineering and the customer experience, as well as security and compliance. Each needs an accountable owner, an agreed standard and a way to assess the result. An agent completing its task doesn't establish that any of those standards have been met.

The cloud providers are extending their guidance in this direction. Microsoft's agent-adoption guidance places agent responsibilities within the existing operating model, separating platform controls from workload ownership. AWS's guidance on agentic platform engineering calls for assessing existing controls and measuring the quality of autonomous decisions.ii

That guidance concerns adopting and operating agents more broadly. Applying it to software delivery means extending the platform to control agent execution, evaluate generated work and record the evidence behind acceptance. Product and service owners remain accountable for the results.

What needs to be in place?

The factory needs standards that your organisation has deliberately chosen. Security owners establish access and data-handling policies. Engineering and architecture owners agree approved patterns and quality requirements. Product and design owners define the customer outcome and experience. The platform team makes the shared parts available and enforceable.

I would assess the foundations for the particular work being delegated:

• Ownership and context: a named service owner, a clear customer problem and maintained information about the domain, interfaces and constraints. Product and engineering owners make that information available to agents.
• Security and environments: approved environments, scoped identities, secrets handling and access policies. Security defines the requirements; the platform enforces them so an instruction cannot grant additional access.
• Engineering and design: approved architecture patterns, repository conventions, components and interaction guidance. The relevant owners turn these into reusable material, instructions and checks.
• Delivery and operation: reliable tests, review and release policies, monitoring, incident ownership and a tested recovery path. Engineers and service owners establish what evidence is required before a change proceeds.
• Measurement: a baseline for business outcomes, delivery, quality and cost, with people responsible for assessing it. The team must be able to tell whether delegated work is improving the service.

Having these things in documents is only part of the preparation. A security policy needs enforcement, a design standard needs usable components and a quality requirement needs a check that can detect failure. If the existing test suite misses important defects, giving it more generated changes will leave the team with the same assurance gap.

You can begin with assisted work while improving these foundations. An agent might prepare a change for an engineer to inspect before it has permission to run a release. Increase autonomy for a particular task only when its owners, controls and validation are working well enough to support it.

What does lean mean here?

Lean means fewer handoffs, small batches, limited work in progress, rapid customer feedback and continuous improvement. Those practices matter before choosing a team size.

Agents can generate work faster than people can assess or release it. A team with hundreds of unfinished agent changes is accumulating work, even if its coding throughput looks impressive. The constraint may be understanding the change, testing it with customers or safely putting it into production.

DORA's guidance identifies small batches as a way to improve the benefits of AI adoption and counter delivery instability. Its 2025 research describes AI as amplifying the strengths and weaknesses of the existing organisation.ii

I would give the team five operating rules:

• Own a bounded product or customer problem from discovery through operation.
• Start only as much work as the team can validate.
• Ship small changes and observe their effects.
• Turn recurring corrections into improved tests, standards or skills.
• Allocate explicit time to improving the factory.

If review work keeps growing, reduce the amount started and improve the checks. Adding more agents to the same queue will leave the people with more unfinished work to manage.

Who is in the product team?

I would start with three core capabilities and adjust headcount to the scope. Each needs someone with the judgement to make decisions and assess work they did not produce themselves.

Product and domain leadership

The product lead understands customers, chooses the problems to solve and prioritises the work. They define success and accept business outcomes. They need enough domain knowledge to challenge a plausible specification that misses how the business actually works.

Agents can synthesise research, draft specifications, suggest acceptance scenarios and analyse results. The product lead checks the underlying evidence and decides whether the proposed work addresses the customer problem. A completed specification still needs that decision.

Product design

The designer owns journeys, usability, accessibility, interaction quality and consistency. They validate the experience with users and work with engineering on what can be delivered within the constraints.

Agents can produce prototypes, explore alternatives, implement interfaces and check against the design system. The designer assesses whether the experience makes sense, including errors, empty states and recovery. Passing component checks cannot establish that a customer understands the journey.

Engineering leadership and delivery

The technical lead owns architecture, technical correctness, integration, reliability and engineering decisions. Agents can support planning, implementation, testing, technical review, deployment preparation and incident investigation.

Engineers still need enough technical depth to diagnose failures and challenge generated implementations. They must be able to explain why a change is correct, what could fail and how the service will recover. Strong communication matters because product and design decisions can depend on those constraints.

How many people does that require?

SVPG's 2025 vision proposes a product manager, designer and engineer as a future team shape over a three-to-ten-year horizon. It is a forecast, not evidence that every product can be run by three people.i

A three-person team could cover these capabilities for a bounded product with strong platform support. For a production service, I would often start with an additional engineer to provide review capacity, operational cover and continuity.

Three people should be a hypothesis to test, not a staffing mandate. More integrations, demanding reliability requirements or a wider domain may require more people or a narrower scope. The team also consumes shared platform, security and specialist capacity; those costs belong in the economics.

We also need a development path for less experienced engineers. As agents take over traditional introductory tasks, junior engineers need other opportunities to build technical judgement. I would build that path through pairing, bounded ownership and incident learning, with experienced engineers helping people understand the decisions behind a change.

A junior engineer could own a small improvement from specification through release, then explain the implementation and evidence with a colleague. They need opportunities to investigate failures and learn the system as well as learn to use agents.

How does the organisation support the team?

Product teams own customer outcomes and their services throughout their lifetime. They need a manageable scope and dependable shared capabilities to do that with fewer people.

A shared platform team owns the factory as an internal product: environments, identities, agent execution, reusable workflows, evaluation infrastructure and cost visibility. Its customers are the teams using those capabilities, and its priorities should reflect where those teams are losing time or encountering failures.

Specialists help with security, reliability, data, accessibility and adoption. They embed where needed and convert repeatable expertise into reusable capabilities. A security specialist might work with a team on a new threat scenario, then help turn the resulting check into something other teams can use.

This draws on Team Topologies' distinction between teams aligned to a flow of value, platform services and enabling support. Its emphasis on cognitive load is particularly useful: a smaller team must have a scope it can understand and operate.i

Every shared agent or skill needs a named owner responsible for evaluation, maintenance and retirement. The platform team can supply the execution environment while a security or product team owns the expertise encoded in a particular skill.

Those responsibilities need an agreed route for problems. Product teams should know who can fix an unreliable shared workflow, and the owner needs evidence of failures, review effort and repeated corrections to prioritise that work.

Who owns design and standards?

“Agents follow our standards” only becomes useful when someone creates those standards, makes them available in the work and checks whether they are followed. I would assign ownership explicitly:

Use instructions to guide judgement and automated controls to enforce requirements wherever possible. An instruction can explain the approved architecture and its reasoning. A dependency check can prevent a change from introducing a prohibited connection.

For design, the product designer owns the experience in this product. The shared design-system owner maintains the reusable components and patterns. If the product needs a new interaction, the designer and engineers work through it together, with the design-system owner deciding whether it should become a shared pattern.

The factory should give agents the approved components, tokens and examples before they build. It can run accessibility checks and compare rendered screens with expected layouts. The designer still needs to inspect the journey and test it with users, particularly when the interaction is new.

Architecture needs the same clarity. The technical lead records the important decisions and contracts, then makes them available to the agents doing the work. Specialists help where a decision crosses service boundaries or needs expertise beyond the team.

Standards themselves need a lifecycle: propose, review, test, version, roll out, measure and revise. Test a changed skill against representative work before making it the default, and keep a way to return to the previous version. An exception needs a named decision-maker, a recorded reason and a review date.

AutoScout24 provides a concrete example of distributed ownership. Plugin owners maintain their plugins, platform engineering reviews new admissions and a required linter checks structure, registry consistency, ownership entries and version changes. That supports shared standards without making the platform team review every routine update.i

How do people and agents work together?

Take a proposed customer onboarding flow as an example. Before agents start building, product, design and engineering need to agree which customer problem they are solving, what a successful experience looks like and what the existing service can support.

Discover and specify

Agents gather evidence and draft requirements and scenarios. The product lead chooses the problem and desired outcome: for example, helping a customer complete setup without assistance. The designer examines where people struggle, while engineering checks integration and data constraints. Before building, the product lead establishes current completion rates and requests for assistance, with analytics support to check that the events measure the journey correctly.

Together they describe acceptance scenarios, including interrupted setup, invalid input and returning to an unfinished journey. The product lead owns the intended outcome and prioritisation; the designer and technical lead shape the specification before implementation starts.

Design

Agents explore interfaces and technical options. The designer owns the experience and validates a prototype with users. The technical lead owns the architecture, including how onboarding state connects to the existing account service.

A failed usability test leads back to design. If users cannot understand what the next step requires, generating more implementation will not resolve that uncertainty.

Plan and build

The technical lead sets the scope, constraints and permitted autonomy. Agents decompose the work, implement small changes and run the required checks using the agreed components and interface contracts.

An implementation discovery may require a revised specification. If the account service cannot safely resume partial setup, engineering brings that constraint back to product and design. They decide whether to change the service or adjust the journey.

Validate

Agents return test evidence, previews and review findings. The product lead assesses acceptance scenarios, the designer checks the experience and the engineers assess correctness, reliability and unresolved technical risks. Specialists contribute where the change needs their judgement.

Evidence should let those people assess the work without reconstructing the agent's entire session. Missing evidence is a reason to return the work for further validation.

Release

A named service owner defines the release policy and approves exceptions. Agents execute the approved workflow within that policy, including the required checks and rollback preparation. For the onboarding flow, a limited rollout lets the team observe completion and failure before expanding it.

Operate and improve

Agents monitor, investigate and propose remediation. The service team owns reliability, incident decisions and follow-up. Product compares completion and requests for assistance with the baseline; design investigates confusion; engineering examines errors and recovery. The team checks whether the rollout changed the customer population or other conditions before attributing an improvement to the new flow.

These stages allow feedback and iteration. A production finding may change the acceptance scenarios, and a repeated review correction should improve the shared checks or instructions. The team keeps responsibility for the service after release.

How do you measure whether delegated work is good?

Business intelligence, engineering metrics and quality metrics become essential when you delegate work to agents. You need to know what the business needs, whether the work meets the standard and whether the result is worth its cost.

The cloud frameworks already include measurement. The question is whether your organisation has implemented it well enough to connect customer outcomes, delivery, quality and spend. Separate dashboards can report activity without showing whether a completed piece of work improved the product.

I would make four sets of measures part of the operating model:

• Business outcomes: the product lead owns the definition of success, supported by people who understand the business data. Track customer behaviour, adoption and the intended outcome. For onboarding, that means completion and the need for assistance, with a baseline and an agreed observation period.
• Engineering delivery: the technical lead tracks lead time, unfinished work, review effort and rework. Faster implementation only helps if the team can validate and release the result. A growing review queue is a reason to reduce work in progress.
• Quality and reliability: engineering and service owners track acceptance results, escaped defects, failed changes and recovery. Design owns evidence about usability and accessibility. Agent or skill owners evaluate whether their checks detect known failures as well as pass good work.
• Economics: the product and platform owners assess cost per accepted outcome with finance or FinOps support. Include people's time, model spend and shared infrastructure. Record failed attempts and rework so that the cost of unsuccessful runs remains visible.

Uber's software factory account describes evaluation against real workloads and costs per completed outcome alongside quality measures. It is a useful implementation example of the measurement the factory itself needs.i

The platform should connect a piece of work to its agent runs, checks, human review, release and costs. Product analytics then helps assess the customer outcome. Agree what each measure means and who maintains the data, so comparisons remain useful as workflows and models change.

Use that evidence to make decisions. Unresolved acceptance failures stop release. Repeated review corrections become improvements to the skill or standard. More escaped defects can require reduced autonomy. A technically sound feature that fails to improve the customer outcome goes back to product discovery.

Business results may take longer to observe than test results. Keep that distinction when accepting a release: passing the required checks permits the rollout, while the team remains responsible for finding out whether it achieved the business goal.

How much autonomy should agents have?

I would start with human-reviewed delivery and expand autonomy when there is evidence that validation works. There are different implementations to learn from. Stripe describes unattended coding agents using isolated developer environments to produce human-reviewed changes.i

StrongDM describes a three-person AI team deliberately avoiding human code writing and review, with specifications, scenarios and substantial investment in automated validation. That is a company account of a particular setting; the validation capability is part of what makes that choice possible.i

• Assisted: agents prepare work; people inspect and approve it.
• Delegated: agents complete bounded tasks and return evidence; people decide acceptance.
• Policy-controlled automation: qualifying changes proceed automatically within explicit limits.
• Exception-led supervision: people monitor results and intervene when evidence, risk or behaviour falls outside those limits.

Permissions should be specific to the task and service. Reliable dependency updates do not establish competence to redesign payment authorisation. A team might automate one class of update while continuing to inspect every change to a sensitive customer journey.

For each work type, define what the agent can access, what it may change, the evidence required and when it must stop. Review failures and missed defects as well as successful completions. The service owner must be able to reduce autonomy when results deteriorate.

How do you adopt the model?

I would use the first ninety days to test it in one bounded product area. Progress depends on evidence from the work, so a date alone should not trigger wider autonomy.

• First 30 days: assess existing ownership, standards and measurement for one product area. Assign missing owners and establish business, delivery, quality and cost baselines. Prepare the context, environments and checks needed for a bounded task, keeping human inspection where validation is incomplete.
• Days 31 to 60: delegate selected work types. Use the agreed measures to assess review effort, failures, rework and customer results, then improve the shared skills. Look for repeatable completion with acceptable quality and manageable human intervention.
• Days 61 to 90: expand successful workflows and selectively automate low-risk changes. Proceed when end-to-end results improve without unacceptable reliability, cost or team-load regressions.

Start with one customer problem and review the way you deliver it today. Name the owners, identify the standards agents will need to follow and check whether you can measure the result. Use those findings to choose the first piece of work to delegate.