Choosing an Agentic Delivery Framework: Which Ones Redesign the Work and Which Just Add Ceremony

You've been handed a sentence and an afternoon. The sentence is "pick us an agentic framework." The afternoon is a dozen GitHub tabs, each repo claiming to be the operating system for AI-assisted development, each with a star count and a README that reads like the others. Somebody upstream wants a decision by Friday, and the honest pressure is to adopt the loudest option, wire it in, and move on.

Here's the trap in that pressure. This is a field pattern I keep running into, not a measured study: a team installs a framework, adoption climbs, everyone's running slash commands and spec files by week two, and six months later the delivery signals haven't budged. Lead time looks flat. Review latency can even get worse, plausibly because generated changes push up review volume and pull-request size, though workload and process shifts are confounders you'd have to rule out. The framework got adopted.

The work never changed.

And now "we're using an agentic framework" is a line in a board deck that describes activity, not capability.

So before you rank these repos by features, it's worth asking a different question. Not "which one has the most commands" but "which parts of how your team actually works would this change, and would it leave a trace you could inspect afterward." That question reorders the whole field.

The quick answer: choose by consequence, not by feature count

No context-free ranking tells you which framework fits your team. Capability comparisons, star counts, and compatibility checks are real inputs, they just aren't the decision. The decision is which parts of your delivery operating model you're willing to redesign, and which framework's shape matches that intent.

There are three legitimate paths, and none of them is presumptively best. Adopt one framework wholesale and accept its opinions. Adopt a leader as a backbone and graft the pieces it's missing. Or compose your own from components across the field. Which path fits depends on how much of the operating model you're actually allowed to change, and how much integration work your team can own.

Key takeaways

• Read each framework by which of the seven operating-model components it touches and which artifacts it actually produces, not by how many commands it ships. The artifact classes to look for are mapped in the six-class AI engineering stack.
• A framework becomes an operating-model change only if your team adopts and governs it that way. The repo alone doesn't guarantee the change; it just makes it possible.
• The field groups into a handful of shapes: spec-first backbones, full role-and-lifecycle models, traceability and governance layers, compounding-improvement loops, and a long tail of lighter toolkits.
• Compose-your-own is a real option, not a cop-out, but it only pays off when your team explicitly owns the interfaces, the review gates, and the upgrade policy. Otherwise you've bought integration debt instead of framework ceremony.
• The strongest warning sign across every shape is ceremony with no artifact. If a framework adds prompt ritual but leaves no changed spec, no decision log, no quality-gate config behind, it's likely adding surface, not substance. Artifacts aren't proof on their own; you still check that they're used, kept fresh, and signed off.

Why a ranking answers the wrong question

Most of what's already published on these repos is a feature-and-star-count comparison. What commands it ships, how many roles it bundles, whether it's Claude-Code-native or portable. Those articles answer "what does it have." They can't answer "what will change about how your team works," because they never model the work.

That gap is the opening. These frameworks aren't interchangeable prompt wrappers whose differences are cosmetic. They're competing bets on a delivery operating model, and an operating model has structure you can name. Borrowing the language management uses for organizational design, a delivery operating model has seven components: roles/responsibilities, decision rights, workflows/handoffs, review & control standards, information/system access, incentives/performance measures, and operating cadence. Read a framework by which of those it redesigns, and the differences stop being cosmetic.

That lens is analytical, not a proven-complete taxonomy. Some of what matters most in an agentic setup, agent memory and context handling, execution isolation, model routing, security posture, observability, sits awkwardly inside "information/system access" and doesn't decompose cleanly into these seven. Treat the components as a management lens that surfaces the operating-model consequences a feature table hides, not as a scientific classification. It's a good enough map to make a defensible choice, and that's the job here.

There's a second lens worth naming, because it turns "does this change the work" from a feeling into something you can inspect. Call it the Shift Harness Artifact Test: after a team runs a framework for a few sprints, what durable artifacts does it leave behind? Six classes are worth looking for: changed specs, decision logs, QA plans / quality-gate configs, review patterns, governance evidence, and role-level playbooks. The artifact test isn't a scored pass/fail with a threshold to hit. It's an audit lens. You're checking whether the artifacts exist, whether they're complete, whether they stay fresh, whether they trace back to decisions, whether anyone signs off on them, and whether anything downstream actually consumes them. When these artifacts are maintained, approved, and consumed downstream, they're evidence the workflow may be changing. A framework that generates a nicer prompt and a busier terminal is adding ceremony to the same broken workflow.

The runbook: what to check on any framework in front of you

You don't need to memorize a model. You need a short set of checks to run on each repo, in order, so that by the time you close the tabs you can defend a choice. Here's the sequence.

Check 1: Which of the seven components does it actually touch, and how hard? Go component by component and grade the contact, don't mark a binary "redesigns it / leaves it alone." A framework can touch a component four ways: it can offer documented guidance (a standards file the model reads), produce an artifact (a spec, a plan, a log it writes to disk), automate a workflow (an ordered sequence of steps it drives), or technically enforce something (a gate a commit can't pass without). Those are very different levels of change. "Documents a review standard in a markdown file" and "blocks the merge until the review gate passes" are both "review & control standards," but only one of them survives contact with a team under deadline pressure.

Check 2: What artifacts does it leave behind? Run the artifact test. If you cloned this repo, ran it for three sprints, then walked away, what would remain? Changed specs you could diff. Decision logs you could read. Quality-gate configs a new hire would inherit. If the answer is "a chat transcript and some generated code," the framework has left little durable evidence that its operating-model effects can be audited.

Check 3: Does it fit your ground truth? Greenfield or brownfield. Solo developer or a multi-role team with a QA lead and an architect who need defined handoffs. Claude-Code-native or portable across tools. High-ceremony (lots of structure, slower, more defensible) or low-ceremony (fast, lighter, easier to abandon). A framework built for greenfield solo work will fight a brownfield multi-role team, and the fight shows up as the framework being quietly ignored by week three.

Check 4: Who has to own it for the change to stick? This is the check most feature comparisons skip. A framework that redesigns decision rights or review standards only works if someone on your team has the authority to install those changes. If the delivery lead can bolt on a tool but can't change who approves what, the operating-model components the framework targets stay frozen, and you get adoption without change. Map the framework's ambitions to your actual authority before you adopt.

Run those four checks and the twelve-repo blur resolves into a small number of distinguishable bets. Now group them.

Reading the field by operating-model shape

I'm naming specific frameworks here because you're going to see these names in the tabs, and naming them is more useful than abstract categories. None of this is a ranking, and none of it is a knock on any repo. Each shape is a legitimate bet on a different part of the operating model. Feature details below reflect where these projects sat in mid-2026; verify against the live repos before you commit, because several are moving fast.

Spec-first backbones

These redesign workflows/handoffs and review & control standards by making a written specification the pivot of the work. The model works against an agreed spec instead of an ad-hoc prompt, and the spec becomes the reviewable artifact. GitHub's Spec Kit sits here, and it has grown well past a narrow "spec backbone" into brownfield support, extensions, presets, and checkpoints. OpenSpec sits nearby with a tighter remit: it makes proposed changes explicit and structurally reviewable, and its validation checks structure rather than guaranteeing anyone actually agreed on intent. Agent OS belongs in this cluster too, as a standards-and-context layer that injects standards and specs into the model's context, not as a full role-and-lifecycle model. The trade-off across all three: a spec backbone changes what "done" means and gives review something real to bite on, but it adds a specification step that low-ceremony teams will resent, and a spec nobody rereads is just documentation with extra steps. This is the cluster to look at first if your delivery problem is that requirements evaporate between the ticket and the pull request. Spec-driven development is worth understanding on its own terms before you pick a backbone.

Full role-and-lifecycle operating models

These are the most ambitious bets. They redesign roles/responsibilities, decision rights, and operating cadence by defining a whole lifecycle with named agent roles and handoffs between them. BMAD is the clearest example, though it's worth separating its installed core from optional modules (a test-architecture module, for instance) and attributing each mechanism to the exact piece that provides it, rather than crediting the whole system for one module's feature. Superpowers is a complete lifecycle methodology in this family too, covering brainstorming, design, planning, test-driven development, subagents, and review as a connected sequence. The upside is real: if your problem is that AI-assisted work has no defined roles or handoffs, these give you a shape to install. The failure mode is equally real. A full lifecycle model imposes the most ceremony, and if your team can't or won't change decision rights and cadence to match, you get an elaborate structure that everyone routes around. These reward teams that genuinely have the authority to redesign how the function works. That authority question is the same one that separates a scrum master's process ownership from a spec's control layer, and it's worth being honest about before you adopt a model this opinionated.

Traceability and issue-native governance

These redesign workflows/handoffs, governance evidence, and information/system access by threading the work through a trackable chain. CCPM runs a chain from PRD to epic to tasks to GitHub issues to code and commits, so the work leaves a governance trail in the issue tracker rather than in a chat window; it's compatible with Agent Skills, and any bug-reduction figure the project cites is self-reported, so treat it as a claim rather than a benchmark. Spec Kitty takes a repository-and-worktree-native approach to work-package governance with human-in-the-loop gates, closer to the code than to the issue tracker. The bet here is that governance evidence should be a byproduct of the workflow, not a separate compliance exercise. The trade-off: this shape is oriented toward issue linkage, work-package records, and approval evidence, which is exactly what you want if you're heading toward a real security or regulatory review, and exactly the overhead a small team shipping fast will find suffocating.

Compounding-improvement loops

This is the narrowest and most specific bet. It redesigns incentives/performance measures and review patterns by feeding what the team learns back into the system so the next cycle starts smarter. compound-engineering is the clearest instance, and its compounding mechanism is a specific command that captures and reuses learnings rather than a general vibe of "it gets better over time." The appeal is that most frameworks are static: they set up a workflow and leave it there. A compounding loop tries to make the workflow improve itself. The catch is that a loop only compounds if the team actually runs it and acts on what it surfaces. Bolt it on without changing what gets measured or reviewed, and the loop spins without turning anything.

The long tail: lighter toolkits and catalogues

Not everything is a full operating-model bet, and some of these are better read as components than as frameworks. ai-dev-tasks is a lightweight PRD-to-task toolkit, useful when you want a little structure without a lifecycle. GSD is a lifecycle orchestrator with research, roadmaps, multi-agent orchestration and coordination, and quality gates, heavier than its "get stuff done" framing suggests. SuperClaude is behavioral configuration: its personas are model behavior modes, not organizational human roles, so don't read a role-allocation model into it. wshobson/agents is a catalogue and marketplace of agents rather than one coherent operating model, which makes it a source of parts rather than a system to adopt. Cluster these mentally as "components and light toolkits," and reach for them when you're grafting rather than adopting.

Here's the field mapped against the seven components. The cells are graded by contact type, not marked as a binary, because "documents a standard" and "enforces a gate" are not the same change.

Read the rows, not the totals. A row with a lot of "documented-guidance" is a framework that tells the model how to behave but leaves enforcement to you. The strongest grade, technical enforcement, means a machine-checkable control that fires at a named point (command execution, commit, CI, or merge); I've graded conservatively here and left it off cells I couldn't tie to a specific control in the current repos, so treat any enforcement claim as something to confirm against the live project. The long-tail row is a single aggregate over materially different projects; read the per-project descriptions above it, not the row. Neither pole is better in the abstract. The one that fits is the one whose actual controls match the components you most need to change.

The which-for-what: mapping real decisions to shapes

Feature tables compare frameworks to each other. What you need is a map from your situation to a shape. Read the "why" column as a hypothesis to test in a short pilot, not an established comparative result. These are directional, not prescriptions, and your ground truth overrides the table.

Notice that most rows point at a shape, not a single repo. That's deliberate. The shape is the decision; the specific framework within it is a compatibility-and-taste choice you make after the shape is settled.

The third path: compose your own

A ranking can't recommend "none of these, assemble your own," because a ranking has to name a winner. An operating-model lens can, and it maps cleanly to which components you choose to redesign. You might take a spec backbone from Spec Kit or OpenSpec, borrow CCPM's PRD-to-issue traceability, add worktree governance in the spirit of Spec Kitty, layer a compounding loop on top, and keep your own review gates and role playbooks. Each piece maps to a component, and the composition is just a deliberate answer to "which components am I redesigning and which am I leaving alone."

I want to be honest about when this pays off, because composing is where the architect's judgment earns its keep and also where teams talk themselves into more work than they saved. Composing trades adopt-and-go simplicity for fit. It's viable when the interfaces between the pieces are explicit, when someone owns the upgrade policy for each borrowed component, when review authority is defined, and when the team genuinely controls the review gates, decision rights, and cadence the composition assumes. When those are in place, a composed operating model can fit a team better than any single framework's opinions. When they're not, you've built integration debt that can cost more than the framework ceremony you were trying to avoid, and a homegrown mix that nobody owns is just ceremony with extra maintenance.

So compose-your-own isn't the sophisticated answer that the adopt-one path is a naive version of. It's one of three legitimate bets, and it happens to be the one that demands the most authority over your own operating model. If you have that authority, it's powerful. If you don't, adopting a framework wholesale and living inside its opinions is the more honest choice.

Questions to ask, and the red flag that cuts across everything

When you're in the tabs, a few questions do most of the work. Does this produce a changed spec, or a nicer prompt? Does it leave a decision log, or a chat history? Does it generate a quality-gate config a new hire inherits, or a workflow only its author understands? Would running this for three sprints leave anything on disk that a review could inspect? Which of the seven components does it enforce, versus merely document?

The warning sign is one thing, said many ways: ceremony with no artifact. A framework that adds ritual, more slash commands, more required files, more steps, but leaves behind nothing you could put in front of an auditor or a new hire, has probably changed the surface of the work and not its substance. That's the failure mode that produces high adoption and flat metrics, the one that turns "we use an agentic framework" into a claim about activity. Frameworks meant to improve repeatability or governance should leave inspectable evidence proportionate to those goals. The ones that leave none are asking you to take the change on faith.

What you're actually deciding

The tabs make this feel like a product comparison, and the pressure makes it feel like a Friday deadline. It's neither. Picking or composing an agentic delivery framework is deciding which parts of your delivery operating model you're willing to redesign, and which framework's shape matches both that intent and your authority to carry it out.

Whether any of these becomes a real operating-model change or just another installed tool won't be settled by the repo you choose. It'll be settled by whether your team adopts it as a change to how the work is governed, and whether anyone's checking that the artifacts it promised are actually showing up. Before you adopt another framework, it's worth running the one you already have through these same checks. Map it to the seven components. Look for the six artifacts. If your current setup is generating ceremony and no trace, a new framework won't fix that, and if it's already leaving artifacts behind, you may have less to change than the tabs suggest.

AI Transparency Notice: This article and its accompanying images were created with the assistance of generative AI. The author directed the content, contributed the underlying ideas and analysis, and reviewed the final publication.

Frequently Asked Questions