OUTCOME MAP: AGENT PLATFORM
════════════════════════════════════════════════════════════

  DESIRED OUTCOME
  Every agent instance (Sales Dev, Content Amplifier, future)
  inherits identity, memory, comms, dispatch, and quality from
  one platform — so engineering builds domain knowledge, not
  infrastructure, and the system audits itself.
       │
       ├── Contributing Factors
       │   ├── Convex schema + functions deployed (8 queries, 3 mutations)
       │   ├── Agent comms CLI proven (5 channels, 8 message types)
       │   ├── Plan CLI DB-native (32 commands, 2842 lines)
       │   ├── Agent ETL CLI working (3 agents loaded to prod)
       │   ├── 23 plan templates active across 5 worktree teams
       │   ├── 4 WorkChart orchestrators built (Sequential, Concurrent, Adaptive, Group-Chat)
       │   ├── Cognitive architecture defined (4 memory types, 8 JSON files per agent)
       │   └── First instance (Sales Dev Agent) in active development — proves the pattern
       │
       ├── Obstacles
       │   ├── 5 separate PRDs described one system → Spec confusion for engineering
       │   │   Mitigation: Consolidate into one platform PRD, 5 concerns as sections
       │   ├── 3 CLIs, no coordination → Agents use different entry points
       │   │   Mitigation: drmg thin router wraps all three, old paths become aliases
       │   ├── Memory schema exists but no writers → Knowledge doesn't compound
       │   │   Mitigation: Session extract (Phase 1) writes to existing tables
       │   ├── VVFL enforcement artifacts (5 generators, 23 templates, 17 rules) unmeasured
       │   │   Mitigation: Graph seeder + 8 auditors measure first, then improve
       │   └── Blocked by Identity PRD (prd-identity-access) → Auth is unresolved
       │       Mitigation: --path flag on ETL CLI (0.5 day) unblocks agent loading
       │
       ├── Investigations (answer before committing)
       │   ├── Are agents with memory measurably faster than without?
       │   │   [Owner: Eng, Phase 1. Kill signal if not.]
       │   ├── Does session recovery time improve with message loading?
       │   │   [Owner: Eng, Phase 3. 30-day measurement window.]
       │   ├── Can VVFL auditors produce actionable patterns after 3 runs?
       │   │   [Owner: Eng, Phase 4. Kill signal if zero patterns → improvements after 5 runs.]
       │   └── Does the unified CLI reduce friction vs 3 separate CLIs?
       │       [Owner: Eng, Phase 2. Time-to-first-query comparison.]
       │
       ├── Success Measures (binary)
       │   ├── O1: Session recovery time reduced ≥80% → YES / NO
       │   ├── O2: Duplicate work across teams reduced ≥80% → YES / NO
       │   ├── O3: Spec-to-ship cycle time improved 2x → YES / NO
       │   ├── O4: ≥50% of critical VVFL findings resolved → YES / NO
       │   ├── F1: Agent productive in <30s after session start → YES / NO
       │   ├── F2: Block signal reaches orchestrator in <2min → YES / NO
       │   └── F6: All CLI commands work through `drmg` → YES / NO
       │
       ├── Roles (RACI)
       │   ├── Accountable: Wik (platform architecture, graduation decisions)
       │   ├── Responsible: Engineering agents (build, test, report via drmg CLI)
       │   ├── Consulted: Dream team / Nav (commissioning, priority order)
       │   └── Informed: Future agent instances (inherit platform capabilities)
       │
       └── Next Actions (momentum within 48 hours)
           ├── Add --path flag to agent-etl-cli (Phase 0, 0.5 day)
           ├── Extract shared DB context from plan-cli (Phase 1, first task)
           └── Seed context graph from filesystem (Phase 1, second task)

════════════════════════════════════════════════════════════