Team-Managed Agentic SDLC
Repo readiness is necessary, but it is not enough. Teams do not deliver through one repository. They deliver through habits: how work is sliced, specified, reviewed, tested, merged, deployed, reported, and learned from.
Level 3 maturity begins when agent-assisted engineering stops being a collection of individual workflows and becomes a team-managed SDLC.
The goal is not uniformity for its own sake. The goal is predictable evidence. When an agent opens a pull request, the team should know what the issue must contain, what the PR must prove, which risk labels matter, which review roles apply, and which metrics will show whether the workflow is helping.
Shared Issue Taxonomy
The first team-level artifact is a shared issue language.
An agent-operable issue should say:
- intent;
- acceptance criteria;
- non-goals;
- affected components;
- risk class;
- constraints and invariants;
- dependencies or blockers;
- testing expectations;
- observability and operational notes;
- rollback plan;
- what the agent may and may not do.
This looks heavier than a normal ticket, but it replaces private clarification. If the agent needs the human to restate everything in chat, the issue is not yet an engineering artifact. It is a placeholder.
The taxonomy should also distinguish change classes: docs, tests, service code, infrastructure, IAM, data migration, CI guardrail, public API, generated code. Different change classes deserve different gates.
Review Agents Are Critics, Not Approvers
Review agents are useful when they have a role. A generic “review this PR” agent usually produces generic feedback. A role-specific critic can be sharper:
- architecture reviewer;
- QA reviewer;
- security reviewer;
- infra reviewer;
- SRE reviewer;
- product or acceptance-criteria reviewer.
These agents should produce evidence and critique. They should not be treated as approval authorities in early maturity. A security review agent can flag IAM expansion or insecure output handling. An SRE review agent can ask about timeouts, retries, health checks, metrics, rollback, and SLO impact. The human still owns judgment.
The value is consistency. The team starts encoding the questions it wants asked on every relevant change.
Metrics That Do Not Lie Too Much
AI adoption metrics often reward the wrong behavior. Number of prompts, number of generated lines, or number of AI-authored pull requests can all increase while delivery quality gets worse.
Better team metrics include:
- agent PR acceptance rate;
- review rework rate;
- CI failure rate;
- cycle time by change class;
- escaped defects;
- rollback rate;
- number of missing-context findings;
- manual coordination time avoided;
- agent-caused incidents or near misses.
These are imperfect, but they point toward system behavior rather than tool excitement.
The team should also track qualitative friction: where did the agent get stuck, what context was missing, which review comments repeated, and which tasks should not have been delegated.
Onboarding Becomes Part of the Platform
Human onboarding matters because agentic engineering changes how people work. Engineers need to learn:
- how to write agent-operable issues;
- how to supervise commits;
- how to review agent-authored changes;
- how to interpret review-agent feedback;
- how to maintain repository context files;
- when not to use agents;
- how Jira and GitHub state are synchronized;
- how to escalate uncertainty.
This is not merely a tooling rollout. It is a change in specification and review discipline.
The best internal trainers are not prompt enthusiasts. They are engineers who understand the delivery system and can explain why a boundary exists.
Team Boundaries and Platform Boundaries
A team-managed SDLC also reveals where platform support is missing. If every repository has a different test command, different PR expectations, different deployment vocabulary, and different ownership metadata, agents will amplify the inconsistency.
That does not mean every repo must become identical. It means the differences must be explicit. Platform engineering should make the standard path easy and the exceptions visible.
What Level 3 Proves
Level 3 does not prove that agents understand the whole system. It proves that a team can operate agent-assisted delivery across its repositories with repeatable specification, review, verification, and metrics.
If the team cannot explain why an agent PR was accepted, rejected, rolled back, or narrowed, the process is not mature yet.
The maturity label should follow evidence, not ambition.