Agentic software delivery governance

Introduction

Agents used by the delivery team need a different governance model from AI models embedded in the product. Delivery agents may not be part of the customer-facing service, but they can still create risk because they may read code, write code, inspect logs, summarise documents, generate infrastructure changes or draft customer-facing material.

The company should decide what delivery agents are allowed to see and do. There is a big difference between an agent summarising public documentation and an agent reading production logs, customer data, secrets or incident records.

Delivery boundaries

Useful boundaries include:

• Which agent tools can be used by staff.
• Whether source code can be shared with external AI services.
• Whether customer data or PII can be used in delivery prompts.
• Whether production logs can be pasted into an agent.
• Agent access to repositories and documentation.
• Agent access to secrets.
• Whether delivery prompts are retained and where.
• How agent-generated code, infrastructure or policy changes are reviewed.
• How decision records help agents understand context.

Review and accountability

Agent-generated work still needs human accountability. If an agent writes code, changes infrastructure, drafts a policy or suggests a customer response, a person should own the decision to accept it.

The review model does not need to be heavy. It should be clear:

• What can an agent do without approval?
• What requires pull request review?
• What requires a human decision record?
• What must never be delegated to an agent?
• How are mistakes traced and corrected?

For software delivery, the key principle is that agents can accelerate work but should not silently change the control position. Code still needs review. Infrastructure still needs traceability. Security compromises still need decision records. Production changes still need an accountable owner.

Why decision records matter

Agents are only useful if they can understand context. Source-controlled decision records give agents and people the same memory: why Azure was chosen, why the POC is throwaway, why a security compromise was accepted, and what must be revisited before Pilot or Production.

Without decision records, agents infer intent from code. That is fragile. The code shows what exists; the decision record explains why.

How this evolves as the company grows

• At POC, keep agent-assisted delivery visible: record prompts, generated changes and review notes where they affect code or infrastructure.

• At Pilot, make sure agent changes are traceable through repositories, pull requests and release notes because external users may be affected.

• At Production, agent output should support controlled change rather than bypass it: approvals, rollback evidence and release quality still matter.

• As the company scales, use agents to monitor delivery drift, dependency risk and repeatability, while keeping people accountable for accepted risk.

What an agent should look for

• Are agent-generated changes traceable?

• Is human accountability clear for accepted risk?

• Can delivery evidence be reviewed later by people and agents?

What good looks like

The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.