Usage & Flow

How DeepPlan MCP processes your plans, and real-world examples of what it produces.

The Three Flows

DeepPlan supports three orchestration flows. Each flow has AI+IDE as the planner at every stage boundary.

Flow 1: Baseline (AI Pure)

The simplest flow — a single LLM analyzes your plan directly.

User Draft → AI+IDE Plan

Use mode: "ai_pure" in the API call. Best for quick checks or simple plans.

Flow 2: Auto Council (Default)

Full expert council with AI+IDE refinement at every stage.

User Draft
    │
    ├─ 1. AI Search (Librarian)
    │     Knowledge base cache → Web search fallback
    │     → search context
    │
    ├─ 2. AI+IDE Enrichment
    │     Draft + search context → enriched draft
    │
    ├─ 3. Auto-select experts + chair
    │     AI picks best personas from your pool
    │
    ├─ 4. Expert Analysis (parallel)
    │     Each non-chair persona analyzes the enriched plan
    │     ┌─ 🔒 Security Expert
    │     ├─ ⚡ Performance Expert
    │     ├─ 🎨 UX/DX Expert
    │     └─ 🔧 DevOps Expert
    │
    ├─ 5. Chair Synthesis
    │     Chair reads ALL expert reports + original plan
    │     → produces unified blueprint
    │
    └─ 6. AI+IDE Refinement
          Blueprint → final actionable implementation plan

Use mode: "current" (default). Best for most use cases.

Flow 3: Paired Debate

Each expert is cloned into a Pro/Con pair for adversarial review.

User Draft
    │
    ├─ 1. AI Search → AI+IDE Enrichment (same as Flow 2)
    │
    ├─ 2. Auto Picker selects experts + chair
    │
    ├─ 3. PRO Phase (parallel)
    │     Each expert proposes improvements
    │
    ├─ 4. CON Phase (parallel)
    │     Same expert critiques their OWN pro report
    │     (adversarial self-review)
    │
    ├─ 5. Chair Synthesis
    │     Weighs PRO vs CON for balanced blueprint
    │
    └─ 6. AI+IDE Refinement
          Blueprint → final actionable implementation plan

Use mode: "debate". Best for high-stakes architecture decisions where you want stress-tested recommendations.

Key Details

• AI+IDE at every boundary — search context is enriched (not just concatenated), and the chair blueprint is refined into an actionable plan.
• Council selection uses draft_plan as the primary criteria. DeepPlan reads each deployed council’s persona names and roles to pick the best match.
• tech_stack and context_constraints are supplementary — they are passed to the expert personas during analysis but do NOT affect which council is selected.
• Only deployed councils are considered. Draft councils (gray dot on dashboard) are excluded from auto-selection.
• Chair persona = Synthesizer — the Chair uses its own system_prompt to synthesize expert reports. It is NOT called as an expert.
• Non-chair personas = Experts — all other personas analyze the plan in parallel.
• Paired Debate — in debate mode, each expert first proposes (PRO), then self-critiques (CON). This produces higher-quality recommendations by stress-testing every proposal.
• No code output — all personas focus on architecture strategy, direction, and patterns. They explain WHAT to do and WHY, never HOW in code.

Auto Persona Pick vs Auto Council Select

Usage in Your IDE

Basic Usage

Just describe what you want to build:

“I want to build a real-time chat app with SvelteKit and Cloudflare. Use DeepPlan MCP to review my architecture.”

With Tech Stack

Provide context for better recommendations:

“Use upgrade_architecture_blueprint with this plan: Build a multi-tenant SaaS dashboard. Tech stack: SvelteKit, Cloudflare Workers, D1, R2.”

With Constraints

Add constraints to prevent incompatible suggestions:

“Review this plan with DeepPlan: Implement payment processing with Stripe. Context constraints: Must run on Cloudflare Workers Edge Runtime, no Node.js-only APIs.”

Iterative Refinement

Use DeepPlan multiple times as your plan evolves:

“Take the blueprint from the last DeepPlan call and refine it. I’ve decided to use Durable Objects instead of KV for session storage. Run it through DeepPlan again.”

Example Results

Example 1: Real-time Chat System

Draft plan: “Build a real-time chat app for teams with multiple rooms, file sharing, and typing indicators.”

What the Council returns:

• Use 1 Durable Object per chat room for WebSocket state management
• Implement WebSocket Hibernation API to reduce idle DO costs by ~80%
• Store messages in D1 with composite index on (room_id, created_at)
• Upload files via R2 presigned URLs to bypass the 100MB Worker limit
• 6 executable next steps with specific file paths

Example 2: E-commerce Marketplace

Draft plan: “Build a multi-vendor marketplace where sellers list products and buyers can purchase with Stripe.”

What the Council catches that you missed:

• Stripe Connect Express accounts for vendor payouts
• Inventory race conditions during flash sales (solved with D1 transactions)
• R2 image optimization pipeline with size variants
• Webhook idempotency for out-of-order Stripe events

Example 3: IoT Dashboard

Draft plan: “Dashboard showing sensor data in real-time with alerting when values exceed thresholds.”

Council’s key insight:

• Dual-path data ingestion: Hot path (KV for latest readings) + Cold path (D1 for historical graphs, batched via Queues)
• Hysteresis alerting: Temperature must exceed threshold for 3 consecutive readings before alerting, preventing alert fatigue

Example 4: Multi-tenant SaaS with RBAC

Draft plan: “SaaS platform where organizations can invite members with different roles (admin, editor, viewer). Each org has isolated data.”

Council’s architecture directives:

• Tenant isolation via D1 row-level security — every table includes org_id with composite indexes, never rely on application-layer filtering alone
• RBAC middleware pattern — create a requireRole('admin') middleware that checks JWT claims before route handlers, not inside them
• Invitation flow with expiry — use KV with TTL for invite tokens instead of D1 to avoid cleanup cron jobs

Example 5: API Gateway with Rate Limiting

Draft plan: “API gateway that rate-limits by API key, logs usage, and proxies to multiple upstream services.”

Council’s edge cases found:

• Clock skew across edge locations — use sliding window counter in Durable Objects instead of fixed windows in KV
• Upstream timeout cascading — implement circuit breaker pattern with 3-state (closed/open/half-open) per upstream
• Log ingestion backpressure — batch logs via Queues with max batch size of 100, not individual writes to D1

Customizing Your Councils

Building a Custom Council

1. Create personas — go to Dashboard → Personas and create experts for your domain
2. Set system prompts — each persona needs a detailed system_prompt describing their role, expertise, review style, and focus areas
3. Create a council — go to Dashboard → Councils, name it, add your personas
4. Set a Chair — choose one persona as Chair (synthesizer). This persona will NOT analyze — it only synthesizes
5. Deploy — toggle the council to “deployed” (green dot). Only deployed councils are available for MCP

Tips for Persona Design

• Be specific about expertise — “Senior Security Engineer specializing in OAuth 2.0 and API authentication” is better than “Security Expert”
• Define review style — “Always start with the most critical finding. Use severity labels. Reference specific components from the plan.”
• Add anti-patterns — “Never suggest solutions incompatible with the stated runtime. Never give vague advice like ‘consider security’.”
• Keep focused — each persona should have a clear, non-overlapping domain

Tips for Chair Design

• Synthesis, not repetition — instruct the Chair to resolve conflicts between experts, not concatenate their reports
• Structured output — require specific sections (Architecture Directives, Edge Cases, Next Steps)
• Write for AI agents — the output goes to an IDE AI agent, so instruct the Chair to write numbered, executable steps

Credit Cost

Each MCP call costs 1 credit, regardless of:

• How many personas are in the council (3, 5, or 10)
• How long the draft plan is
• Which AI engines are used

Credits never expire. See Pricing for volume discounts.

Tips for Best Results

1. Be specific — “real-time chat with rooms and file sharing” is better than “an app”
2. Always include tech_stack — enables stack-specific recommendations
3. Add constraints — “must run on Edge Runtime” prevents bad suggestions
4. Keep plans under 500 words — the Council works best with focused plans
5. Deploy your councils — only deployed councils (green dot) are available for MCP
6. Iterate — run your plan through DeepPlan multiple times as it evolves
7. Domain-specific councils — create specialized councils for your project types (e.g. “E-commerce Council”, “IoT Council”)