Workflow
The day-to-day process for AI-assisted delivery.
Default 1-Week POC Rhythm
The standard cadence for delivering a validated proof of concept. This rhythm can be compressed or extended, but the sequence remains the same.
Workshop
- • Capture context, requirements, and constraints
- • Identify key stakeholders and decision makers
- • Define success criteria for the POC
- • Agree on scope boundaries
Stress Test + Artefacts
- • Project Agent stress tests requirements
- • Challenge assumptions and identify gaps
- • Produce Vision document
- • Produce Architecture document
- • Produce Requirements (Phase 1)
- • Create initial State of Play
Build POC
- • Coding Agent proposes phase plan
- • Build against agreed scope with Stack A
- • Daily check-ins on progress
- • Update State of Play as decisions are made
Client Review + Steering
- • Live review session with stakeholders
- • Demonstrate working proof
- • Capture feedback and decisions
- • Adjust scope for next phase if needed
User Feedback (Optional)
- • Test with representative users
- • Gather feedback on core assumptions
- • Validate UX decisions
- • Document findings in State of Play
Promote via Gates
- • Pass Intent Gate (if not already done)
- • Pass Build Gate at phase boundaries
- • Pass Release Gate before production
- • Progress through stages: POC → MVP → MMP → PROD
Meeting Cadence
Workshop
When: Start of project
Duration: 2-3 hours
Who: Project Lead, Client stakeholders, Project Agent
Capture context and requirements. Define scope.
Client Review
When: End of each phase
Duration: 1-2 hours
Who: Project Lead, Client stakeholders, Demo of work
Review progress. Make decisions. Steer next phase.
Daily Check-in
When: During build
Duration: 15 min
Who: Project Lead, Coding Agent/Dev
Progress update. Blockers. Quick decisions.
Follow-up Workshop
When: As needed
Duration: 1-2 hours
Who: Project Lead, Client, Project Agent
Address scope changes. Clarify requirements.
When to Run a Follow-up Workshop
Not every change needs a workshop. Use this guide:
Workshop NOT Needed
- • Minor scope adjustments within phase
- • UI/UX refinements
- • Bug fixes or polish
- • Technical implementation decisions
Workshop Needed
- • Major scope change
- • New stakeholders with different priorities
- • Pivot in product direction
- • Significant assumption proven wrong
How to Run Live Steering
The client review is not just a demo—it's a decision-making session. Here's how to run it effectively:
- Set expectations upfront: "We'll show progress, then make decisions together about next steps."
- Demo working software: Show the actual product, not slides. Let stakeholders interact if possible.
- Capture feedback live: Have State of Play open. Add decisions as they're made.
- Force decisions: "Given what you've seen, should we proceed, adjust scope, or pause?"
- Summarise before ending: Read back decisions. Confirm next actions. Share updated State of Play.
Capturing Decisions
Every decision should be captured durably. Use the State of Play document as the single source of truth.
Decision Entry Template
## Decision: [Brief title] - **Date:** YYYY-MM-DD - **Context:** Why this decision was needed - **Decision:** What was decided - **Rationale:** Why this option was chosen - **Impact:** What changes as a result - **Owner:** Who is responsible for action
See Helpers & Templates for the complete State of Play template.
Roles in Workflow
See Operating Model for detailed role definitions.
Key Principle
Different AIs should own different responsibilities. A single agent trying to handle context, scope, code, and sequencing produces inconsistent results. Separate Project Agent and Coding Agent roles.
Next Steps
See Helpers & Templates for prompts and templates, and Standards for coding conventions.