Evidence note: this article draws on three kinds of material, and they are not equally strong. The first is self-description — public repositories, project READMEs and vendor engineering blogs describing their own tools. The second is secondary discussion of an emerging vocabulary ("agentic SDLC", "Continuous AI") that no single body defines. The third is PlayAgit’s own pipeline ledger, which is a record of one publishing system’s behaviour and is not independent verification of anything outside it. Nothing in the first two categories below was independently corroborated for this article; where a figure or a named product feature appears, its evidence level is marked in place.
One Name, Many Repositories: What the Agentic SDLC Movement Actually Contains
Search for "agentic SDLC" on a code host and the phrase resolves not to a specification but to a cluster of unrelated repositories that happen to share a name. Several public projects carry it directly — among them one, another, a third, and a worked example built around a URL shortener. That these repositories exist under that name is observable; the stronger claim, that they constitute a coherent movement with shared definitions, is not established by the naming alone and should be treated as open (uncorroborated).
The practical consequence for a reader evaluating the space: there is no canonical reference implementation to compare against. Curated lists such as a collection of agentic AI work on GitHub aggregate the material but do not adjudicate between approaches. Readers tracking how this vocabulary is displacing CI/CD language may also want this site’s earlier survey of the agentic SDLC.
Agents as Contributors: Multi-Agent Systems That Build, Test and Deploy From Scratch Through GitHub Actions
The organising ambition attributed to these projects is that AI agents act as core contributors rather than assistants — writing, testing and deploying software as first-class participants in the lifecycle (claim not independently verified). Some implementations are described as multi-agent systems that carry a project from an empty repository through to deployment, using a code host’s own automation runners as the execution substrate (single-source; uncorroborated).
That architectural choice, if it holds, is doing something specific: it puts agent work inside the same audit surface as human work. A pull request, a workflow run and a job log are artefacts a reviewer can open months later. The distinction matters more than it sounds, because the alternative — agents acting through an out-of-band harness — produces changes with no durable record. This site has previously documented the failure mode where agent runs write to a repository and leave no usable trace.
Dependency Graphs, Gates, Governance, Observability: The Shape of an Orchestration Engine
Where these systems describe an orchestration engine, four components recur in the descriptions: a dependency graph for ordering work, gates that admit or block progress, governance rules over who may approve what, and observability over what actually ran (uncorroborated; drawn from project self-descriptions rather than from an inspected implementation).
Read sceptically, this is a restatement of ordinary workflow engineering with an agent placed at the work node. That is not a criticism — the hard part of agent delivery is not the model call but the surrounding state machine. But it does mean the four-component list is close to unfalsifiable as a claim: nearly any pipeline can be described this way after the fact. What would make it a real architectural statement is a published gate schema and a record of gates actually firing, and sources reviewed for this article do not provide one.
Engineering Leadership Catches Up: OpenAI’s Guide for AI-Native Teams and GitHub’s Agentic AI Developer Certification
Two artefacts aimed at engineering leadership are reported in this space. The first is a strategic guide for engineering leaders on integrating agents into the lifecycle, said to be titled "Building an AI-native engineering team" — a community translation project for Persian-speaking readers is the closest corroboration found, and the existence and exact contents of the original guide remain unconfirmed here (uncorroborated).
The second is a certification reported as "GitHub Certified: Agentic AI Developer (GH-600)", covering building, orchestrating, evaluating and governing agents alongside modern lifecycle practice (uncorroborated; the certification code and syllabus were not verified against a vendor certification page for this article). Both are worth watching for the same reason: certifications and leadership guides are lagging indicators. They appear when a practice is stable enough to examine, which would suggest the vocabulary is consolidating — but a reader should confirm both directly with the vendors before citing either.
The Assumption CI/CD Was Built On, and Why Agent-Driven Delivery Breaks It
The argument advanced by several of these projects is that continuous integration was designed around an assumption that a human wrote the code, and that agent-driven delivery invalidates it (uncorroborated as a general claim, though it is internally coherent).
The assumption shows up in small places. Review capacity is assumed to be the scarce resource and authorship the abundant one; agents invert that. Commit volume is assumed to track effort; it no longer does. A failing test is assumed to indicate a mistaken intention rather than a plausible-looking hallucination. None of this breaks a build system mechanically — pipelines run the same either way. What breaks is the inference a team draws from a green build, because the code that turned it green was produced by a process whose failure distribution is different from a human’s.
From AI/CD to AI/AD: Six Steps, Five Gates, a Production Feedback Loop, and Sign-Offs That Point at Real Artefacts
One open governance framework is described as defining six steps and five gates with a production feedback loop, where each gate is backed by real evidence — pull requests, issue comments, recorded sign-offs — rather than a checkbox (uncorroborated; the step and gate counts come from the framework’s own description). A published process document for one command-line project illustrates the general shape of writing such a process down.
The naming proposed for the transition — AI/CD, read as agentic integration with continuous delivery, moving eventually to AI/AD, autonomous delivery — is reported but not established terminology (uncorroborated). The substantive idea underneath the branding is the evidence requirement: a gate that emits a pointer to an artefact is auditable, and a gate that emits only a pass flag is not. That distinction survives whether or not the acronyms do.
Frameworks in this category also claim platform independence across major code hosts, issue trackers and source control combinations (uncorroborated; portability claims of this kind are rarely tested in public).
Vocabulary Without Implementation: Why ‘Continuous AI’ and the Consultancy Write-Ups Stop Short
A recurring criticism within these projects is that the large institutions have supplied vocabulary without implementation: a code host promoting "Continuous AI" and a major consultancy publishing on the "agentic SDLC", with neither offering a framework a team could adopt (uncorroborated; this characterisation comes from the critics, and the referenced publications were not read for this article).
The criticism is worth holding at arm’s length, because it is also a competitive claim — open-source projects benefit from arguing that incumbent terminology is empty. What can be said neutrally is that terminology and implementation diffuse at different speeds, and that a term with many definitions and no reference implementation is one a buyer should ask pointed questions about.
What PlayAgit’s Own Gates Did Between 28 August and 12 September 2026: 497 Drafts, 348 Published, 112 Sent Back, 37 Refused
Against that backdrop, one set of numbers in this article is not a report about someone else’s system. In PlayAgit’s own pipeline runs — 80 runs recorded between 28 August and 12 September 2026 — the quality gate examined 497 drafts and returned three distinct verdicts: 348 published, 112 sent back for revision, and 37 rejected outright, as of 21:18 UTC on September 12, 2026.
The distribution is the interesting part. A gate that only passed and failed would have collapsed those 112 revisions into one bucket or the other; keeping "send it back" as a separate outcome is what makes the gate a step in a loop rather than a filter at the end of one. Roughly three in ten drafts did not pass on first presentation. That is PlayAgit’s own measurement on PlayAgit’s own pipeline over those sixteen days, not a benchmark, and it says nothing about what rate another system should expect.
Twenty-One Thousand Scored Candidates and the 10,079 That Never Reached Production
The same 80 runs over 28 August to 12 September 2026 scored 21,404 topic candidates. Of those, 8,064 were held before production, 10,079 were rejected, and 3,261 went to production — again, PlayAgit’s own ledger figures for its own pipeline, with no external comparison available.
Two observations follow. First, the rejection stage is where nearly half the volume disappears, well upstream of any gate on written drafts: by the time the quality gate sees a draft, most of the selection work has already happened. Second, the held bucket is larger than the produced bucket. Holding is a real state with a cost — deferred candidates accumulate — and a system that reported only pass and fail would show a production rate roughly twice as favourable as the one the full ledger supports.
Where Gate Evidence Stops Being Evidence
The limits are visible in the same records. Across those 80 runs between 28 August and 12 September 2026, PlayAgit’s pipeline produced 2,690 research dossiers holding 10,169 individual claims. Of those claims, 375 were independently cross-checked and 1,639 were primary-attested — that is, traced to the subject’s own official statement.
Stated plainly: on PlayAgit’s own measurement, under four percent of claims passing through the pipeline in that window received independent cross-checking, and about sixteen percent were confirmed only against the source that made them. Primary attestation is a weaker guarantee than it looks — it establishes that a party said something, not that the thing is true. This is the precise point at which gate evidence stops functioning as evidence: a gate can record with certainty that a check ran, and record nothing at all about whether the check was strong enough to matter. Any gate-counting dashboard, including PlayAgit’s, is vulnerable to this confusion.
Why End-to-End Benchmarks Cannot Tell You Where the Logic Broke Down
The reported critique of end-to-end agent benchmarks such as SWE-bench is that they are expensive to run, slow to iterate on, and diagnostically blunt: a task-level pass or fail does not say which step of the agent’s reasoning collapsed (uncorroborated; no cost or runtime figures were verified for this article).
This is the same structural problem as the gate-evidence limit above, viewed from the other end. A binary outcome over a long trajectory compresses away everything a maintainer needs — whether the agent picked the wrong file, called the right tool with wrong arguments, or produced a correct patch that a harness mis-scored. This site’s earlier examination of what LLM evaluations actually assess covers the adjacent problem of small evaluations that cannot separate models at all.
Behavioral Evaluations: Asserting on Tool Calls and File Edits Instead of Final Strings
The proposed alternative is a behavioral evaluation: a fast, local, unit-style test that asserts on discrete intermediate actions — that a specific tool was called, that a particular file was modified — rather than on equality of a final output string. Google’s developer blog discussion of evaluating and guarding AI coding agents sets out this framing (the recommendation is reported; its effectiveness is not independently demonstrated in sources reviewed here).
The appeal is mechanical rather than theoretical. String equality on generated prose or code is the wrong assertion for a non-deterministic system: it fails on paraphrase and passes on plausible nonsense. Asserting that the agent opened the configuration file and called the migration tool is checkable, stable across rewording, and localises a failure to one step. The cost is that the assertions encode one accepted path, and an agent that solves the task a different way will fail a test it arguably should pass.
Cheap Micro-Checks Beside Expensive Macro Benchmarks: Changing Prompts and Upgrading Models Without Regressions
The companion argument is that cheap micro-checks sitting alongside expensive macro benchmarks are what let a team edit a system prompt or swap in a newer model without shipping a regression (uncorroborated; presented as recommended practice, with no published before-and-after data verified here).
The reasoning is familiar from ordinary testing economics. A suite that costs little runs on every change; a suite that costs a great deal runs before a release, if then. Without the cheap layer, prompt edits go out unverified because verification is too expensive to bother with, which is exactly when silent regressions enter. A team weighing this should ask what the micro-check layer costs to maintain, since assertions on intermediate tool calls are tightly coupled to an agent’s internal structure and break when that structure changes for legitimate reasons.
Five Reviewers on Your Own Machine — Logic, Security, Style, Guidelines, Product — Against the Hosted Bot That Floods the Pull Request
AgentCheck is presented by its own repository as an open-source subagent that performs code review locally through five focused reviewers covering logic, security, style, guidelines and product concerns. That is the project’s own description of itself and has not been independently evaluated for this article.
The case made against hosted review bots — the named example being Cursor Bugbot — is that they flood pull requests with low-value comments, operate as a black box, bill per seat, arrive too late in the cycle, and cannot reach the tools in a developer’s own environment (these are reported criticisms, not verified findings, and the vendor’s response was not sought). Two of the five points are structural rather than matters of quality: running after a pull request exists is genuinely later than running before a commit, and a hosted service genuinely cannot invoke a local toolchain. Whether local review produces better findings is a separate question that the architecture argument does not answer.
Structure Beat Raw Model Power: Bidirectional MCP, Async Event Buses, Unified Fallback Validation, Tiered Routing
A review of strong submissions to an AI agents competition reports four recurring engineering patterns: bidirectional Model Context Protocol connections for inter-agent communication, asynchronous event buses enabling parallel execution, strict unified validation applied to model fallbacks, and tiered routing that keeps expensive inference calls to a minimum. The write-up of those patterns is the source; the patterns are an observation about one judged cohort, not a controlled comparison (uncorroborated as a general finding).
The broader conclusion drawn — that structural engineering beats linear prompt chaining on resilience, latency and cost — is plausible and unproven in the material reviewed (uncorroborated). Note the selection effect: patterns observed in winning entries are patterns of entrants who also had the engineering maturity to win, which is not the same as patterns that cause winning.
When Coding Is No Longer the Long Pole: 50,000 Lines in Just Over a Week and the Knowledge That Has to Outlive the Session
Distillery is described by its own repository as roughly 50,000 lines of Python — about 16,000 production, 25,000 test and 7,000 documentation — designed, built and shipped in just over a week. That breakdown is the project’s own account, not independently audited, and line counts are in any case a weak proxy for delivered value (uncorroborated).
The claim built on top of it is the more consequential one: that writing the code for a unit of work is no longer the longest pole in the lifecycle, and the bottleneck has moved to capturing and retaining knowledge across sessions (uncorroborated). One response is persistent shared team context delivered through a context server that records design decisions and feeds them back into later sessions — one such project publishes work in this direction, though its effectiveness is unverified here. Related frameworks adapt the lifecycle to stateless agents using specialised roles, explicit handoffs and living documentation (uncorroborated).
A Fresh Context Window Per Phase: An Unattended Loop From Brief to Commit, a Dozen Projects, and the Platformer That Failed
cc-pipeline describes itself as orchestrating a coding agent through an automated loop — specification, research, planning, building, review, fixing, reflection, commit — with each step receiving a fresh context window through the Claude Agent SDK. Its stated input is a single brief document describing the desired build, from which it runs phase by phase unattended (self-described; not independently verified).
The project’s own account reports roughly a dozen runs, including two kanban boards, two Tetris implementations, an R statistical analysis, and a platformer attempt that failed (uncorroborated). The reported failure is the most useful data point in that list, and it is also the least detailed — without knowing which phase broke, a reader cannot tell whether the loop or the task was at fault. The project also reports having tried terminal-multiplexer key injection to reset context between phases and having abandoned it in favour of a genuinely fresh window per step (uncorroborated).
Frameworks Written for Humans, and Agents That Design Their Own Workflows
Jido presents itself as an Elixir agent SDK that runs thousands of agents at roughly 25KB each without container or cluster infrastructure, and proposes that agents manage their own workflow design life cycle to reduce the human intervention needed to build workflows. Both the per-agent footprint figure and the autonomy proposal are the project’s own claims; neither was measured for this article (uncorroborated — and per-agent memory figures are highly sensitive to what is counted).
The underlying complaint — that existing agent frameworks were written for humans, leaving language models to work around assumptions about human work styles — is a reasonable critique and an unverified one (uncorroborated). Adjacent work includes context engineering tooling for coding agents, Simon Willison’s observation that vibe coding and agentic engineering are converging, and his standalone guide to agentic engineering patterns.
What Running This Costs: Tokens, Infrastructure, and the Platform Question for AI-First Teams
The cost question is where the architecture arguments above become budget decisions. A discussion of the economics of agent scale frames the concern: at volume, token spend and supporting infrastructure push organisations toward building internal platforms for AI-first teams rather than leaving each team to assemble its own (uncorroborated as a general conclusion; no cost figures were verified here). Reported remarks by Andi Gutmans, described as head of Agentic Data Cloud at Google, on judgment, code review and data activation belong to a conversation series that could not be checked for this article, and should be treated as open until read at source.
Tiered routing, cheap micro-checks and local reviewers all reduce the same bill. Self-hosted components carry their own long-tail costs, as this site’s coverage of keeping an end-of-life storage component patched illustrates.
PlayAgit Benchmark
The figures below are PlayAgit’s own ledger records for its own publishing pipeline. They are measurements of one system, not verification of anyone else’s.
Across 80 pipeline runs recorded between 28 August and 12 September 2026, PlayAgit’s own run records show 18,576 topic candidates discovered across four categories from 213 distinct source hosts. Over the same 80 runs and the same sixteen-day window, 21,404 topics were scored, of which 8,064 were held before production and 10,079 rejected, leaving 3,261 that went to production. The published end of the same records, for the same 80 runs between 28 August and 12 September 2026, shows 394 posts published, comprising 211 new posts and 74 updates.
Three things follow, and each is bounded by that one sample. First, discovery is not the constraint: 18,576 candidates entering the funnel against 394 posts leaving it means selection, not sourcing, determines output. Second, the gate is doing real work — over those same 80 runs the quality gate reviewed 497 drafts and returned 112 for revision and 37 rejections alongside 348 publications, so nearly three drafts in ten did not pass as written. Third, and most limiting: of 10,169 claims held across 2,690 research dossiers in that window, only 375 were independently cross-checked while 1,639 rested on the subject’s own attestation. A pipeline can hold a high rejection rate and still carry mostly single-sourced claims, because rejecting weak topics and verifying strong ones are different jobs. On this sample, the first is running at scale and the second is not.