Evidence note: this article rests on two kinds of material, kept distinct throughout. The first is primary sources — public repository documentation, vendor blog posts and author write-ups — where the verifiable fact is that a project or person stated something, not that the statement has been independently tested; several of the projects described here have no independent corroboration available, and that is noted where it matters. The second is PlayAgit’s own pipeline records, which are measurements the project took of its own system; each is attributed to the run window and sample size it came from, and none of them constitutes outside verification of anything.
Why agentic delivery frameworks make gates explicit
A cluster of public projects published over recent months share one structural idea: when an agent produces the work, the checkpoint between steps has to become an artifact rather than a habit. Whether that pattern is now common across agentic delivery frameworks is an open question — the claim that explicit quality gates have become the standard control mechanism for agent-produced work is not independently corroborated, and should be read as a pattern visible in a handful of self-published projects rather than an established industry norm.
The most explicit of them is the icebox-cli process framework. According to its own documentation, the framework argues that continuous integration and continuous delivery assume humans write the code, that this assumption is now broken, and that the successor is "AI/CD" — agentic integration and continuous delivery — with eventual autonomous delivery as the end state. Its documentation also states that GitHub uses the term "Continuous AI" and that PwC has published on the agentic software development lifecycle, but that neither offers an implementable framework; that is the framework author’s own assessment of competing work, not a neutral finding.
The framework is described as six steps, five gates and a production feedback loop, attributed to an author reported as having four decades of software experience and six months of running agents in real delivery pipelines. Both the authorship details and the six-step/five-gate structure are uncorroborated — no independent source confirms them, and the structure should be treated as how the project describes itself.
What counts as evidence for a gate decision
The more interesting part of the icebox-cli design, for anyone evaluating it, is what it accepts as proof that a gate was passed. Its own documentation states the governance layer is platform-agnostic — supporting GitHub, GitLab, Azure DevOps and Jira in any source-control combination — and that each gate is backed by real evidence living in the repository: pull requests, issue comments and gate sign-offs. Independent verification that this works across all four platforms is open; the platform-agnostic claim rests on the project’s own description.
That design choice has a plain consequence worth naming. If a gate’s evidence is a pull request or a signed-off comment, the gate leaves a count behind: how many passed, how many were returned, how many were refused. A gate with no artifact leaves nothing to audit afterwards. This is the same seam explored in our earlier look at review roles, delivery gates and evidence in agent-built software.
Adjacent projects point the same way without claiming the same scope. AgentCheck describes itself as an open-source subagent for Claude Code that runs code review locally across five focused reviewers — logic, security, style, guidelines and product — and its author argues that comparable hosted tools flood pull requests with noise, run opaquely, bill per seat and intervene too late and without access to the developer’s own environment. That is the author’s stated position; independent assessment of either the tool or the criticism is open.
PlayAgit’s run records, August 28 to October 1, 2026
Against that backdrop, it is worth putting numbers from a pipeline that actually logs its gates — with the caveat that these are self-measurements, not a benchmark.
In playagit’s own pipeline runs (156 runs, 2026-08-28 to 2026-10-01, as of 2026-10-01), 28,972 topic candidates were discovered across 4 categories from 223 distinct source hosts (own measurement; not independent verification). Over the same 156 runs and the same window, 34,185 topics carried a score.
Those two totals do not line up, and the records as supplied do not explain why: there is no mapping between the 28,972 discovered candidates and the 34,185 scored topics. Scored topics exceed discovered candidates by 5,213 — arithmetic derived from the two figures above, not a recorded field. Several explanations are plausible (topics rescored across runs, topics carried forward from before the window, separate counting units) and the records do not settle which applies. It stays open.
What the topic decisions counted
In playagit’s own pipeline runs (156 runs, 2026-08-28 to 2026-10-01, as of 2026-10-01), of 34,185 scored topics, 13,328 were held before production and 14,883 were rejected, while 5,974 went to production (own measurement; not independent verification).
Those three outcomes sum exactly to 34,185 — derived arithmetic — so the scoring stage is internally closed: every scored topic has a recorded disposition. Expressed as proportions of the scored population, holds are 39.0%, rejections 43.5% and production 17.5% (derived from the figures above). The held bucket is not a backlog of failures; it is the largest single category of decision the gate makes, which is the behaviour an explicit gate is supposed to produce.
What the evidence and review records counted
In playagit’s own pipeline runs (156 runs, 2026-08-28 to 2026-10-01, as of 2026-10-01), across 4,677 research dossiers holding 25,318 claims, 1,420 were independently cross-checked and 5,430 were primary-attested (own measurement; not independent verification). That is 5.6% cross-checked and 21.5% primary-attested, derived from those figures — meaning roughly three claims in four carried neither a second independent source nor a first-party attestation, and were therefore available only as hedged material.
In the same 156 runs over the same window, the quality gate reviewed 1,142 drafts: 934 were published, 131 were sent back to revise and 77 were rejected (own measurement; not independent verification). Those three outcomes sum to 1,142 exactly (derived), so the draft gate, like the scoring gate, closes on its own population. A comparable earlier slice of the same pipeline is described in our account of how 7,436 topic candidates became 75 published posts.
Where the publication totals stop reconciling
Here the records stop agreeing with each other, and the disagreement is the most useful thing in this article.
In playagit’s own pipeline runs (156 runs, 2026-08-28 to 2026-10-01, as of 2026-10-01), 986 posts were published, recorded as 309 new and 254 updated (own measurement; not independent verification). The new-and-updated breakdown sums to 563, which is 423 short of 986 — derived arithmetic. Separately, the draft gate over the identical runs and window records 934 publication outcomes, which is 52 short of the 986 reported posts (also derived).
Three totals that should describe one thing give three different answers. The records as supplied contain no field that reconciles them: no mapping from the 5,974 topics sent to production to the 1,142 drafts reviewed, and none from draft-gate outcomes to the post-level publication count. Whether the gap reflects an incomplete breakdown, posts published outside the draft gate, or different counting units across stages is open. What can be said is narrower and still worth saying: each gate is internally consistent, and the joins between gates are not recorded.
What developers can assess next
Three threads from the public material are worth evaluating against your own pipeline, none of them independently verified.
The first is evaluation granularity. Behavioral evaluations — fast, local, unit-style tests asserting on discrete intermediate actions such as a specific tool call or file modification, rather than on final string equality — are reportedly recommended for evaluating coding agents, in a write-up on evaluating and guarding AI coding agents. The accompanying arguments — that end-to-end benchmarks such as SWE-bench are expensive, slow and short on root-cause diagnostics, and that cheap micro-checks alongside macro benchmarks allow prompt iteration and model upgrades without regression risk — are likewise uncorroborated positions rather than measured results.
The second is skepticism as practice. A developer-advocacy argument that professional skepticism is a developer’s best skill in an AI-driven world is attributed to BrowserStack’s head of developer advocacy and open source, along with the position that fixing flaky tests comes down to managing application state. Both are that author’s stated views; neither is independently confirmed here.
The third is persistent context. Because coding agents are said to be stateless across sessions, several frameworks externalize context — VibrationPlan describes itself as the lifecycle adapted for stateless agents, built on specialized roles, explicit handoffs and living documentation; Distillery describes itself as an MCP server giving sessions persistent shared team context, built in just over a week as 50,000 lines of Python comprising 16,000 production, 25,000 test and 7,000 documentation lines, with its author arguing that coding an epic is no longer the long pole and that knowledge now outpaces teams; and cc-pipeline describes an autonomous pipeline running spec, research, plan, build, review, fix, reflect and commit with a fresh context window per step, whose author reports trying tmux with send-keys first and not recommending it, and reports roughly a dozen runs including an Elixir gateway port, two kanban boards, a statistical analysis in R, Tetris twice from one brief, and a platformer attempt that failed. Each of these is the project’s own account. Related distribution and scale proposals — Copilot plugins as a way to keep shared instructions, skills and MCP configurations current across teams, an Elixir agent SDK reported to run 10,000 agents at about 25KB each without container orchestration, a context-engineering workflow tool for opencode, a collection of agentic engineering patterns alongside the observation that vibe coding and agentic engineering are converging more than their author would like, and a platform and team-topologies framing that codifies the rules into the platform underneath — are all uncorroborated at this point. So is the existence of a broader set of repositories and certifications scoped explicitly as agentic-lifecycle projects, including a Persian translation of an engineering-leadership guide, a curated agentic-AI resource collection, two further lifecycle repositories, a multi-agent system described as automating the lifecycle from project creation through deployment to GitHub Actions, and an orchestration engine described as a dependency graph with gates, governance and observability, demonstrated on a URL shortener. Those last two are each the repository’s own self-description; independent corroboration of either is open.
The follow-up question
The concrete question this article leaves is not about any of those frameworks. It is: which records connect topic decisions to reviewed drafts to published posts? A pipeline can have three internally consistent gates and still be unable to answer "which held topic became which published post." The icebox-cli design’s answer — a pull request, an issue comment, a gate sign-off — is an identifier that survives across stages. Counts alone do not join. Readers evaluating their own agentic pipeline can test this cheaply: take one published artifact and walk it backwards through every gate it passed. If the walk breaks, the gates are logging decisions without logging lineage. Our earlier piece on how agentic frameworks use review roles, gates and shared context covers the role side of the same problem.
How we apply this in Vision
The figures above change what gets treated as a finished measurement in this pipeline.
In playagit’s own pipeline runs (156 runs, 2026-08-28 to 2026-10-01, as of 2026-10-01), 28,972 topic candidates were discovered across 4 categories from 223 distinct source hosts, and 34,185 topics were scored — with no supplied mapping between the two totals. Because that join is missing, discovery volume is not read here as a predictor of anything downstream; it is reported as a stage count only.
In those same 156 runs over that same window, of the 34,185 scored topics, 13,328 were held before production, 14,883 were rejected and 5,974 went to production. Because those three outcomes close exactly on the scored population, the hold rate is treated as a usable operating signal — a held topic is a recorded decision, not a dropped one.
In those same 156 runs over that same window, 4,677 research dossiers held 25,318 claims, of which 1,420 were independently cross-checked and 5,430 were primary-attested. That ratio is the reason the hedging rules in this pipeline are a default rather than an exception: on this measurement, most claims arrive without either form of backing.
In those same 156 runs over that same window, the quality gate reviewed 1,142 drafts and recorded 934 published, 131 sent back to revise and 77 rejected — while the post-level record for the identical window reports 986 posts published, broken out as 309 new and 254 updated. Three totals, three answers. Until a record joins them, the draft-gate count of 934 is the figure used internally for review throughput, and the 986 figure is used only for publication volume, with the discrepancy carried as an open item rather than averaged away.