In May 2026, Microsoft published Agentic-Agile: Why Agent Development Needs Agile (Not Just Prompts) — a thoughtful, well-argued piece making the case that prompt-driven development breaks down at scale and that formalizing agent collaboration with specs, backlogs, and governance is the answer. They open-sourced a template repository (MIT license) with CLAUDE.md, STYLE.md, issue templates, and a five-value manifesto.
The article is right about the problem. Prompt-driven development does produce code that works in isolation and breaks under integration. Behavior does drift across sessions. Defects do escape into production when there is no review gate.
But the answer Microsoft proposes — a codified methodology with templates, ceremonies, and a manifesto — feels like 2001 all over again. The original Agile Manifesto was a rebellion against heavyweight process. Agentic-Agile, for all its genuine insight, risks becoming the very thing Agile rebelled against: a methodology sold as a solution, adopted as a religion, and applied regardless of context.
The open-source community, as usual, has been running a different experiment entirely. Not one methodology, but dozens. Not a template, but a toolbox. Not top-down adoption, but bottom-up evolution. And while Agentic-Agile is still debating its values, OSS projects have been shipping production code with AI agents for over a year.
Here is what the open-source ecosystem actually reveals about building software with agents — and why the corporate world would do well to pay attention.
The Problem Microsoft Correctly Identifies
Let us give credit where it is due. The core diagnosis is sound:
"The breakdown happens when scope grows. A multi-module system. An integration layer with external dependencies. A feature that spans files, schemas, and behavioral contracts."
The symptoms Microsoft lists — no backlog, no concept of done, no phased delivery, no governance — are real. Anyone who has tried to build something non-trivial with AI agents recognizes them immediately. And the article's conclusion — "This is not a model problem; it is a process problem" — is the single most important insight in the piece.
Where the article and I diverge is what to do about it. Microsoft proposes one methodology (Agentic-Agile), one template (the GitHub repository), and one manifesto (five values, thirteen principles). It is a clean, coherent package — the kind of thing enterprises love because it can be mandated, measured, and gated.
But software development — especially agent-assisted development — does not work that way. It is messy, context-dependent, and evolving faster than any template can track.
The Open-Source Landscape: Not One Methodology, But Dozens
While Microsoft was refining its manifesto, the open-source community was building. By mid-2026, a rich ecosystem of agentic development frameworks had emerged — each representing a different hypothesis about how humans and agents should collaborate.
BMAD-METHOD (Breakthrough Method for Agile AI Driven Development, 35k+ GitHub stars) takes a supervised, human-led approach. It separates planning from execution: dedicated planning agents (Analyst, PM, Architect) collaborate with the human to produce detailed PRDs and architecture documents. A Scrum Master agent then transforms these plans into hyper-detailed development stories that contain everything the Dev agent needs — full context, implementation details, architectural guidance — embedded directly in story files. The human stays in the loop at every stage. BMAD's insight: context loss kills agent quality, so build context into the artifacts, not around them.
Sprint (by Damien Lainé) takes a radically different approach. It runs as a Claude Code plugin — a spec-driven, self-iterative state machine. You write specifications, run /sprint, and the orchestrator dispatches specialized agents (Architect, Implementation, Testing) through defined phases, looping autonomously until the work is done or validation fails. The key innovation is what its creator calls "convergent multi-pass": each iteration reduces noise and clarifies the solution, like a diffusion process. Specs shrink as work completes. Errors get erased. Working code stays untouched. Most sprints converge in under 5 iterations. Sprint is technology-agnostic — while it ships with Python/FastAPI and Next.js agents, an allpurpose-agent adapts to any stack.
AI-Scrum (by Michael Bleterman) maps Scrum roles to Google ADK agents. A PM agent translates human input into sprint files. An Orchestrator agent assigns tasks by role. Backend/Frontend/DevOps agents execute in parallel. A QA agent validates outputs in a defect detection loop. Learnings persist in a ChromaDB vector store between sprints — the AI equivalent of tribal knowledge. Early results show genuine clock-time reduction for well-scoped parallel tasks, but also reveal brutal environment overhead costs that dominate token budgets on small sprints.
AgenticScrum (by safer-strategy) also maps Scrum to roles — ProductOwnerAgent, ScrumMasterAgent, DeveloperAgent, QAAgent, SecurityAuditAgent — but distinguishes itself through "persona engineering." Each agent gets detailed configuration: role, goal, backstory, LLM configuration, capabilities, rules, and knowledge sources. The framework includes a setup CLI that scaffolds the entire project structure, generating foundational rules and persona definitions. A checklist-driven quality approach (Definition of Done, Code Review checklists) ensures thoroughness.
Agentic-PDLC (by Rafael Costa) automates the full Product Development LifeCycle, both upstream (ideation) and downstream (delivery), using a Kanban board that moves itself. When you approve a spec, the card moves. When an agent opens a PR, the card moves. You just approve or reject. The framework provides a shared rulebook (AGENTS.md) read by every agent — Claude, Jules, Gemini — all pulling in the same direction without copy-pasting context between tools. A CI auditor checks every PR for architecture violations before anything reaches main.
AgileCoder (by FPT Software AI4Code lab) takes the most academically rigorous approach. It "mimics real-world software development by creating a backlog of tasks and dividing the development process into sprints, with the backlog being dynamically updated at each sprint." The key innovation is task-orientation rather than fixed-role assignment — the opposite of how most agent frameworks work. AgileCoder uses a new dataset called ProjectDev for evaluating complex, real-world software requirements.
There are more. Wilson Kichoi's agentic_development_workflow defines a five-phase framework (Research → Specification → Task Breakdown → Execution → Verification) with human gates at every phase and persistent documents that survive across sessions. The Agentic Trio (by INNOQ's Daniel Westheide) argues that small teams of product manager, UX designer, and engineer — augmented by agents — can now handle both discovery and delivery, with the engineer's key role shifting from producer to "guardian" who builds the agent harness.
The notable thing about all these frameworks is not their individual quality (though some are genuinely impressive). What is notable is that none of them agree on fundamentals:
BMAD: sequential, supervised, human-in-the-loop at every step
Sprint: autonomous state machine, self-iterating
AI-Scrum: role-based parallel execution with environment overhead
AgileCoder: task-oriented, dynamic backlog
Agentic-PDLC: rulebook-based with automated board management
If you go looking for "the right way" to do agentic development, you will not find it. What you will find is a dozen different answers, each optimized for a different context.
What the Open-Source Community Gets Right
1. Bottom-Up Convention Over Top-Down Methodology
Microsoft's Agentic-Agile template proposes a set of files (CLAUDE.md, STYLE.md, CONTRIBUTING.md, issue templates) as a codified methodology. The open-source community arrived at these same files independently — but as conventions, not mandates.
CLAUDE.md originated as a Claude Code convention. It spread because it worked, not because someone declared it. The same happened with AGENTS.md (from Agentic-PDLC), .claude/project-map.md (from Sprint), and the "prompt files" that various frameworks autogenerate. These files emerged organically because developers needed a way to give agents project context that survived session boundaries.
This is how open source has always worked: a practice proves useful in one project, gets copied by another, and eventually becomes a convention. The difference between a convention and a methodology is that conventions evolve. They fork. They get adapted. A CLAUDE.md in a JavaScript monorepo looks nothing like one in a Go microservice. That is a feature, not a bug.
2. Speccing Before Building — But Not as a Ceremony
Every framework in the ecosystem validates Microsoft's claim that specs must come before prompts. But none of them treat spec-writing as a formal ceremony. BMAD builds specs through multi-agent collaboration. Sprint reads specs as markdown files and iterates on them. Wilson Kichoi's workflow generates SPEC.md as a persistent output document.
The open-source insight: specs are engineering artifacts, not administrative documents. They live in the repo, evolve with the code, and are written for the same audience as the code itself. The moment spec-writing becomes a "process" with required fields, review gates, and sign-offs, it stops being useful.
3. Agents as Contributors, Not Just Tools
Microsoft argues that agents should be treated as contributors. Every open-source framework that works does this by default — not because of philosophy, but because treating agents as tools produces worse results.
But "agent as contributor" means different things in different contexts. In Sprint, the architect agent writes project-map.md and maintains it. In BMAD, planning agents produce PRDs that structure the entire development cycle. In AgenticScrum, each agent has a "backstory" — a narrative context that shapes its behavior. The insight is that agents produce better output when they have ownership, context, and a clear identity. This is not sentimentality; it is a design principle supported by empirical observation.
4. The Review Bottleneck Is Real
If there is one finding that every framework agrees on, it is this: agent throughput exceeds human review capacity by a factor that can break your team.
The ZenDevy 2026 field assessment puts it bluntly: "When agent output speed exceeds human review speed, unreviewed code accumulates and becomes technical debt." The AI-gile Manifesto (a rolling document published by Elite Software Engineer) warns: "A team of one human and five agents with no WIP limit on 'awaiting review' is a team building technical debt at machine speed."
The practical solutions that have emerged are not about reviewing less, but about automating the review pipeline:
Agent-to-agent validation loops: AI-Scrum's QA agent catches regressions before human review
Automated CI gates: Agentic-PDLC's CI auditor blocks architecture violations
Risk-based review: Humans review based on risk, not exhaustively (Dan Bodar's "Harness Engineering")
Review queues with WIP limits: Treat review capacity as the bottleneck and plan accordingly
5. Governance From Day One, Not Day Zero
Microsoft says: "Put governance in the backlog from day one." The open-source ecosystem has a more nuanced take. Governance is essential, but it must be proportional to risk and evolvable as the project matures.
Agentic-PDLC takes the most explicit approach: its CI auditor checks every PR for architecture violations. But it also provides a "maturity model" — teams start with minimal gates and add more as they learn where agents produce dangerous output.
The key insight: governance that blocks is destructive. Governance that catches and surfaces is productive. A CI gate that rejects a PR because of a formatting violation is not governance; it is annoyance. A CI gate that says "this PR introduces a new dependency with a known vulnerability — here is the risk assessment" is governance.
Where Microsoft's Approach Falls Short
The Template Trap
Microsoft's Agentic-Agile template is well-crafted. But the moment a methodology becomes a template, two things happen. First, teams adopt the template without understanding why it is structured the way it is. Second, the template resists adaptation — modifying it feels like deviating from the "official" approach.
The open-source ecosystem, by contrast, builds frameworks that are designed to be forked, extended, and replaced. Sprint encourages creating custom agents for your tech stack. BMAD provides expansion packs for different domains. None of them present themselves as the "right" way.
The Scale Assumption
Microsoft's methodology is designed for teams — multiple humans, multiple agents, parallel execution, review gates. This is the right assumption for enterprise development. But a significant portion of agentic development is done by solo developers or very small teams.
For a solo developer, many of Agentic-Agile's recommendations (epic decomposition, wave planning, retrospective analysis with agents) are overengineered. What they need is simpler: a CLAUDE.md that works, a process for writing specs before prompts, and a review loop that does not assume another human is available.
The open-source frameworks recognize this diversity. BMAD embraces the human-supervised solo workflow. Sprint automates what BMAD guides. AgenticScrum lets you choose your roles. This flexibility is not a bug of the ecosystem; it is the entire point.
The Vendor Blind Spot
Microsoft's Agentic-Agile is platform-agnostic in principle, but in practice it assumes GitHub, GitHub Issues, and GitHub Copilot. The issue templates target GitHub. The copilot-instructions.md file is GitHub-specific. The sample workflow assumes the PR model of GitHub.
This is not cynicism — it is a genuine blind spot that comes from building methodology inside a platform company. The open-source ecosystem, by definition, cannot make that assumption. Sprint works in any Claude Code environment. AGENTS.md is tool-agnostic. The frameworks that work best are the ones that work anywhere.
The Missing Conversation: Cost
Almost none of the methodologies — not Microsoft's, not the open-source ones — seriously address the economics of agentic development. The one exception is AI-Scrum, which explicitly documents the brutal cost of environment setup (package installations, Playwright configuration, path resolution) that can dominate token budgets on small sprints.
This is a gap that will become more urgent, not less. As stronger models drive up per-token costs, and as teams scale their agent usage, the question of whether a framework is economically sustainable will matter as much as whether it produces good code.
The open-source community, to its credit, has started to address this. Sprint's convergent multi-pass model is explicitly designed to reduce wasted tokens — each iteration removes noise instead of adding it. Wilson Kichoi's five-phase workflow segments costs across phases, so you only spend expensive model calls on the parts that need them. But this remains an under-explored dimension of the problem.
What the Ecosystem Actually Tells Us
If you step back from the individual frameworks and look at the ecosystem as a whole, a consistent pattern emerges:
Specs before prompts — Every effective workflow starts with written specifications. Not to satisfy a process, but because agents produce better output when given structured contracts.
Context files work — CLAUDE.md, AGENTS.md, and their variants are not overhead. They are the single highest-leverage investment a team can make. They reduce context bloat, enable session continuity, and let agents ground themselves without scanning the entire codebase.
Review is the new bottleneck — Agent throughput will always outpace human review. The solution is not to review faster, but to build automated validation pipelines that catch what can be caught algorithmically, freeing humans to review what matters.
One size does not fit all — Solo developers need different processes than enterprise teams. Greenfield projects need different processes than maintenance. The frameworks that succeed are the ones that adapt to context, not the ones that prescribe it.
The methodology is not the product — The teams shipping the best code with AI agents are not the ones with the most sophisticated methodology documents. They are the ones who have internalized a handful of principles (spec first, automate review, maintain context) and adapted them to their specific constraints.
The Bottom Line
Microsoft's Agentic-Agile article is a useful contribution to an important conversation. It correctly identifies the failure modes of prompt-driven development and makes a compelling case for structured collaboration. The template repository is well-executed.
But the article presents Agentic-Agile as the answer, when the open-source ecosystem shows that there is no single answer — only a landscape of approaches, each optimized for different contexts, teams, and problems.
The open-source community's experiment with agentic development is not about finding the one true methodology. It is about building a toolbox diverse enough that every team can find what works for them, and flexible enough that what works can change as the technology evolves.
If I were writing the manifesto, it would be shorter than Microsoft's five values and thirteen principles. It would be closer to the AI-gile Manifesto's four values — Intent, Validation, Collaboration, Reversibility — or even shorter:
Trust the agent, but verify the output.
Specify the contract before the implementation.
Automate the review pipeline.
Adapt the process to the context.
Keep the human in the steering loop.
The ceremonies, templates, and frameworks that surround these principles are decorations. They help, but they are not the point. The point is that building software with AI agents requires new disciplines — disciplines that the open-source community is discovering, sharing, and evolving in real time.
The best thing Microsoft could do next is not to refine its methodology. It is to get out of the way and pay attention to what the ecosystem is already teaching us.
This article is part of an ongoing series on AI-assisted software development. The frameworks mentioned are linked below for reference: