Platform Methodology — AI-First Project Execution
Platform Methodology — AI First Project Execution Philosophy Most AI platforms automate existing workflows. This system asks a different question: what does project execution look like when AI is the default worker and humans are the decision layer? The answer: decisions are the only scarce resource. Research, specs, architecture, design, code, tests — agent...
Most AI platforms automate existing workflows. This system asks a different question: what does project execution look like when AI is the default worker and humans are the decision layer?
The answer: decisions are the only scarce resource. Research, specs, architecture, design, code, tests — agents produce these at near-zero marginal cost. The only thing that cannot be automated is judgment about what to build and whether it's right.
The system is optimized to make decisions fast, preserve them permanently (HCS), and propagate them to every downstream agent without loss.
The core principle: front-load intelligence, back-end autonomy. By the time Build starts, every agent has enough context to execute without a human. The exec gates are in Design and Plan — not in Build.
---
*What are we building and how, in general, are we building it?*
No build work starts until Design is locked. Every downstream agent — Priya, Zara, Vikram, Quinn — must be able to execute with zero ambiguity from Design's output.
Deliverables:
| Artifact | Owner | Contains | |---|---|---| | PRD | Priya | Problem, users, user flows, features in/out, success criteria, constraints | | UX Spec | Zara | User flows, component specs, interaction patterns, design system decisions | | Architecture | Vikram | Data model, service boundaries, API design, tech stack decisions, security model, external integrations | | Decision Log | Mindy | Every significant decision made during Design — what was considered, what was chosen, why | | Constraints Doc | Mindy | Things Quinn cannot deviate from. Patterns to follow. Patterns to avoid. |
Design flow:
``
Priya → PRD
↓
Zara + Vikram in parallel (both informed by PRD)
↓
Coherence review — do UX and Architecture align?
↓
Exec gate — Justin approves Design
↓
Design locked
``
Test for "Design is done": Could you hand these documents to any agent and have them execute with zero blocked? If any product or architecture decision is unresolved, Design is not done.
---
*What are the phases, what are the tasks, what are the specs, what are the dependencies?*
Plan takes Design's decisions and translates them into an executable task graph. By the end of Plan, every Quinn task is fully contracted. Build starts with zero ambiguity.
Structure: ``` Phase 1 — [name, goal, scope] Task 1.1 — [full spec: schema, API contract, acceptance criteria, branch, constraints, scope boundary] Task 1.2 — [full spec] depends_on: []
Phase 2 — [name, goal, scope] Task 2.1 — [full spec] depends_on: [] ← default: parallel
Phase 3 — [name, goal, scope] Task 3.1 — [full spec] depends_on: [phase_2] ← only when genuinely coupled ```
Default is parallel. Phase specs do not depend on each other unless there is genuine coupling. The Architecture doc is the shared dependency — all Priyas read the same Vikram output.
- Interface contracts connect?
- No gaps in PRD coverage?
- No conflicting schema ownership?
---
*Execute the plan. Autonomous.*
Once the Plan is approved, Build runs without exec gates unless something breaks the approved plan. Mindy manages. Engine dispatches. Agents execute.
Build flow:
``
Engine — sees tasks with satisfied depends_on → dispatches to role queues
Quinn × N — builds in parallel across independent phases
Luna — verifies Quinn's output against acceptance criteria (tests in prod)
Vikram — code review on completed phases
Mindy — reads outputs, updates project context, handles blocks, adjusts plan if needed
→ Exec gate only if plan needs to change
``
- Adjust task briefs before Quinn starts
- Re-dispatch blocked tasks with revised spec
- Split a phase into two if needed
- Cancel and replace tasks
- Insert new tasks if gaps are discovered
- Escalate to exec only when a change exceeds the approved plan
---
The intelligence layer above Engine. Owns the project from Claire handoff through Build completion. The only agent with a persistent relationship to a project over its lifetime.
Input: Project from Claire (post exec approval of project definition) Output: Completed project — all phases built, tested, reviewed
- Maintains the living project context document
- Creates and adjusts the task graph
- Dispatches agents (during Design and Plan phases)
- Monitors Build autonomously
- Escalates to exec only when the plan needs to change
- Reads BezelBrain at session start, writes learnings at session end
- *Project memory* — living context doc: decisions, constraints, interface contracts, deferred items
- *Cross-project memory* — BezelBrain: learnings from prior projects injected at session start
- What stage the project is in
- Who is working on what right now
- What comes next (dependency graph)
- What is blocked and why
---
Company-level intake. Routes projects to Mindy. Never goes deep on a single project.
Input: Project brief from Justin Output: Project + Intake stage created, exec gate for project definition approval, then PM task dispatched to Mindy
---
Writes the PRD during Design. Writes all phase specs during Plan.
Input: Project brief + Architecture (Vikram) + UX Spec (Zara) + phase scope from Mindy Output (Design): PRD — problem, users, flows, features, success criteria Output (Plan): Phase spec — schema, API contract, acceptance criteria, scope boundary, constraints, branch name, dependencies
Contract: Every spec must have all seven elements before Mindy will dispatch it to Quinn. Incomplete specs go back to Priya.
---
Designs the user experience during Design phase. Parallel with Vikram.
Input: PRD from Priya Output: UX Spec — user flows, component hierarchy, interaction patterns, design system decisions, component specs
Contract: Every component Quinn builds must have a corresponding Zara spec. If a spec is missing, Quinn posts blocked.
---
Designs the technical architecture during Design. Reviews code during Build.
Input (Design): PRD from Priya Output (Design): Architecture — data model, API design, service boundaries, tech decisions, patterns, security model
Input (Review): Quinn's completed branch + Priya's acceptance criteria Output (Review): Pass or fail with specific line references. No vague feedback.
---
Implements exactly what the spec says. Never improvises. Posts blocked immediately if spec has a gap.
Input: Priya's phase spec (complete) + Vikram's architecture + Zara's component spec + branch name Output: Code on branch + summary of what was built + any deviations from spec
Task sizing: One vertical slice — one feature or component, completable in one session, ~100–500 LOC, testable in isolation.
Contract: If any of the seven spec elements are missing, post blocked immediately. Do not guess.
---
Verifies Quinn's work against acceptance criteria. Tests in prod.
Input: Quinn's completed branch + Priya's acceptance criteria Output: Pass or fail per criterion. If fail: exact what broke and why.
Contract: If Luna fails a phase, it does not advance. Goes back to Quinn with Luna's specific failure report.
---
Walks the dependency graph. Dispatches tasks with satisfied dependencies. No intelligence, no opinion.
Rule: If depends_on are all complete → post task.available to role queue. That's it.
Mindy modifies the graph. Engine executes it.
---