Your Agentic SDLC Needs a Control Plane, Not Another Copilot Demo

The demo is easy. Give an agent a repository, an issue, and a shell. Watch it investigate, edit a branch, run tests, and open a pull request. The moment it can move across that workflow, you are no longer managing a coding assistant. You are managing a software delivery control plane with permissions, approvals, and recovery paths.

An agent can now participate in requirements discovery, implementation, testing, review, and release preparation. That means a TPM cannot manage the program with a single question such as, "Did the model write useful code?" The better question is, "Who owns each decision, what evidence is required at each boundary, and what happens when the agent is wrong?"

Agentic software delivery is a control plane problem. The model is one component. The program needs ownership, permissions, evaluation, observability, and recovery around it.

The number that matters

Google Cloud's 2024 DORA report found that a 25% increase in AI adoption was associated with better documentation quality, code quality, and review speed. The same report associated that increase with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability.

These are survey associations, not a causal forecast for your organization, but they create a useful TPM warning: local productivity signals can improve while the delivery system gets less stable.

Counting generated lines or accepted suggestions is not enough. The scorecard must reach the customer and the production system.

The framework: five controls for an agentic SDLC

1. Assign an owner at every branch

Multi agent workflows create a deceptively simple question: who owns the answer when the path branches?

OpenAI's orchestration guidance describes two useful patterns. A handoff moves control to a specialist. An agent used as a tool lets the manager keep ownership of the reply. Those patterns are not interchangeable, and the difference matters when a workflow can change a repository, approve a release, or communicate an external commitment.

The program pattern I keep coming back to is simple: make the agent's freedom narrow enough to trust, then widen it only when the evidence earns that trust. That is a program decision, not a prompt trick.

Write the owner into the program design. Requirements owns acceptance criteria. The implementation agent owns a proposed change. Test automation owns test evidence. Security owns the security decision. A human release owner owns the production change.

If a box says "the agents handle it," the box does not have an owner yet.

2. Put approvals beside the side effect

A top level review does not necessarily protect every nested tool call. OpenAI's guardrail guidance separates automatic checks from human approval and recommends pausing before side effects such as edits, shell commands, cancellations, or sensitive integrations. It also warns that checks placed only at the agent level may not cover every custom tool call.

For a TPM, this becomes a boundary map:

1. Repository read access can be automatic.
2. Branch creation can be automatic within a named repository and task scope.
3. Commits need tests and traceability.
4. Pull request creation needs a visible diff and acceptance evidence.
5. Production changes, permission changes, security exceptions, and customer affecting actions need an approval interruption at the tool boundary.

The goal is not to add a human click to everything. It is to make the irreversible actions obvious and fail closed when the required evidence is absent.

3. Turn requirements into evidence, not prose

GitHub's documentation for Copilot cloud agent describes a workflow that can research a repository, create an implementation plan, make changes on a branch, run tests and linters in an ephemeral environment, and create a pull request for review. That is a capability description. It is not evidence that the resulting change satisfies your program.

The TPM job is to make the acceptance contract executable enough that a reviewer can inspect it.

For each agent task, define:

• The issue or requirement the task is allowed to address.
• The files, services, and environments inside its scope.
• The tests that must pass.
• The checks that must be visible in the pull request.
• The conditions that force escalation.
• The person who can accept, reject, or narrow the change.

This turns an agent run into a traceable delivery unit instead of a clever chat transcript.

4. Measure the delivery system, not the local trick

A fast draft or accepted code suggestion is an intermediate signal. Your program scorecard should include change throughput, review burden, escaped defects, rollback frequency, incident volume, task completion, and the time required to resolve an agent generated failure.

NIST's AI Risk Management Framework describes governance as a cross cutting function and treats risk management as continuous across the AI system lifecycle. Its generative AI profile also calls for evaluating output against known ground truth, reviewing sources and citations, and adding human review and documentation where warranted.

That gives TPMs a practical structure for the roadmap:

• Define the quality and safety signals before the pilot.
• Establish a baseline for the existing delivery process.
• Run a limited workflow with representative tasks.
• Compare local speed with system outcomes.
• Review the scorecard at each expansion decision.

Do not let a successful demo become a permanent exception to measurement.

5. Page on symptoms and diagnose causes

Microsoft's observability guidance connects tracing, evaluation, automated quality gates, logs, model outputs, and operational health. Google SRE's monitoring guidance makes a related distinction: page on user visible symptoms, then use cause oriented signals for diagnosis.

The same distinction works for agentic systems. Page when a task fails to complete, an unsafe output reaches a review boundary, a tool workflow becomes unavailable, or latency breaks the user promise. Keep the model name, prompt version, retrieval context, tool calls, approvals, and trace data so the team can investigate why.

A dashboard full of token counts may be useful for cost management. It is not a service health model. The program needs signals that tell people whether the workflow delivered the intended outcome safely.

A worked program pattern

Suppose an engineering organization wants an agent to take a well formed issue to a reviewed pull request.

Start with a narrow contract. The agent may read the repository, inspect related issues, propose a plan, edit a branch, run the approved test commands, and open a pull request. It may not merge code, change repository permissions, rotate credentials, or deploy to production.

Then make each handoff visible:

1. The TPM or product owner accepts the issue and defines the success conditions.
2. The agent produces a plan linked to the issue.
3. The engineer reviews the plan before implementation if the task crosses a service boundary.
4. The agent creates a branch and records the files it changed.
5. Tests, linters, and known answer checks run in the isolated environment.
6. The pull request records the agent identity, tool actions, test results, and open uncertainties.
7. A human reviewer evaluates the diff and the evidence.
8. The release owner decides whether the change can move forward.

That is slower than a demo. It is also a program you can audit, improve, and roll back.

The useful artifact is not the agent transcript. It is the chain from requirement to decision: issue, plan, branch, diff, test evidence, review, approval, release, and outcome.

Sources for the framework and counter signals

• NIST AI RMF 1.0
• NIST Generative AI Profile
• GitHub Copilot cloud agent documentation
• OpenAI orchestration and handoffs
• OpenAI guardrails and human review
• Microsoft observability in Generative AI
• Google Cloud 2024 DORA report highlights
• Google SRE monitoring distributed systems

What this does not solve

Model quality is still variable. A clean workflow does not make an agent correct. You still need representative evaluations, known answer tests, and a way to reject weak output.

Governance is not a substitute for engineering judgment. NIST provides a voluntary, outcome focused framework. It does not tell your team the right approval threshold or prove that a particular workflow will improve delivery.

The scorecard will not choose your risk appetite. The program still needs an explicit decision about which actions are reversible, which actions require a human, and how much latency the organization will accept for review.

The signal that matters most

The strongest signal is not how much code the agent produced. It is whether the team can explain what changed, why it was allowed to change, what evidence supports it, and how the system will recover if the decision was wrong.

For the next agent pilot, write the boundary map before you write the prompt. Name the owner at every branch. Put the approval next to the side effect. Then decide which system level outcome would make you stop, expand, or roll back.

Send me one agent workflow, one approval boundary, and one outcome you would measure. I am collecting working patterns for a practical TPM playbook.