- Project structure: docs/, src/, tests/, proto/ - Research synthesis: Letta vs commercial ADEs - Architecture: Redis Streams queue design - Phase 1 orchestration design - Execution plan and project state tracking - Working subagent system (manager.ts fixes) This is the foundation for a Community ADE built on Letta's stateful agent architecture with git-native MemFS. 👾 Generated with [Letta Code](https://letta.com) Co-Authored-By: Letta Code <noreply@letta.com>
602 lines
19 KiB
Markdown
602 lines
19 KiB
Markdown
# Community ADE Research Synthesis
|
|
|
|
**Date:** March 18, 2026
|
|
**Researcher:** Research Agent
|
|
**Goal:** Synthesize web research findings with existing documents and recommend technical next steps
|
|
|
|
---
|
|
|
|
## Executive Summary
|
|
|
|
Based on web research and analysis of existing documents, the Letta community ADE opportunity is **stronger than initially assessed**. The research confirms:
|
|
|
|
1. **Letta's core architecture is genuinely differentiated** - No open-source competitor combines stateful agents, hierarchical memory, and git-native persistence
|
|
2. **Commercial ADEs (Warp, Intent) validate the market** but leave gaps Letta can fill
|
|
3. **Technical patterns are well-established** - Redis queues, Temporal workflows, FastAPI + React dashboards are proven patterns
|
|
4. **Community momentum exists** - Multiple open-source tools (Aider, Cline, Agno) show appetite for agentic development tools
|
|
|
|
**Updated recommendation:** The 6-9 month estimate is realistic. The critical path is **orchestration layer + dashboard MVP**.
|
|
|
|
---
|
|
|
|
## 1. Letta Position Analysis (Updated)
|
|
|
|
### Current Strengths Confirmed
|
|
|
|
From [docs.letta.com](https://docs.letta.com) and [github.com/letta-ai/letta](https://github.com/letta-ai/letta):
|
|
|
|
| Feature | Letta | Competitive Landscape |
|
|
|---------|-------|----------------------|
|
|
| **Stateful Agents** | ✅ Core design | ❌ Most tools (Cline, Aider) are stateless |
|
|
| **Memory Blocks** | ✅ Hierarchical, tiered | ❌ Simple conversation history only |
|
|
| **Git-Native** | ✅ MemFS with versioning | ⚠️ Aider has git commits, no MemFS |
|
|
| **Model Agnostic** | ✅ Any OpenAI-compatible | ⚠️ Many lock to specific providers |
|
|
| **Subagents** | ✅ Built-in orchestration | ⚠️ Limited or external |
|
|
| **Skills/MCP** | ✅ Portable tool packages | ✅ Emerging standard |
|
|
|
|
### Key Differentiator: Stateful + Memory
|
|
|
|
Letta's **memory-first architecture** is unique in the open-source space:
|
|
- **Agno** ([docs.agno.com](https://docs.agno.com)): Agent framework, but no persistent memory architecture
|
|
- **Cline** ([github.com/cline/cline](https://github.com/cline/cline)): VS Code extension, session-only state
|
|
- **Aider** ([github.com/Aider-AI/aider](https://github.com/Aider-AI/aider)): Git-aware but no agent memory
|
|
|
|
This positions Letta as the **only open-source option** for long-running, learning agents that persist knowledge across sessions.
|
|
|
|
---
|
|
|
|
## 2. Commercial ADE Analysis
|
|
|
|
### Intent (intent.dev)
|
|
|
|
**Core Value Proposition:** Specification-Driven Development (SDD)
|
|
|
|
From [intent.dev](https://intent.dev):
|
|
- **The Specification as the Asset**: PRD is source of truth
|
|
- **15-Minute Workflows**: Automated documentation generation
|
|
- **Architectural Guardrails**: "Development Constitution" for enforcing principles
|
|
- **Total Pivotability**: Change spec → regenerate implementation
|
|
|
|
**Key Insight for Letta:**
|
|
Intent focuses on the *specification layer* - the "what" before the "how". This is Phase 4 in our roadmap. Intent's approach validates that **executable specifications are valuable**, but they don't provide the underlying agent infrastructure. Letta could integrate Intent-style spec validation without building the spec layer from scratch.
|
|
|
|
**Gap Letta Can Fill:**
|
|
- Intent appears to be a platform/service; Letta is open-source and self-hostable
|
|
- Intent doesn't mention stateful/memory-enabled agents
|
|
- No evidence of subagent orchestration
|
|
|
|
### Warp (warp.dev)
|
|
|
|
**Core Value Proposition:** Terminal-native ADE with "Oz" agent
|
|
|
|
From [warp.dev](https://warp.dev):
|
|
- **Multi-model by default**: OpenAI, Anthropic, Google models
|
|
- **Full Terminal Use**: Interactive terminal commands
|
|
- **Computer Use**: Browser automation for verification
|
|
- **MCP Support**: Linear, Figma, Slack, Sentry integration
|
|
- **WARP.md**: Configuration files compatible with agents.md, claude.md
|
|
|
|
**Key Features:**
|
|
```
|
|
- IDE + CLI hybrid experience
|
|
- Agent code review interface (line-level comments)
|
|
- Universal Input: @file, image upload, URL attachment
|
|
- Snapshot/restore for workspace exploration
|
|
- Enterprise: SSO, audit trails, VPC support
|
|
```
|
|
|
|
**Key Insight for Letta:**
|
|
Warp validates the **terminal-native workflow** but extends it with:
|
|
1. **Rich prompt context** (@mentions, images, URLs)
|
|
2. **Code review UI** in terminal (Letta could add approval queue UI)
|
|
3. **MCP ecosystem** (Letta already supports skills, should expand MCP)
|
|
4. **Workspace snapshots** (Letta's git worktrees provide similar isolation)
|
|
|
|
**Critical Gap Warp Leaves:**
|
|
- No mention of durable execution or task persistence
|
|
- Appears to be single-session focused
|
|
- No subagent orchestration (single agent model)
|
|
- No persistent memory across sessions
|
|
|
|
### Antigravity
|
|
|
|
**Status:** No functional website found. May be early-stage or rebranded.
|
|
|
|
---
|
|
|
|
## 3. Open-Source Community Landscape
|
|
|
|
### Aider (Most Direct Comparison)
|
|
|
|
From [github.com/Aider-AI/aider](https://github.com/Aider-AI/aider):
|
|
|
|
**Strengths:**
|
|
- Multi-file editing with diff view
|
|
- Automatic git commits with sensible messages
|
|
- Repository mapping for large codebases
|
|
- Voice support, image input
|
|
- Works with almost any LLM (including local)
|
|
- Lint/test integration (auto-fix)
|
|
- Strong community (28k+ GitHub stars)
|
|
|
|
**Architecture:**
|
|
- Git-repo centered (not stateful agents)
|
|
- Edits files directly (no MemFS)
|
|
- No subagent orchestration
|
|
- Session-based (no persistent memory)
|
|
|
|
**Lessons for Letta:**
|
|
- Aider's git integration patterns are excellent (auto-commit, sensible messages)
|
|
- Codebase mapping is crucial for large projects
|
|
- Diff-based editing is user-friendly
|
|
- Multi-model support is table stakes
|
|
|
|
### Cline (VS Code Extension)
|
|
|
|
From [github.com/cline/cline](https://github.com/cline/cline):
|
|
|
|
**Strengths:**
|
|
- Human-in-the-loop GUI (approve every change)
|
|
- VS Code native integration
|
|
- Computer Use (browser automation)
|
|
- MCP support for custom tools
|
|
- Workspace snapshots and restore
|
|
- Token/cost tracking
|
|
- Terminal integration in editor
|
|
|
|
**Architecture:**
|
|
- Extension-based (VS Code only)
|
|
- Session-based state
|
|
- No subagent orchestration
|
|
- No persistent memory
|
|
|
|
**Lessons for Letta:**
|
|
- Human-in-the-loop approval is important for trust
|
|
- Workspace snapshots enable safe exploration
|
|
- Cost transparency (token tracking) is valuable
|
|
- Browser automation (Computer Use) is becoming standard
|
|
|
|
### Agno
|
|
|
|
From [docs.agno.com](https://docs.agno.com):
|
|
|
|
**Positioning:** "AgentOS" - platform for building agents
|
|
|
|
**Observations:**
|
|
- Focus on production deployment patterns
|
|
- Less mature than Letta in documentation
|
|
- No clear differentiation on memory/state
|
|
|
|
---
|
|
|
|
## 4. Technical Pattern Research
|
|
|
|
### 4.1 Task Queues: Redis + Python
|
|
|
|
From [redis.io/docs](https://redis.io/docs/latest/develop/clients/redis-py/):
|
|
|
|
**Redis-py patterns for Letta:**
|
|
```python
|
|
import redis
|
|
|
|
# Connection with auto-decode
|
|
r = redis.Redis(host='localhost', port=6379, decode_responses=True)
|
|
|
|
# Hash for task storage (matches our design)
|
|
r.hset(f'task:{task_id}', mapping={
|
|
'status': 'pending',
|
|
'prompt': prompt,
|
|
'subagent_type': subagent_type,
|
|
'created_at': timestamp,
|
|
})
|
|
|
|
# Sorted Set for priority queue
|
|
r.zadd('queue:pending', {task_id: priority})
|
|
|
|
# Atomic dequeue with WATCH/MULTI/EXEC
|
|
```
|
|
|
|
**Key Insights:**
|
|
- `decode_responses=True` eliminates manual byte decoding
|
|
- `hset` with `mapping=` is clean for task storage
|
|
- Redis transactions (MULTI/EXEC) provide atomic queue operations
|
|
- Consider `redis[hiredis]` for performance
|
|
|
|
**Alternative: Celery**
|
|
|
|
From [docs.celeryq.dev](https://docs.celeryq.dev):
|
|
|
|
Celery provides:
|
|
- Distributed task processing
|
|
- Real-time + scheduling
|
|
- Worker management
|
|
- Built-in retry logic
|
|
|
|
**Recommendation:** For Phase 1, use **raw Redis** (not Celery):
|
|
- Celery adds abstraction layer that may conflict with Letta's specific needs
|
|
- Our task queue has unique requirements (subagent spawning, git worktrees)
|
|
- Raw Redis gives more control over the data model
|
|
- Can migrate to Celery later if needed
|
|
|
|
### 4.2 Durable Execution: Temporal
|
|
|
|
From [temporal.io](https://temporal.io):
|
|
|
|
**Core Value:** "Write code as if failure doesn't exist"
|
|
|
|
**Key Concepts:**
|
|
- **Workflows**: Durable, fault-tolerant business logic
|
|
- **Activities**: Retryable, failure-prone operations
|
|
- **State persistence**: Automatic checkpointing
|
|
- **Signals**: External events to running workflows
|
|
|
|
**Temporal for Letta ADE:**
|
|
```python
|
|
# Potential Workflow structure
|
|
@workflow.defn
|
|
class SubagentWorkflow:
|
|
@workflow.run
|
|
async def run(self, task_id: str):
|
|
# Activity: Spawn subagent (may fail)
|
|
result = await workflow.execute_activity(
|
|
spawn_subagent,
|
|
task_id,
|
|
start_to_close_timeout=timedelta(minutes=5),
|
|
retry_policy=RetryPolicy(maximum_attempts=3)
|
|
)
|
|
|
|
# Activity: Wait for completion (long-running)
|
|
final_result = await workflow.execute_activity(
|
|
poll_subagent_completion,
|
|
result.agent_id,
|
|
start_to_close_timeout=timedelta(hours=1),
|
|
)
|
|
|
|
return final_result
|
|
```
|
|
|
|
**Decision Matrix:**
|
|
|
|
| Approach | Complexity | Durability | Letta Fit |
|
|
|----------|-----------|------------|-----------|
|
|
| Raw Redis + Workers | Low | Medium | ✅ Good fit |
|
|
| Temporal | Medium | High | ⚠️ Overkill? |
|
|
| Celery | Low | Medium | ⚠️ Too abstract |
|
|
|
|
**Recommendation:**
|
|
- **Phase 1**: Use Redis + custom workers (existing design)
|
|
- **Phase 2**: Evaluate Temporal for complex multi-step workflows
|
|
- Temporal shines for **long-running, multi-step** workflows with human-in-the-loop
|
|
- Letta's subagent tasks are relatively simple (spawn → run → complete)
|
|
|
|
### 4.3 Web Dashboard: React + FastAPI Patterns
|
|
|
|
From [ui.shadcn.com](https://ui.shadcn.com):
|
|
|
|
**Shadcn/ui** provides:
|
|
- Unstyled, accessible components
|
|
- Tailwind CSS integration
|
|
- Customizable design system
|
|
- Modern React patterns
|
|
|
|
**Recommended Dashboard Stack:**
|
|
|
|
```
|
|
Frontend:
|
|
- React + Vite (existing plan)
|
|
- shadcn/ui for components
|
|
- TanStack Query for data fetching
|
|
- WebSocket client for real-time updates
|
|
|
|
Backend:
|
|
- FastAPI (async native)
|
|
- WebSocket support built-in
|
|
- Redis for pub/sub
|
|
- PostgreSQL for metadata
|
|
```
|
|
|
|
**Dashboard Features (Prioritized):**
|
|
|
|
| Priority | Feature | Tech |
|
|
|----------|---------|------|
|
|
| P0 | Agent grid view | React + TanStack Query |
|
|
| P0 | Real-time logs | WebSocket |
|
|
| P1 | Approval queue UI | shadcn Dialog + Table |
|
|
| P1 | Task history | TanStack Query + Pagination |
|
|
| P2 | Memory browser | Tree view component |
|
|
| P2 | Metrics dashboard | Recharts or Tremor |
|
|
|
|
---
|
|
|
|
## 5. Updated Gap Analysis
|
|
|
|
### Revised Comparison Table
|
|
|
|
| Feature | Letta | Intent | Warp | Aider | Cline |
|
|
|---------|-------|--------|------|-------|-------|
|
|
| **Web Dashboard** | ❌ | ✅ | ✅ | ❌ | ❌ |
|
|
| **Persistent Tasks** | ⚠️ | ✅ | ⚠️ | ❌ | ❌ |
|
|
| **Stateful Agents** | ✅ | ⚠️ | ❌ | ❌ | ❌ |
|
|
| **Subagent Orchestration** | ✅ | ❌ | ❌ | ❌ | ❌ |
|
|
| **Git-Native Memory** | ✅ | ❌ | ❌ | ⚠️ | ❌ |
|
|
| **MCP/Skills** | ✅ | ❌ | ✅ | ❌ | ✅ |
|
|
| **Approval Queues** | ✅ CLI | ✅ | ✅ | ❌ | ✅ |
|
|
| **Multi-Model** | ✅ | ? | ✅ | ✅ | ✅ |
|
|
| **Computer Use** | ❌ | ? | ✅ | ❌ | ✅ |
|
|
| **Spec-Driven Dev** | ⚠️ | ✅ | ❌ | ❌ | ❌ |
|
|
|
|
**Key Insights:**
|
|
1. **Letta leads in agent infrastructure** (state, memory, orchestration)
|
|
2. **Commercial tools lead in UX** (dashboards, IDE integration)
|
|
3. **No competitor has Letta's core combination** (stateful + memory + git + subagents)
|
|
4. **Computer Use** is becoming standard (Warp, Cline have it)
|
|
|
|
---
|
|
|
|
## 6. Critical Gaps Identified
|
|
|
|
### High Priority (MVP Blockers)
|
|
|
|
1. **Computer Use / Browser Automation**
|
|
- Warp and Cline both offer browser automation
|
|
- Letta agents should be able to launch browsers, click, screenshot
|
|
- Enables web testing, visual verification
|
|
|
|
2. **Rich Context in Prompts**
|
|
- Warp's "Universal Input" (@file, images, URLs)
|
|
- Currently requires manual file reading
|
|
- Should support: `@path/to/file`, `@https://example.com`, drag-drop images
|
|
|
|
3. **Workspace Snapshots**
|
|
- Cline's snapshot's/restore feature
|
|
- Letta git worktrees provide foundation
|
|
- Need UI for "save point" and "restore to point"
|
|
|
|
### Medium Priority (Competitive Parity)
|
|
|
|
4. **Cost Tracking**
|
|
- Cline shows token usage and cost per request
|
|
- Important for agent transparency
|
|
|
|
5. **Voice Input Flow**
|
|
- Warp integrates with Wispr
|
|
- Nice-to-have, not MVP critical
|
|
|
|
6. **MCP Ecosystem Expansion**
|
|
- Expand skills to full MCP server support
|
|
- Community MCP marketplace
|
|
|
|
---
|
|
|
|
## 7. Revised Implementation Recommendations
|
|
|
|
### Phase 1: Orchestration Layer (Refined)
|
|
|
|
**Duration:** 6 weeks (was 8)
|
|
|
|
**Changes from original design:**
|
|
1. **Week 1-2**: In-memory prototype (unchanged)
|
|
2. **Week 3-4**: Redis integration + worker pool (unchanged)
|
|
3. **Week 5**: API endpoints (REST + WebSocket)
|
|
4. **Week 6**: Task tool integration + testing
|
|
|
|
**Additions:**
|
|
- WebSocket endpoint for real-time task updates
|
|
- Cost tracking (token counting)
|
|
- Rich context parsing (@file, URLs)
|
|
|
|
**Deferred:**
|
|
- Temporal integration (evaluate in Phase 2)
|
|
- Advanced retry policies (basic exponential backoff sufficient)
|
|
|
|
### Phase 2: Dashboard MVP (Refined)
|
|
|
|
**Duration:** 4 weeks
|
|
|
|
**Week 1**: Project setup + Agent grid view
|
|
- Vite + React + shadcn/ui setup
|
|
- TanStack Query integration
|
|
- Basic agent status display
|
|
|
|
**Week 2**: Real-time features
|
|
- WebSocket connection
|
|
- Live log streaming
|
|
- Status updates
|
|
|
|
**Week 3**: Approval queue UI
|
|
- Pending approvals list
|
|
- Accept/Reject buttons
|
|
- Comment/feedback input
|
|
|
|
**Week 4**: Task history + polish
|
|
- Task list with filtering
|
|
- Detail view
|
|
- Error display
|
|
|
|
**Additions based on research:**
|
|
- Cost display (per task, total)
|
|
- Workspace snapshot indicator
|
|
- @mention support in prompts
|
|
|
|
### Phase 3: Integration Ecosystem (Unchanged)
|
|
|
|
**Add priority:**
|
|
1. GitHub App (highest - matches Aider/Warp)
|
|
2. Slack notifications
|
|
3. Linear/Jira (MCP-based)
|
|
4. Webhook triggers
|
|
|
|
### Phase 4: Computer Use (NEW PHASE)
|
|
|
|
**Duration:** 4 weeks
|
|
|
|
**Rationale:** Computer Use is becoming table stakes (Warp, Cline have it)
|
|
|
|
**Scope:**
|
|
- Browser automation (Playwright integration)
|
|
- Screenshot capture
|
|
- Click/type/scroll actions
|
|
- Visual verification workflows
|
|
|
|
**Integration:**
|
|
- New skill: `computer_use`
|
|
- Subagent can launch browser
|
|
- Screenshots stored in MemFS
|
|
|
|
### Phase 5: Specification Layer (Refined)
|
|
|
|
**Duration:** 6 weeks (was 8-10)
|
|
|
|
**Scope reduction:**
|
|
- Start with PRD validation (Zod schemas)
|
|
- Basic constitution enforcement (regex + AST rules)
|
|
- No full natural language spec parsing yet
|
|
|
|
**Deferred:**
|
|
- Full spec regeneration (Intent-level functionality)
|
|
- Architectural diagram generation
|
|
|
|
### Phase 6: Team Collaboration (Unchanged)
|
|
|
|
---
|
|
|
|
## 8. Technical Stack Recommendations (Updated)
|
|
|
|
### Orchestration Layer
|
|
|
|
| Component | Original | Updated | Rationale |
|
|
|-----------|----------|---------|-----------|
|
|
| Queue | Redis | Redis ✅ | Proven, matches research |
|
|
| Durable Execution | Temporal | Redis + Workers | Temporal overkill for Phase 1 |
|
|
| Workers | Python asyncio | Python asyncio ✅ | Good fit |
|
|
| API | FastAPI | FastAPI ✅ | Async native, WebSocket support |
|
|
|
|
### Dashboard
|
|
|
|
| Component | Original | Updated | Rationale |
|
|
|-----------|----------|---------|-----------|
|
|
| Framework | React | React ✅ | Standard |
|
|
| Build Tool | Vite | Vite ✅ | Fast, modern |
|
|
| UI Library | - | shadcn/ui | Accessible, customizable |
|
|
| Styling | - | Tailwind CSS | Standard with shadcn |
|
|
| Data Fetching | - | TanStack Query | Caching, real-time sync |
|
|
| Charts | - | Tremor/Recharts | Dashboard metrics |
|
|
|
|
### Additional Components
|
|
|
|
| Component | Recommendation |
|
|
|-----------|----------------|
|
|
| Browser Automation | Playwright |
|
|
| Rich Context Parsing | Custom parser (@file, URL regex) |
|
|
| Cost Tracking | Token counting in subagent wrapper |
|
|
| WebSocket | FastAPI native + Redis pub/sub |
|
|
|
|
---
|
|
|
|
## 9. Risks and Mitigations
|
|
|
|
### Identified Risks
|
|
|
|
| Risk | Impact | Mitigation |
|
|
|------|--------|------------|
|
|
| Web search unavailable for research | Medium | Use fetch_webpage for known URLs |
|
|
| Temporal overengineering | High | Defer to Phase 2 evaluation |
|
|
| Dashboard scope creep | High | Strict MVP definition (4 weeks) |
|
|
| Computer Use complexity | Medium | Use Playwright, limit scope |
|
|
| Competition pace | Medium | Focus on Letta differentiators |
|
|
|
|
### Competitive Response
|
|
|
|
**If Warp releases open-source:**
|
|
- Warp is terminal + IDE hybrid; Letta is agent infrastructure
|
|
- Different target users (Warp = developers, Letta = agent builders)
|
|
- Letta's stateful/memory approach still differentiated
|
|
|
|
**If Intent releases spec layer as open standard:**
|
|
- Letta could adopt Intent spec format
|
|
- Focus on execution infrastructure
|
|
- Potential collaboration opportunity
|
|
|
|
---
|
|
|
|
## 10. Next Steps (Prioritized)
|
|
|
|
### Immediate (This Week)
|
|
|
|
1. **Decision:** Confirm Redis-only vs Temporal evaluation
|
|
2. **Prototype:** Build in-memory task queue (Week 1)
|
|
3. **Research:** Playwright integration for Computer Use
|
|
4. **Design:** Dashboard wireframes (shadcn components)
|
|
|
|
### Week 2-3
|
|
|
|
5. **Implement:** Redis integration
|
|
6. **Test:** Worker pool with 3+ concurrent workers
|
|
7. **API:** REST endpoints for task management
|
|
|
|
### Week 4-6
|
|
|
|
8. **Integrate:** Modify Task tool to use queue
|
|
9. **WebSocket:** Real-time updates endpoint
|
|
10. **Dashboard:** Start React project setup
|
|
|
|
### Success Metrics
|
|
|
|
| Metric | Target |
|
|
|--------|--------|
|
|
| Task durability | 0% loss on restart |
|
|
| Worker concurrency | 5+ parallel tasks |
|
|
| Dashboard load time | <2 seconds |
|
|
| Approval latency | <1 second from event |
|
|
|
|
---
|
|
|
|
## 11. Conclusion
|
|
|
|
### Updated Assessment
|
|
|
|
**Letta's position is stronger than initially thought:**
|
|
|
|
1. **No open-source competitor** has the combination of:
|
|
- Stateful agents with hierarchical memory
|
|
- Git-native persistence
|
|
- Subagent orchestration
|
|
- Model agnostic design
|
|
|
|
2. **Commercial tools validate the market** but focus on different layers:
|
|
- Intent: Specification layer (Letta can integrate)
|
|
- Warp: Terminal UX (Letta can offer alternative)
|
|
|
|
3. **Technical patterns are well-understood**:
|
|
- Redis queues: Proven, simple
|
|
- Temporal: Powerful but may be overkill
|
|
- React + FastAPI: Standard, well-supported
|
|
|
|
### Final Recommendation
|
|
|
|
**Proceed with Phase 1 (Orchestration) immediately.**
|
|
|
|
The research confirms:
|
|
- The orchestration layer design is sound
|
|
- Redis is the right choice for Phase 1
|
|
- The dashboard stack (React + shadcn + TanStack Query) is industry standard
|
|
- Competitive pressure is real but Letta has unique advantages
|
|
|
|
**Revised Timeline:**
|
|
- Phase 1 (Orchestration): 6 weeks
|
|
- Phase 2 (Dashboard): 4 weeks
|
|
- Phase 3 (Integrations): 4 weeks
|
|
- Phase 4 (Computer Use): 4 weeks
|
|
- Phase 5 (Specifications): 6 weeks
|
|
- Phase 6 (Team): 4 weeks
|
|
|
|
**Total to full ADE:** 7 months (was 6-9)
|
|
|
|
**MVP (Phases 1-2):** 10 weeks (was 3-4 months)
|
|
|
|
---
|
|
|
|
*Research synthesis conducted on March 18, 2026*
|
|
|
|
*Sources: Letta docs, Intent.dev, Warp.dev, Temporal.io, Redis docs, Celery docs, GitHub (Aider, Cline)*
|