Ready to get started?
Install Paivot and see the methodology in action with AI agents.
How we adapted the Pivotal methodology for AI-driven software development. The core philosophy remains intact; the execution model changes significantly.
The Pivotal methodology was designed for human teams. Humans have persistent memory, build relationships, learn implicitly, and communicate through conversation. AI agents have none of these. They are ephemeral, stateless, and can only operate on explicit context.
Paivot preserves what made Pivotal work while adapting the mechanics for AI execution.
D&F remains the foundation. The documents serve an even more critical purpose in Paivot: they provide the context that AI agents cannot accumulate through experience.
The BLT concept survives, but the "team" is now a set of specialized AI agents: Business Analyst, Designer, and Architect. Each owns their domain and produces artifacts that inform the backlog.
TDD remains non-negotiable. The testing philosophy is actually stricter in Paivot because AI agents can't exercise judgment about "good enough" coverage.
INVEST was always good practice. In Paivot it becomes structurally critical because Independence enables parallelism, allowing the orchestrator to dispatch multiple Developer agents simultaneously.
We still build thin end-to-end slices before adding complexity. Horizontal layers in isolation remain an anti-pattern. Milestones must be demoable with real execution.
The retro process continues, extracting learnings from completed work and feeding them back into future stories. The mechanism changes, but the intent is identical.
Original
A team of humans works together over weeks or months, building shared context and institutional knowledge.
Paivot
Each agent is spawned for a single task, completes it, and is disposed. No agent carries context between invocations.
Why
AI agents have limited context windows and no persistent memory. Attempting to maintain a "long-running team" creates context overflow and hallucination. Ephemeral agents with explicit context are more reliable.
Original
Developers pair on all production code, sharing knowledge and catching errors in real-time.
Paivot
A central orchestrator dispatches work to individual Developer agents. Each agent works alone on a single story.
Why
AI agents cannot meaningfully pair. There is no second perspective to offer, no knowledge transfer happening. Instead, the orchestrator pattern provides coordination, and the PM-Acceptor role provides review.
Original
Stories reference shared understanding. "Add logout button" assumes the team knows where buttons go, what the auth system looks like, and what happens on logout.
Paivot
Every story must embed ALL context needed for implementation. The Developer agent has access to nothing beyond what is written in the story and the codebase.
Why
Ephemeral agents cannot ask clarifying questions mid-implementation or remember yesterday's discussion. If context is not in the story, it does not exist.
Original
PM trusts developers based on relationship and track record. Review is often a conversation.
Paivot
Developers must record explicit proof of passing tests in delivery notes. PM-Acceptor reviews evidence rather than re-running tests.
Why
AI agents have no reputation to protect and no relationship to maintain. Evidence-based review ensures accountability without requiring the PM to duplicate work.
Original
Pivotal Tracker was the central nervous system. All stories, blockers, dependencies, velocity, and project history lived there.
Paivot
A git-backed issue tracker replaces Pivotal Tracker as the single source of truth. Story status, rejection history, blockers, dependencies, and learnings are tracked with CLI-first access and JSON output for agent parsing.
Why
Pivotal Tracker was designed for human interaction patterns. AI agents need CLI-first access, machine-parseable output, and git integration for persistence across sessions.
Original
Teams learn implicitly through pairing, retrospectives, and hallway conversations. Knowledge spreads organically.
Paivot
Developers record LEARNINGS in delivery notes. PM labels stories with learnings. Retro agent extracts and categorizes insights. Sr. PM reviews learnings before creating new stories.
Why
AI agents cannot learn implicitly. Knowledge must be captured explicitly, stored persistently, and injected into future context deliberately.
Original
CI runs the full test suite on every change.
Paivot
Test scope is narrow by default. Only tests affected by the story run. Full suite runs only for milestone validation, explicit labels, or shared infrastructure changes.
Why
AI agents can generate many changes quickly. Running the full test suite on every story creates bottlenecks. Narrow scope maintains velocity while milestone gates ensure system integrity.
Original
Team members flex between roles when needed. A developer might help with design; a PM might write a test.
Paivot
Agents have strict role boundaries. A Developer agent cannot close stories. A PM agent cannot write code. The orchestrator cannot implement features.
Why
Role flexibility requires judgment about when to flex. AI agents lack this judgment. Strict boundaries prevent agents from wandering into areas where they will make mistakes.
Original
Team norms are cultural. People follow practices because they understand why and hold each other accountable through relationships and shared values.
Paivot
Rules are enforced structurally by the pvg Go binary at the hook level. A scope guard blocks unauthorized writes. A dispatcher guard prevents the orchestrator from bypassing BLT agents. These sit outside the LLM and cannot be circumvented by prompt manipulation or context compaction.
Why
LLMs can be "convinced" to deviate from instructions and lose rules after context compaction. Advisory instructions do not work for subagents. Structural enforcement (code that runs before every tool call) is the only reliable mechanism.
Original
Teams review each other's work through pairing, design critiques, and collaborative sessions. Feedback is constructive and relationship-based.
Paivot
Three dedicated Challenger agents (BA Challenger, Designer Challenger, Architect Challenger) adversarially review each D&F document. Each returns a binary APPROVED or REJECTED verdict with specific issues. Creators revise and resubmit until approved or the user intervenes after max iterations.
Why
AI agents producing documents tend toward consensus and completeness theater. An adversarial reviewer with a single job (find what's wrong) catches omissions, hallucinations, and contradictions that the creator agent is structurally unlikely to notice in its own output.
Original
Each discipline has an anchor who represents the practice and monitors team health persistently throughout the project.
Paivot
The orchestrator (main Claude) coordinates all work. The Anchor agent is spawned to adversarially review backlogs, preserving the "ask hard questions" function but as an ephemeral review step rather than persistent presence.
Why
Persistent anchoring requires relationship-building over time. Paivot splits the anchor function: the orchestrator provides coordination, while the Anchor agent provides the adversarial review that ensures quality before execution begins.
The main Claude instance dispatches all work but never writes code itself. This separation ensures implementation happens in focused, ephemeral contexts while coordination happens in a persistent context. Enforced structurally by the pvg hook system, not just by prompt instructions.
In original Pivotal, anchors monitored team dynamics. In Paivot, the Anchor agent adversarially reviews the backlog before execution, looking for gaps: missing walking skeletons, horizontal layers, non-demoable milestones. It also validates milestone completion: real delivery, no mocks, and vault skills consulted.
Three dedicated Challenger agents (BA Challenger, Designer Challenger, and Architect Challenger) adversarially review each Discovery & Framing document. They check for omissions, hallucinations, and contradictions against upstream documents. Each returns a binary APPROVED or REJECTED verdict. Up to 3 revision rounds before escalating to the user.
Advisory instructions do not work for subagents. The pvg Go binary sits outside the LLM and enforces rules at the hook level via PreToolUse interception. It cannot be circumvented by prompt manipulation or context compaction. A scope guard blocks direct writes to protected vault directories, and a dispatcher guard prevents the orchestrator from writing D&F files itself.
An Obsidian vault serves as the knowledge layer that agents read from and write to at runtime. Decisions, patterns, debugging insights, and methodology notes survive across sessions and compound over time. SHA-256 checksums protect vault integrity. All writes go through the vlt CLI, and direct file edits are blocked.
Developers do not simply mark stories complete. They record proof: CI results, coverage metrics, test output, commit SHA. The PM reviews evidence rather than re-running tests. Every rejection must include four parts: Expected (quote the AC), Delivered (what code does), Gap (where it falls short), and Fix (actionable guidance).
Opt-in per story via the hard-tdd label. Splits development into two structural phases: RED (write tests only, no implementation) and GREEN (write implementation only, test files locked by git). Git diff verifies test immutability between phases. The PM-Acceptor adjusts its review criteria based on the current phase.
BLT agents follow a structural execution sequence: their first output must be QUESTIONS_FOR_USER, never a document. The orchestrator relays questions to the user, then resumes the agent with answers. This ensures requirements are clarified before any document is produced. Light D&F means fewer rounds, not zero rounds.
After all three D&F documents exist, every BLT agent cross-reviews the other two for consistency. Contradictions between business requirements, user needs, and technical approach are surfaced before the backlog is created. The system must reach BLT_ALIGNED status before the Sr. PM begins story creation.
Milestones are natural checkpoints for user feedback. When a milestone completes: human-readable summary, async feedback assessment by Sr. PM, and course correction incorporated into upcoming stories.
The Sr. PM creates all epics upfront but only decomposes stories for the current milestone. After each milestone completes, the next gets decomposed with the benefit of real implementation experience.
When the PM discovers a bug that should have been caught by tests, they record a LEARNING explaining why tests missed it. Original Pivotal teams learned this implicitly. Paivot makes it explicit and injects it into future context.
A Structurizr DSL file lives alongside ARCHITECTURE.md as a machine-checkable twin. Defines containers, components, and their allowed dependencies. The Anchor agent validates that code respects declared boundaries. Generated diagrams keep documentation in sync with reality.
Optional state machine on issue status transitions. pvg guard validates that every status change follows the allowed graph. You cannot skip from open directly to closed without passing through in-progress and delivered. Invalid transitions are blocked.
All work happens on short-lived story/<ID> branches off main. No long-lived feature branches. Developer agents create branches, implement, and the orchestrator manages merges back to main after acceptance. Protected-main handoff pauses the loop when human review is needed.
The /intake command converts raw user feedback into a prioritized backlog through five phases: collect feedback, search vault for context, detect project stack, delegate to Sr. PM for story creation, and triage into the backlog.
Stack-aware defaults prevent resource exhaustion. Heavy stacks (Rust, iOS, C#, CloudFlare Workers): max 2 developer agents + 1 PM = 3 total. Light stacks (Python, TypeScript): max 4 developer + 2 PM = 6 total. Auto-detected from project files, user-overridable.
The /piv-loop command runs the full delivery pipeline autonomously. Priority order: accept delivered stories first, fix rejected stories second, implement ready stories third. Runs until blocked or protected-main handoff.
Paivot is not a rejection of the Pivotal methodology. It is a translation for a world where the builders are AI agents rather than human teams.