community-ade/docs/FUTURE_PHASES.md

Community ADE — Future Phases

Synthesized from research docs, archived implementations, and design work. Each phase builds on the SDK-first unified platform.

---

Phase 2: Approval System + Governance

Source: _archive/approval-impl/, _archive/approval-system/, src/services/approval.ts, src/services/lock.ts, docs/design.md, docs/redis-schema.md

What exists (design + partial impl):

• 8-state approval lifecycle: DRAFT → SUBMITTED → REVIEWING → APPROVED → APPLYING → COMPLETED (or REJECTED/CANCELLED)
• Distributed locking with FIFO queues, TTL with heartbeat renewal, deadlock detection via wait-for graph
• Risk scoring: (criticality × 0.4) + (magnitude × 0.3) + (blast_radius × 0.2) + (failure_rate × 0.1)
• Auto-approve threshold for low-risk operations
• Quorum rules: score >= 75 requires 3 approvals, >= 50 requires 2, else 1
• Batch approval operations
• Redis key schema fully designed (ade:task:*, ade:approval:*, ade:lock:*)

What to build:

• Port approval.ts (1,080 lines) and lock.ts (748 lines) into mvp-unified/src/services/
• Add approval routes (POST /api/tasks/:id/submit, POST /api/approvals/:id/respond)
• Dashboard: approval queue panel, risk score visualization, lock monitor
• WebSocket push for approval state changes
• Human gate UI for tool calls needing sign-off

SDK integration: Task approval triggers createSession() + runTurn() on approved tasks via the existing worker pool.

---

Phase 3: Memory Curation

Source: _archive/memory-curator-kimi/design.md (most comprehensive), _archive/memory-curator-deepseek/, _archive/memory-curator-glm/, _archive/memory-curator-minimax/

Design highlights (from Kimi curator):

• 4-tier memory hierarchy:
  • EPHEMERAL — conversation-scoped, auto-expires
  • WORKING — task-relevant, medium persistence
  • DEEP — identity-defining, long-term
  • RESIDENT — permanent, never pruned
• Memory lifecycle state machine: BIRTH → promotion/pruning → DEATH/RESIDENT
• Compression strategies:
  • Narrative summarization (preserve emotional/contextual meaning)
  • Factual extraction (key-value pairs)
  • Semantic embedding (for similarity search)
• Token pressure triggers at 70-80% threshold
• Compression cascade: EPHEMERAL (50%) → WORKING (30%) → DEEP (20%) → Emergency
• Importance scoring: importance + log(accessCount) × 0.1 + exp(-daysSinceAccess/7) + connectivity × 0.05

Philosophy: "Memory is the substrate of consciousness. Curation is about stewarding agent identity, not just managing storage."

What to build:

• Memory curator service wrapping Letta's block system
• Token pressure monitoring per agent
• Compression strategies as pluggable modes (not hardcoded)
• Dashboard: memory health indicators, compression triggers, tier visualization
• Curation modes: aggressive (DeepSeek approach) vs. conservative (Kimi approach)

SDK integration: Memory operations via client.agents.blocks.*. Compression runs as background tasks through the worker pool.

---

Phase 4: Enhanced Orchestration

Source: docs/ade-phase1-orchestration-design.md, docs/parallel-tasks-orchestration.md, docs/ade-research.md (Intent analysis)

What to build:

• Coordinator/Specialist/Verifier pattern (inspired by Intent research)
  • Coordinator agent breaks down complex tasks
  • Specialist agents execute subtasks
  • Verifier agent validates outputs
• Git worktree isolation per task (each agent works in its own worktree)
• Spec tracking: planned vs. executed steps
• Task dependencies and DAG execution
• Priority queue with preemption support
• Stall detection improvements (currently 30s timeout)

SDK integration: Each subtask is a worker pool task, with createSession() per specialist agent.

---

Phase 5: Integration Ecosystem

Source: docs/ade-research.md (Warp/Intent feature comparison)

What to build:

• GitHub App — PR creation, issue tracking, code review triggers
• Slack notifications — task completion, approval requests, alerts
• Linear/Jira via MCP — bidirectional issue sync
• Webhook triggers — external events spawn agent tasks
• Tool marketplace — UI for discovering and attaching Letta tools

SDK integration: Integrations register as Letta tools via client.tools.create(), agents invoke them naturally.

---

Phase 6: Feature Flags + Gradual Rollout

Source: _archive/future-proofing/feature-flags.md

Design highlights:

• Redis-backed flags with gradual rollout (5% → 25% → 50% → 100%)
• A/B testing for curation strategies
• Kill switches for risky features
• Flag types: release, experiment, ops, permission

What to build:

• Feature flag service backed by Redis
• Dashboard: flag management UI, rollout controls
• Agent-level feature targeting

---

Phase 7: Computer Use

Source: docs/ade-research.md (Warp terminal capabilities)

What to build:

• Playwright browser automation as Letta tools
• Screenshot capture + visual verification
• Computer Use skill via SDK tools
• Session recording and replay

---

Phase 8: Team Collaboration

Source: _archive/future-proofing/architecture-roadmap.md

What to build:

• Multi-user access with authentication
• Shared agent pools
• Session sharing (like Warp)
• Audit trail (who changed what, when)
• Role-based permissions

---

Success Metrics (from execution plan)

Metric	Target
Task durability	100% — tasks never lost on restart
Throughput	10 tasks/min with 3 workers
Enqueue latency	< 100ms
Recovery time	< 60s from worker crash
Dashboard load	< 2s
Lock acquisition	< 10ms
Backward compat	Existing letta-code usage unchanged

---

Key Principle

One unified system. Models are interchangeable options, compared through the same interface. Memory curation strategies become modes, not products. Every feature flows through the SDK. The ADE is a window into Letta + an orchestration layer on top of it.