Agentic-Agile: Why Agent Development Needs Agile (Not Just Prompts)

“A bad system will beat a good person [or agent] every time” ~Dr. William Edwards Deming (with apologies)

I started vibe coding by writing prompts (often dictated into my phone), refining them with an agent in M365 Copilot, and creating handoff files to use with GitHub Copilot CLI. The results were predictably non-deterministic.

Prompt-driven development is a typical starting pattern: a developer opens a chat session, writes a prompt, reviews the output, adjusts, re-prompts. Maybe they get something useful. Maybe they spend an afternoon debugging emergent behavior that nobody specified and nobody tested. Then the process evolves to Spec-Driven Development: the developer creates specifications defining the “why and the “what.” They institute constraints and validation criteria, and the agent delivers more consistent code requiring less debugging.

But how do we scale this to teams of many humans and agents working in parallel? How do we persist development over large projects and codebases that exhaust most of the agent context window during initial grounding? How do we get better over time?

Several of my colleagues and I have started talking about a model we’re calling Agentic-Agile development as one methodology to address these problems.

Agentic-Agile Methodology: Wait! Hear me out!

I’m fortunate in my role at Microsoft as a Partner Tech Strategist (PTS) to work in a global team managing joint product and co-innovation with our leading Data & AI and partners. We come with a combination of engineering and product management backgrounds and spend most of our time focused on getting teams working better together across organizations. Adding agents to the development team, while ensuring continuous improvement, is proving a natural extension of our role.

The original Agile Manifesto taught us to value individuals and interactions, working software, customer collaboration, and responding to change. It was so successful that for some it became dysfunctional dogma (see The Death of Agile: Why Big Tech Is Ditching Scrum and What They Use Instead | by Ibrahim Irfan | Medium).

But Agile and Scrum were designed for maintaining team velocity while maintaining alignment in working toward rapidly shifting business goals. Today’s problems are similar but with agents, the time scale and the makeup of the team have changed. Our processes need to be flexible to evolve and maintain that alignment with agents as part of the team. That doesn’t mean we need to abandon processes.

This article is the introduction to a longer series detailing my and some colleagues’ practices that we hope will be helpful to others on the same path. I’ll often reference some of my personal projects, like Minthe which started as an attempt to build a chief of staff agent in Microsoft Foundry. Minthe has become my larger experiment in Agentic-Agile development and also has helped to bootstrap several other projects.

This isn’t a finished process, and we would really like your feedback and participation to continue to improve the framework.

• Read the full version of Toward an Agentic-Agile Manifesto
• Explore the Agentic-Agile Template | GitHub

Prompt-driven development works for small, self-contained tasks: Generate a function. Refactor a module. Write a test. These are bounded problems with clear outputs that modern AI coding agents handle well. Spec-Driven Development expands the scope of the tasks that can be delivered but it doesn’t scale over time without careful grooming and maintenance.

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. At that scale, prompt-driven development produces a set of familiar failures:

• No backlog: There is no structured list of what needs to be built, in what order, with what dependencies. Work gets discovered during implementation, not planned before it.
• No concept of done: Each prompt session ends when the developer feels satisfied, not when a contract is fulfilled. “Good enough” replaces “contract satisfied.”
• No phased delivery: Everything is attempted at once. There is no staged rollout, no incremental validation, no ability to pause and redirect.
• No governance: Safety constraints, validation rules, and quality gates are bolted on after the fact, if they are added at all.

# Copilot Instructions

> This file provides GitHub Copilot with project-specific context. 

## Project Description

<!-- Replace this with a 2-3 sentence description of your project. -->
<!-- Example: "A REST API for task management built with Node.js and Express. Uses PostgreSQL for storage and JWT for authentication." -->

[Describe your project here]

## Coding Style

<!-- Define the conventions Copilot should follow when generating code. -->

- **Language:** [e.g., TypeScript, Python, Go]
- **Formatting:** [e.g., Prettier with default config, Black for Python]
- **Naming:** [e.g., camelCase for variables, PascalCase for classes]
- **Imports:** [e.g., absolute imports only, group by stdlib/third-party/local]
- **Error handling:** [e.g., always use typed errors, never swallow exceptions]

## Testing Approach

<!-- Describe how tests should be written and organized. -->

- **Framework:** [e.g., Jest, pytest, Go testing]
- **Location:** [e.g., `__tests__/` directories alongside source, `tests/` at root]
- **Naming:** [e.g., `test_<function_name>`, `describe/it` blocks]
- **Coverage expectations:** [e.g., all public functions must have tests]

## Documentation Maintenance

<!--
  Define which documents exist, and when each should be updated.
  This prevents documentation from drifting out of sync with code.
-->

| Document | Update When |
|----------|-------------|
| `README.md` | Project scope, setup, or usage changes |
| `CLAUDE.md` | Process, conventions, or structure changes |
| `STYLE.md` | Style conventions change |
| `CONTRIBUTING.md` | Contribution process changes |
| API docs | Endpoints added, modified, or removed |
| [Your doc] | [Your trigger] |

## Development Process

<!--
  Describe how work flows from idea to merged code. Agents use this to
  understand your workflow expectations: how to structure PRs, when to
  run tests, what review looks like.

  The process below is an Agentic-Agile template. Adapt it to your team.
-->

### Workflow

```
Plan → Issue → Implement → Review → Merge → Docs
```

| Phase | Description |
|-------|-------------|
| **Plan** | Define what to build. Identify scope, dependencies, and file ownership. |
| **Issue** | Create a GitHub Issue with structured scope, acceptance criteria, and negative constraints. |
| **Implement** | Build the feature in a feature branch. Follow coding conventions. Write tests. |
| **Review** | Submit a PR. Every PR receives review that checks correctness, test coverage, and convention compliance. |
| **Merge** | Merge to the integration branch after review approval. |
| **Docs** | Update documentation affected by the change. Close the issue. |

Most teams treat AI agents as tools to be configured: pick a model, write a prompt, tune the parameters, receive product. Agentic-Agile treats agents as contributors to the team. Every action an agent takes is a development action, with the same downstream consequences as a human commit.

Agents create files, introduce dependencies, write tests. They can also enrich human prompts and specs and create issues in backlog. As you become more comfortable, give the agents the autonomy to research, make architectural decisions, and document these in ADR docs and updates to issues. However, if agents are doing development work, you need to agree with them on development process.

The same engineering discipline that prevents human teams from shipping broken software applies to human-agent teams: structured planning, clear acceptance criteria, incremental delivery, and review gates. A team that would never ship a human-authored module without code review should not ship agent-authored modules without equivalent scrutiny.

---
name: Agentic Story
about: A structured story for human-agent development
title: ''
labels: ''
assignees: ''
---

## Summary

<!-- What does this story deliver? One sentence describing the outcome. -->

## Context / Motivation

<!-- Why is this work needed? What problem does it solve or what capability does it enable? -->

## Scope

### Files to Create or Modify

<!-- Explicit list of files this story will touch. This prevents overlap with parallel stories. -->

- `path/to/file1.ext` — description of changes
- `path/to/file2.ext` — description of changes

### Interfaces to Implement

<!-- APIs, contracts, or integration points this story must satisfy. -->

- 

### Invariants to Preserve
ds
<!-- Existing behavior, contracts, or constraints that must NOT be broken. -->

- 

## Acceptance Criteria

<!-- Specific, testable conditions that must be true when this story is complete. -->

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Negative Constraints

<!-- What this story explicitly does NOT do. Prevents scope creep and clarifies boundaries. -->

- Does NOT modify ...
- Does NOT implement ...
- Does NOT change the behavior of ...

## Dependencies

<!-- Other issues or stories that must be completed before this one can start. -->

- Depends on #
- Blocked by #

## File Ownership

<!-- Explicit list of files this story owns exclusively during its wave. No other story in the same wave should touch these files. -->

| File | Owner (this story) | Notes |
|------|-------------------|-------|
| `path/to/file.ext` | ✅ | |

The underlying idea is not new. It is the foundational insight of Agile, applied to a new collaboration model. What Agile recognized for human teams, Agentic-Agile Development recognizes for human-agent partnerships: iteration, contracts, and reflection prevent the same class of failures.

With Minthe I authored specifications docs from prompts before any implementation code was written. After the first few iterations, we realized that design docs were being updated by agents and drifting from the original specs, but changing original spec docs led to more potential for drift. This introduced confusion for agents reading conflicting info, particularly in swarms.

The partnership evolved through recognizable stages: first, we designed and handed off. Then we alternated layers. Eventually, we ran multiple agents in parallel with review gates between waves.

After interrupting a few refactoring loops, we moved to using the GitHub repo issues to document new specs and features. Every capability became an issue with acceptance criteria. GitHub Copilot CLI (mostly with Claude models) easily adapted to reading and executing from issues as locked specifications during delivery. Mandating that all issue work be done in separate branches reduced collisions in parallelization. The closed issues and PR comments became historical reference points for subsequent iterations to refer to what had been done and what the intent was there, while capturing expanded requirements and specs in new issues. Parent-child, blocker relationships between issues further enhanced traceability.

What matters is how it changes the relationship between the human and the agent. This is a partnership, not a hierarchy. The human’s role is architecture and specification: a Scrum Coach who facilitates the collaboration rather than directing every action. The agent contributes implementation within constraints. Review is shared responsibility.

Shortly after this, we introduced a retrospective process where I asked an agent to review session files, git commit logs, PRs and other data to find where we could improve.

The methodology has since been applied to several, unrelated projects in different domain from the original chief of staff agent. The patterns (spec-first backlog, phased planning, agent context files) transferred without explicit reference to the original project. The methodology appears to be genuinely portable rather than project-specific. That portability is the real test: a methodology that only works on the project where it was invented is not a methodology.

A common objection: “We will add guardrails later, once we know what we are building.” In agentic development, this is backwards. Agents make decisions at execution speed. Without upfront constraints, they will make reasonable-looking choices that violate architectural invariants, introduce security gaps, or create dependencies that are expensive to unwind.

We learned this the hard way. Our CI pipeline was not Story 1. Quality issues accumulated across waves before any automated gate existed. By the time we added the pipeline, we had already built on assumptions that had never been validated. This required reopening and redeveloping the features. Along with CI gates, adding adversarial code reviews during each delivery wave and unit tests as part of acceptance criteria in each issue made a huge difference in work-product delivered.

Governance in Agentic-Agile Development is not a phase. It is a property of the backlog itself. Safety constraints are acceptance criteria on stories. Review gates sit between execution waves, not at the end of the project. Validation infrastructure, including CI/CD, linting, and automated tests, is the first story implemented, not the last.

The measurement is straightforward: if you are catching architectural violations during final review rather than during story execution, your governance is too late. Move it earlier.

We’re planning a deeper dive on this for the next installment in the series.

1. Copy the microsoft/agentic-agile-template repo on GitHub.
2. Clone your repo locally, switch to /plan mode, and ask GitHub Copilot to:
   1. read the contents of the repo for grounding and
   2. ask you clarifying questions to customize the template for your project.
3. If you don’t already have a backlog, create high-level issues for the major capabilities your product needs to deliver. Remember to create an issue describing what CI/CD tooling and gates are appropriate for your project (or ask Copilot for a suggestion)
4. Go back into /plan mode and ask the agent to work with to review the backlog and decide on which items to tackle first.
5. Pick that issue and ask Copilot to improve the description to conform to the ‘agentic-agile-template’.
6. When you feel comfortable with the issue description, ask Copilot to implement it and see what happens.
7. Keep working the process: every ambiguous capability becomes an issue. Every issue gets acceptance criteria. Every acceptance criterion becomes a contract that guides agent execution.

Comment here and let us know how it went.

• The Agentic-Agile Manifesto: Full manifesto with all thirteen principles
• Agentic-Agile Template | GitHub: Issue templates, agent context files, and starter backlog structure
• The original Agile Manifesto
• Andrej Karpathy: Software is changing (Again) | Y Combinator YouTube