Software factory org design assigns human ownership for the work that agents perform. Start with one service, name its decision owners, define the limits of delegated work, and test who can stop and restart the workflow before expanding it.
TL;DR
A software factory needs clear ownership of specifications, verification, agent operations, and service outcomes. These are responsibilities, not four mandatory hires. Product teams own service decisions. Platform teams provide shared controls. A written responsibility matrix connects each decision to a person, a backup, and evidence. Staffing follows measured workload and risk.
An agent opens a pull request that passes its tests. The change also modifies an interface used by another team. The reviewer can see the result, but nobody knows who can accept the interface change or stop related agent runs. More automation will not resolve that ownership gap.
This guide gives engineering leaders a model for assigning those decisions. It covers team boundaries, approval rights, and escalation policy. It also includes a responsibility matrix that teams can copy into their own operating documents.
The model applies to an AI software factory: a repeatable software delivery workflow in which agents perform defined tasks under human direction and controls. The amount of delegated work can vary by service and change type.
Start With One Service and Its Decisions
The useful unit for organizational design is a service or product area with a named owner. Its workflow connects intake, specification, implementation, verification, and release. Each stage needs a clear handoff and a person who can resolve an exception.
An ownership record should state:
- Which repositories, services, and environments the workflow covers.
- Which tasks agents may perform and which actions require human approval.
- Who accepts the specification, verifies the result, and authorizes release.
- Who can pause work, revoke access, and authorize a restart.
- Who covers each decision when the primary owner is unavailable.
These boundaries should match the system's real dependencies. A team cannot release independently if every change requires another team's manual intervention. DORA identifies the ability to test, change, and deploy with limited external coordination as a feature of effective team and system design. DORA: Loosely Coupled Teams.
For a shared library or tightly coupled application, the ownership record must include the affected teams. A single service owner does not acquire authority to accept risks on their behalf.
Assign Four Core Responsibilities
The four responsibilities below form a starting model. Existing engineers and leaders can hold them. Teams should separate duties where risk, workload, or internal policy requires independent review.
Specification Owner
The specification owner defines the intended outcome, scope, constraints, and acceptance criteria. The record includes affected interfaces, excluded work, and conditions that require a new decision.
For example, a task to improve a checkout error message might permit changes to copy and tests. It would exclude payment authorization logic. If an agent discovers that the requested behavior needs an authorization change, the task returns to the specification owner.
The owner also keeps the specification current when new evidence changes the task. An agent may draft a plan or identify missing information. A named person accepts the resulting scope.
Verification Owner
The verification owner defines what evidence is sufficient to accept a change. That can include automated tests, code review, behavior in a test environment, security checks, and review by an affected service owner.
A successful demonstration answers whether a tested scenario works. It does not establish that every relevant behavior is correct. The verification owner decides which additional checks the change requires and records any unresolved limits.
This responsibility includes maintaining test quality. An agent that changes application code and weakens the associated test has not supplied independent evidence of success.
Agent Operations Owner
The agent operations owner maintains the environment in which delegated work runs. This includes credentials, allowed tools, runtime configuration, execution limits, run records, and the tested procedure for stopping work.
The owner makes those controls usable by authorized responders. A stop procedure that depends on one available engineer creates a preventable dependency. The operating record must name a backup and explain how that person obtains access.
Service Owner
The service owner remains accountable for the service outcome. This person accepts the workflow's risk boundaries, resolves conflicting priorities, and ensures that release and incident responsibilities are assigned.
The service owner can delegate particular approvals. A gate owner is the person authorized to decide whether work may pass a specific checkpoint, such as specification acceptance or release. The delegation states what that person may approve and what must be escalated.
These roles do not imply that one manager must personally review every change. They make it possible to distribute decisions without losing accountability.
Use a Responsibility Matrix for Each Workflow
The table below is a proposed operating template. It is not a universal staffing standard. Each row has one accountable role. Before use, replace role names with named owners and backups.
| Decision or activity | Accountable role | Work performed by | Required record |
|---|---|---|---|
| Accept the task and its scope | Specification owner | Product and engineering contributors; agents may draft | Accepted specification and exclusions |
| Set acceptance criteria | Verification owner | Engineers, test specialists, and relevant reviewers | Versioned criteria and required checks |
| Approve service-specific agent instructions | Service owner | Specification owner and agent operations owner | Reviewed instructions and change history |
| Change shared agent access or execution controls | Agent operations owner | Platform and security contributors | Reviewed configuration and permission record |
| Implement within approved scope | Specification owner | Assigned engineer or agent | Changes linked to the accepted task |
| Accept verification evidence | Verification owner | Automated checks and designated human reviewers | Results, findings, and unresolved limits |
| Authorize release | Service owner or delegated release gate owner | Designated release operator | Approval, deployment record, and recovery plan |
| Maintain the stop procedure and backup access | Agent operations owner | Platform and service responders | Tested runbook and drill record |
| Authorize restart after a workflow halt | Service owner | Verification and agent operations owners | Cause addressed, controls checked, restart decision |
| Own an incident affecting the service | Service owner | The established incident response team | Incident record and assigned follow-up actions |
Download the editable responsibility matrix (CSV) and enter the named owners and backups for your workflow.
Security or architecture teams can hold required approval rights for particular change classes. Those rights should appear in the workflow record rather than remain an informal expectation.
Accountability for maintaining the stop procedure does not restrict who may use it. An authorized responder should be able to stop affected work when a defined trigger occurs.
Keep Product Decisions Close to the Service
A shared platform should reduce repeated work while preserving clear service ownership. Team Topologies distinguishes teams aligned to business work from platform teams that provide an internal product to support them. That distinction is useful when placing shared agent infrastructure. Team Topologies: Key Concepts.
The following split is a design recommendation for a software factory:
| Shared platform responsibility | Product team responsibility |
|---|---|
| Approved runtime and integration patterns | Service-specific task scope |
| Credential handling and access controls | Domain constraints and acceptance criteria |
| Shared run records and cost reporting | Review of changes affecting the service |
| Supported agent instruction templates | Service-specific instructions within shared limits |
| Stop mechanisms and access recovery | Release decisions and incident follow-up |
Shared templates need a version, an owner, and an update process. A team can customize permitted behavior without bypassing controls that apply across the organization.
For a small team, the same people may cover both columns. As more teams adopt the workflow, a dedicated platform capability becomes useful when repeated maintenance or cross-team support consumes material time. Team count alone does not establish when to make that change.
Platform evaluation should test whether these ownership and control requirements can be implemented. The software factory platform overview connects them to Augment's approach.
Define Stop, Escalation, and Restart Rights
The policy must distinguish three actions: pausing one task, halting a workflow, and disabling broader access. Their scope and consequences differ.
The example below is a starting policy. Each organization must set its own risk thresholds and response coverage.
| Trigger | Immediate action | Decision owner | Evidence needed before work resumes |
|---|---|---|---|
| Work exceeds the accepted specification | Pause the task | Specification owner | Accepted scope change or corrected task |
| Required verification fails | Block progression to release | Verification owner | Resolved finding and fresh verification |
| A run reaches its approved time, retry, or cost limit | Stop that run | Agent operations owner | Cause reviewed and new limit explicitly approved |
| An agent attempts an unauthorized action | Stop affected work and restrict access as required | Agent operations owner, with security response as applicable | Access checked and cause addressed |
| A change causes a service incident | Apply the existing incident process | Service owner and incident commander | Recovery verified and restart approved under that process |
The policy should specify the primary contact, backup contact, response target, and action to take when neither responds. For a pending approval, the safe default is to leave the change blocked. Incident response follows the service's established emergency procedure.
Repository controls should support the policy. GitHub, for example, supports required reviews and status checks through protected branches. Teams must check bypass permissions and confirm that a blocked change cannot proceed through another route. GitHub: Protected Branches.
Security practices also belong throughout the delivery workflow. NIST's Secure Software Development Framework provides high-level practices that teams can integrate into their SDLC. The responsibility matrix here does not establish compliance with that framework. NIST SP 800-218.
For more detail on checkpoint policy, use the quality gates guide.
Match Staffing to the Work That Remains
Agent adoption does not establish a fixed staffing outcome. Some tasks may require less implementation time while review, environment maintenance, or incident work grows. Teams need their own workload evidence before changing staffing assumptions.
Useful measures include:
- Time spent clarifying specifications and resolving scope changes.
- Verification effort and time waiting for review.
- Accepted changes, rework, and failures after release.
- Time spent maintaining agent environments and shared instructions.
- Interruptions, incident coverage, and backup availability.
A growing review queue is a reason to investigate task size, test quality, reviewer capacity, and release risk. It does not by itself justify adding agents or removing review.
The software factory metrics guide covers delivery measurement in more detail. At the organization level, the question is which responsibility lacks sufficient time, skills, or coverage.
Career design should preserve opportunities to learn the system. Supervised implementation, debugging, specification writing, and verification all provide evidence of engineering judgment. Performance evaluation should consider that evidence, rather than treat agent-generated output volume as an individual's contribution.
Apply the Model to One Service First
Consider a product team piloting agents on a billing service. This is an illustrative example, not a customer result.
The service lead owns the workflow. An engineer owns specifications. Another engineer owns verification for the pilot. An existing platform engineer maintains agent access and runtime controls. Each responsibility has a named backup.
The team permits documentation updates and selected test improvements. Changes to payment authorization, customer data access, or production configuration require separate scope and review. The workflow produces a pull request and evidence; it does not receive unrestricted production access.
Before adding more tasks, the team runs a stop drill. A backup responder stops a test run using the documented procedure. The team records whether work actually stopped, whether new triggers remained active, and which permissions were needed. A restart requires the named owner's decision.
This exercise tests the organization as well as the tooling. If a backup cannot find the run, access the control, or reach the decision owner, the workflow needs correction before wider use.
What to Do Next
Choose one service. Copy the responsibility matrix and enter a named owner and backup for every decision. Record the permitted tasks, escalation triggers, and restart authority. Then test one blocked change and one halt with the backup responder.
Use the factory maturity model to identify the next operating constraint. The software factory guide connects these organizational decisions to the broader delivery workflow.
Frequently Asked Questions
Does a software factory require a new department?
No. A team can begin by assigning responsibilities within its existing structure. A dedicated platform function becomes useful when shared controls and support need sustained ownership across teams.
Can one person hold more than one role?
Yes, where workload and policy permit it. The ownership record must still distinguish each decision. Changes that require independent approval need a separate reviewer, even when other responsibilities are combined.
Who is responsible for code written by an agent?
The organization remains responsible for the software it releases. In this model, the service owner is accountable for the service outcome, while named specification, verification, and release owners make the delegated decisions.
Can any engineer stop an agent?
The organization should grant and test stop rights for designated responders and backups. The policy defines which work they may stop, when they must act, and who can authorize restart.
Is the service owner always the engineering manager?
No. An organization can assign service ownership to a technical lead or another qualified owner. People management and service decision rights must be explicit if different people hold them.
Related Reading
Written by
Ani Galstian
Ani writes about enterprise-scale AI coding tool evaluation, agentic development security, and the operational patterns that make AI agents reliable in production. His guides cover topics like AGENTS.md context files, spec-as-source-of-truth workflows, and how engineering teams should assess AI coding tools across dimensions like auditability and security compliance