How do AI agents fit into the software lifecycle?

AI agents fit into the software lifecycle as workers inside each stage (planning, building, reviewing, testing, releasing and operating), while people keep the decisions that carry accountability: what to build, whether a change is good enough to ship, and what reaches production. The pattern that works is agents doing bounded tasks with limited tools, independent checks between stages, and a person approving at defined points. Agents speed up the work; they do not remove the need for the gates around it.

What an AI agent is

In software delivery, an AI agent is a language model given a goal, a set of tools and a loop. It reads the task, decides on an action (open a file, search the code, write a change, run a command), looks at the result and decides on the next action, until it judges the goal met or hits a limit.

That loop is what separates an agent from an assistant. An autocomplete suggests the next lines. A chat assistant answers a question. An agent acts on its own for many steps, and its output is a result rather than a suggestion: a plan, a diff, a test report, a pull request.

Three things follow from that:

• Agents need limits. Time, tokens, which files and tools they may use, and which actions need a person.
• Agents need evidence, not confidence. An agent will report success it has not verified. Results such as test runs should come from actually running things.
• Agents need a record. When a change was made by a loop of model calls, the only way to understand it later is a record of what was asked, what was done and who approved it.

AI agents across the lifecycle

Agents can help in every stage. What changes is what they produce, and what a person must keep.

The column on the right is not a list of tasks agents cannot attempt. It is where a decision needs someone who can be held responsible for it.

Single agent vs multi-agent development

A single general agent can plan, write and test a change by itself. Multi-agent development splits the work across agents with different roles and instructions, run in a set order or coordinated by another agent.

Common multi-agent patterns are a pipeline (plan, build, review, test in order), parallel perspectives (several reviewers look at the same change from different angles, then one merges their findings) and debate (two agents propose approaches and a third critiques them). Running agents strictly one after another is simpler to reason about, because each step can read everything before it.

The value of extra agents comes from independence. A reviewer that uses a different prompt, sees the real diff and is not asked to defend its own work is more likely to catch problems than the author re-reading itself.

Human in the loop

"Human in the loop" means the agent's work does not take effect until a person approves it. It is different from "human on the loop", where agents act and a person monitors and can intervene, and from full autonomy, where nobody looks.

For code, the irreversible or high-impact moments are the ones that need a person: merging into the main branch, deploying to production, changing infrastructure or access control, and anything that sends data outside the organisation. The rest can be automated as long as the gates are in place.

Two practical points decide whether human review is real or a formality:

• Separation of duties. The person who asked for a change should not be the only approver when someone else can review it. Otherwise the approval is the author agreeing with themselves.
• The approver needs evidence. A diff, the test results, the open review findings and the policy decisions, in one place. Asking a person to approve a large change with no context produces rubber stamps.

Approval fatigue is a real risk. If every trivial change needs a person, people approve without reading. Use policies to decide which changes need extra attention, and let automated gates handle the rest.

Agentic DevOps

Agentic DevOps is the use of agents in delivery and operations work: changing pipelines and infrastructure code, upgrading dependencies, triaging incidents and proposing fixes. These tasks touch systems with more reach than an application change, so the controls matter more:

• Least privilege. An agent gets only the tools and paths its task needs. Credentials stay in build jobs, not in the agent's context.
• Isolation. Code an agent wrote runs in a sandbox, not on a shared server or a developer's laptop.
• Policy as code. Rules decide what agents may do on their own, what needs approval and what is forbidden, for example any change under infra/**.
• The same gates. An agent's pipeline change goes through tests, review and approval like any other change.
• Outcome metrics. Delivery measures such as deployment frequency, lead time for changes, change failure rate and recovery time tell you whether agents are helping, better than counts of lines written.

How to introduce AI agents into your delivery process

1. Start with bounded tasks. Pick work with a clear definition of done and good tests, such as small features, bug fixes with a reproduction or dependency upgrades.
2. Define the roles. Decide which agents plan, build, review and test, and what each may read and use.
3. Put gates between stages. Tests on the exact change, a review of the real diff and a blocking severity threshold. See What are quality gates?
4. Place the human approvals. At least before merge, and before production for anything risky. Keep the author and the approver separate where the team allows it.
5. Write the policy. Which workflows may start without approval, which paths need a review, which tools and deployments are off limits.
6. Cap time and spend. Agents loop. Set limits per run and per period. See How much does AI coding cost?
7. Keep a record. For each change: the task, the agents and models, the findings, the tests, the approvals and the delivery.
8. Measure outcomes. Compare lead time and change failure rate before and after, and widen the scope only when the numbers support it.

How AI CodeOps does it

AI CodeOps runs AI agents across the lifecycle in the browser. Every session runs one of 16 built-in workflows, each a fixed list of steps run one after another by agents such as the Architect, Builder, Reviewer and Tester. The default, Plan, Build, Review & Test, runs those four in order; others cover security-sensitive changes, release readiness, dependency refreshes and incident response. Each step sees what the earlier steps wrote. Workflows labelled parallel, debate or swarm describe how the steps divide the work, not that they run at the same time.

After the steps, the change is written against a fresh copy of the repository, your own tests run in an offline sandbox, and a separate review reads the diff and records findings. Then a person approves. The person who started the session cannot cast the approving vote while someone else in the workspace can approve; a one-person workspace can approve its own change. Only then does the pull request open.

A workspace policy decides what sessions may do without a person. This example holds dependency upgrades for approval before they start, asks for a review of infrastructure changes, blocks automatic production deploys and keeps one MCP tool away from the agents:

[
  {
    "id": "approve-dependency-refresh",
    "action": "workflow.dispatch",
    "resource": "dependency-refresh",
    "decision": "ask",
    "description": "A person approves before a dependency upgrade session starts"
  },
  { "id": "review-infra-changes", "action": "diff.apply", "resource": "infra/**", "decision": "ask" },
  { "id": "no-production-deploys", "action": "release.deploy", "resource": "production", "decision": "deny" },
  { "id": "no-repo-deletes", "action": "mcp.invoke", "resource": "github/delete_*", "decision": "deny" }
]

The strictest matching rule wins, and every decision other than a plain allow is recorded. Each change can be downloaded as a signed evidence pack listing the task, models, steps, findings, tests, approvals and delivery.

See AI planning for the planning stage, Workflows for every built-in workflow, How AI CodeOps works for a session end to end, and Approvals and policies for the rules.

Go deeper

• Where to put human approvals in an AI coding workflow: which decisions need a person, separation of duties when an agent writes the code, and avoiding approval fatigue.
• Multi-agent patterns for software delivery: pipelines, parallel reviews, debate, orchestrators and verify loops, and how each one fails.