Evidence note: This article rests on two kinds of evidence, and they are not the same. Descriptions of specific open-source frameworks (AgentCheck, icebox-cli, VibrationPlan, cc-pipeline, Distillery, and others) come from each project’s own repository and documentation — they are self-descriptions, reliable as statements of what a project claims to do but not independently audited here. The broader claims about what an "agentic SDLC" is and why CI/CD strains under it are, as of this writing, uncorroborated framings circulating across vendor posts and community repos rather than settled industry consensus; they are marked as such. Figures labeled as playagit’s own runs come from this site’s internal pipeline ledger and are measurements of one system, not independent benchmarks. Every number below carries its source inline.
What an agentic SDLC actually names
Strip away the marketing and an "agentic SDLC" refers to a software lifecycle in which AI agents — not just autocomplete, but planning, editing, and reviewing agents — do the mechanical work of building, testing, and shipping, with humans setting direction and approving gates. That an agentic SDLC "positions AI agents as core contributors in building, testing, and deploying software" is a framing repeated across community repositories, but it is uncorroborated as an established practice (evidence: uncorroborated; recurring self-description across projects). What you can concretely check is that the framing has enough traction to produce working templates: multiple public repositories now ship starter structures under the "agentic SDLC" name (RoshanSharma1, jsuryanm, and a worked URL-shortener example), and a curated index tracks the wider tooling (awesome-github-agentic-ai).
Practically, if you want to evaluate one, look for three things: (1) named agent roles with defined inputs and outputs, (2) explicit gates a human or a checker must pass before work advances, and (3) a record of what each agent did. A repo that has all three is a framework; one that only has prompts is a prompt collection.
Why CI/CD strains when agents drive delivery
CI/CD was designed around a load-bearing assumption: humans write the code, and automation verifies it after the fact. The claim that this assumption "no longer holds when AI agents drive delivery" is uncorroborated as a general law (evidence: uncorroborated), but the mechanism is concrete enough to inspect. Classic CI runs after a human commit — it lints, builds, tests, and gates the merge. When an agent generates the change, three CI premises weaken:
- Volume and cost invert. Human review time was the bottleneck and compute was cheap; with agents, code is cheap to produce and checking becomes the scarce resource.
- Intent is no longer implicit. A human PR carries an author who understood the goal. An agent’s diff needs the goal written down — as a spec — or the pipeline cannot judge correctness.
- The feedback target moves earlier. Catching a defect at CI is late if an agent could have been redirected at the planning step.
The reader-level takeaway: an agentic pipeline does not replace CI, it wraps additional gates around and before it. This ordering problem — deciding what "correct" means before code exists — is covered in depth in our guide to building checks you can trust when code gets cheap.
The pipeline shape: eight concrete stages
The stage sequence commonly proposed is spec → research → plan → build → review → fix → reflect → commit (evidence: uncorroborated as a standard; this specific ordering is a recurring proposal, not a ratified reference model). Rather than restate it abstractly, here is what each stage does and what artifact it must emit for the next stage to consume:
- Spec — turn the request into a checkable statement of done. The O’Reilly dispatch on "the right amount of spec" argues the spec should be just detailed enough to constrain the agent without over-specifying — its output is acceptance criteria, not prose.
- Research — gather the code paths, prior art, and constraints. Artifact: a dossier the plan can cite.
- Plan — decompose into steps with dependencies. Artifact: an ordered task list.
- Build — generate the change against the plan.
- Review — run checkers (human or agent) against the spec’s criteria.
- Fix — apply review findings; loop back to review until clean.
- Reflect — record what was learned for the next run.
- Commit — land the change with the trail attached.
The point of naming stages is not ceremony: each stage’s artifact is the gate input for the next. If your pipeline can’t name the artifact a stage produces, that stage isn’t a gate — it’s a hope.
Orchestrating it: graphs, gates, governance, observability
An orchestration engine for this is described as combining a dependency graph, gates, governance, and observability (evidence: uncorroborated as a required architecture). Concretely, those four map to four questions you must be able to answer at any moment:
- Dependency graph — What can run now? Steps with satisfied inputs are runnable; the graph prevents build before plan.
- Gates — May this advance? A gate is a pass/fail check with a recorded verdict, not a vibe.
- Governance — Who approved this, and under what policy? Especially where agents touch production, this needs enforced boundaries; our write-up on zero-trust architecture for autonomous agents that touch production covers the enforcement side.
- Observability — What actually happened? Per-step logs, inputs, and outputs, so a failure is diagnosable.
If you are assembling one, start by making gates emit durable verdicts. Everything else (retry, audit, governance) is built on top of a recorded pass/fail — the same lesson we drew in engineering production agents with quality gates that actually ship.
AgentCheck: five local reviewers instead of a black-box bot
For the review stage, AgentCheck is instructive because its design is a direct reaction to a failure mode. According to its own repository, AgentCheck is an open-source subagent that runs locally with Claude Code and supplies five focused reviewers — logic, security, style, guidelines, and product (evidence: project self-description). Its stated rationale is equally concrete: it exists because tools in the mold of Cursor Bugbot flood PRs with noise, run in a black box, bill per seat, and try to solve problems too late without access to the developer’s own environment tools (evidence: the project’s own stated motivation, uncorroborated externally).
What a reader can take from this without adopting the tool: a review stage benefits from decomposition by concern. One "review the code" agent produces mush; five reviewers each with a single mandate produce findings you can route. And running locally, inside the developer’s environment, is a deliberate architectural choice — the reviewer can use the same tooling the code depends on.
icebox-cli: 6 steps, 5 gates, a production feedback loop
Where AgentCheck sharpens one stage, icebox-cli proposes the whole process. Per its own process documentation, it is a gate-driven model with 6 steps, 5 gates, and a production feedback loop, positioned for a transition its authors label CI/CD → Agentic Integration / Continuous Delivery ("AI/CD") (evidence: project self-description; the "AI/CD" transition framing is the project’s own, uncorroborated as an industry term). The practical shape to copy is the gate-between-every-step discipline: five gates across six steps means work almost never advances without a checkpoint, and the production feedback loop closes the cycle so runtime signals re-enter the front of the pipeline.
Platform-agnostic and evidenced in-repo
icebox-cli’s second claim is portability. Its documentation states the framework is platform-agnostic — GitHub, GitLab, Azure DevOps, and Jira, plus any SCM — and open source, with real evidence such as PRs, issue comments, and gate sign-offs committed in the repository itself (evidence: project self-description). That last part is the reusable idea: gate verdicts recorded as durable artifacts in the repo, rather than as ephemeral CI output, so the audit trail survives the run. If you build one gate today, make it write its sign-off where the next reader will find it.
Named but not yet implementable: Continuous AI and PwC’s Agentic SDLC
Two prominent names are worth flagging precisely because a reader will encounter them and expect a blueprint. GitHub is reported to describe its approach as "Continuous AI," and PwC has reportedly published on the "Agentic SDLC" — but, as far as available material shows, neither ships an implementable framework you can clone and run (evidence: uncorroborated; no primary framework artifact located, and no citable source is available here for either). Treat both as vocabulary and direction-setting, not as tooling. The working artifacts today are the community repositories, not the big-name coinages.
Adapting the SDLC for stateless agents
A recurring practical problem: agents don’t remember. VibrationPlan addresses this head-on. By its own description, it adapts the SDLC for stateless agents using specialized roles, explicit handoffs, and living documentation (evidence: project self-description). The mechanism to note: because each agent forgets, continuity has to live outside the agent — in handoff documents and a maintained source of truth that the next stateless invocation reads on entry. Design for amnesia and the pipeline stops depending on any single long-lived context.
Framework spines and seats
sebas2810’s claude-agentic-sdlc reportedly organizes work into Owner, PM-orchestrator, and Engineer-Principal seats under a single "Building-Effective-Agents" spine (evidence: uncorroborated; self-described structure). The related sheplu/claude-code-agentic-sdlc sits in the same family. The transferable pattern is the split between a spine (shared conventions every seat inherits) and seats (roles with distinct authority). An Owner sets intent, a PM-orchestrator sequences, an Engineer-Principal executes — a separation of powers that keeps one agent from being planner, builder, and judge at once.
Fresh context per step vs. persistent shared context
Two opposite memory strategies are worth putting side by side, because the choice shapes everything downstream.
Fresh context per step. cc-pipeline gives each SDLC step a fresh context window via the Claude Agent SDK, per its own description (evidence: project self-description). The benefit is isolation: no step is polluted by another’s context, and each stage starts clean against its defined inputs.
Persistent shared context. Distillery takes the other road — an MCP server providing persistent shared team context for AI coding sessions, described as roughly 50k lines of Python (16k production, 25k tests, 7k docs) (evidence: project self-description of scope). The benefit is continuity across sessions and agents. (For the infrastructure side of persistent agent state, compare runtime instances on Amazon Bedrock AgentCore.)
The decision rule for a reader: use fresh-per-step when stages are independent and you fear context bleed; use shared persistence when the work spans sessions and losing context is costlier than the risk of carrying stale state. Many mature pipelines do both — fresh execution contexts reading from a shared, curated memory.
The engineering patterns that carry the weight
A Google Developers Blog post analyzing the strongest challenge submissions reports that the most robust multi-agent systems leaned on foundational software engineering rather than raw model power — specifically bidirectional MCP for inter-agent communication, async event buses for parallel execution, strict unified validation for model fallbacks, and tiered routing (evidence: single vendor write-up reporting a pattern; uncorroborated as a general finding). Read as engineering advice, each is actionable:
- Bidirectional MCP — agents both call and are called, so communication is a protocol, not a prompt hack.
- Async event buses — steps that don’t depend on each other run in parallel instead of blocking.
- Unified validation — every model output, including from fallback models, passes the same validator, so swapping models can’t smuggle in unchecked output. (Tiered routing across models — cheaper models for easy steps, stronger for hard ones — pairs naturally with this; see the control surfaces in Gemini Omni 1.1 Flash.)
The through-line: none of these are AI techniques. They are distributed-systems fundamentals applied to agents.
The real hard problem: defining and checking "correct"
When code becomes cheap to produce, the reported hard part shifts to deciding what "correct" means and building a reliable way to check it (evidence: uncorroborated as a law, but consistent with the cost-inversion mechanism described above). This is the crux the rest of the pipeline serves. Concretely, it means the spec and the gate are the two highest-leverage stages: the spec fixes the target, the gate enforces it, and a checker that can be fooled makes all the upstream generation worthless. This site’s dedicated treatment — when code gets cheap, correctness gets expensive — walks through building checks that resist being gamed.
Learning the discipline
Two learning resources are worth naming, with their nature stated plainly. GH-600 (GitHub Certified: Agentic AI Developer) resources are reported to cover building, orchestrating, evaluating, and governing AI agents with GitHub Copilot and modern SDLC practices (evidence: uncorroborated description; indexed among the awesome-github-agentic-ai collection). Separately, a Persian-translated guide is described as based on OpenAI’s "Building an AI-native engineering team," aimed at engineering leaders integrating agents into the SDLC (evidence: uncorroborated; self-described basis and audience). Both are orientation material, not certification of the underlying claims.
Evidence from one in-production pipeline
The frameworks above are mostly self-described. This site runs a gate-driven agentic pipeline of its own, so the following are measurements — of one system, over one window, not independent benchmarks — and each is attributed accordingly.
Across playagit’s own pipeline runs (n=48 runs, 2026-08-28–2026-09-08):
- The quality gate reviewed 319 drafts: 179 published, 103 sent back to revise, and 37 rejected (source: playagit’s own ledger, n=48 runs). The revise-and-reject share — 140 of 319, roughly 44% — is the concrete cost of enforcing a gate rather than trusting output.
- Across 2,409 research dossiers holding 7,918 claims, 220 were independently cross-checked and 1,150 were primary-attested (source: playagit’s own ledger, n=48 runs). The gap between those two counts and the total is exactly the uncorroborated remainder this article’s evidence discipline exists to flag.
- Of 18,933 scored topics, 7,091 were held before production and 9,069 rejected; 2,773 went to production (source: playagit’s own ledger, n=48 runs).
- 16,481 topic candidates were discovered across 4 categories from 204 distinct source hosts (source: playagit’s own ledger, n=48 runs).
- 205 posts were published (179 new, 0 updated) (source: playagit’s own ledger, n=48 runs).
The shape of these numbers is the argument: most candidates never reach production, and of drafts that do reach the gate, a large fraction are turned back. In an agentic pipeline, the checker is where the throughput goes — exactly as the "correctness is the hard part" claim predicts.
How this is applied here
Vision applies these patterns rather than merely cataloguing them, and does so gate-first. Every stage of its publishing pipeline emits a durable verdict to a ledger — the same discipline icebox-cli describes for in-repo sign-offs — which is why the figures above exist to be quoted at all. Topics pass a scoring gate before research; research produces dossiers whose claims are tagged by evidence level (independently cross-checked, primary-attested, or uncorroborated); drafts pass a quality gate that can publish, revise, or reject; and the ledger records each verdict so the pipeline is auditable after the fact. Two design choices mirror the field: correctness is enforced at the gate, not assumed at generation, and evidence provenance is carried claim-by-claim through the pipeline rather than asserted once at the end — the same layered discipline this very article follows. The uncorroborated framings above stay flagged for a reason: the pipeline that produced this piece is built to keep them flagged.