- 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>
258 lines
9.9 KiB
Markdown
258 lines
9.9 KiB
Markdown
# Agent Development Environment (ADE) Research
|
|
|
|
**Date:** March 17, 2026
|
|
**Purpose:** Compare existing ADE solutions to inform Letta Community ADE development
|
|
|
|
---
|
|
|
|
## Executive Summary
|
|
|
|
The ADE category emerged in 2025 as agentic AI proved too complex for traditional IDE/CLI tooling. Three primary architectures exist:
|
|
|
|
1. **Letta ADE** - Memory-first, context window transparency, multi-model
|
|
2. **Intent (Augment)** - Spec-driven with coordinator/specialist/verifier pattern
|
|
3. **Warp Oz** - Terminal-native with cloud orchestration
|
|
|
|
Each approaches multi-agent orchestration differently, offering distinct tradeoffs for community implementation.
|
|
|
|
---
|
|
|
|
## 1. Letta ADE (Our Foundation)
|
|
|
|
### Core Philosophy
|
|
> "Designing great agents is all about designing great context windows"
|
|
|
|
Letta ADE makes the opaque world of context windows and agent reasoning **visible and manageable**.
|
|
|
|
### Key Features
|
|
|
|
| Feature | Implementation |
|
|
|---------|---------------|
|
|
| **State & Memory** | Stateful agents that learn from interactions vs stateless LLMs |
|
|
| **Context Management** | Editable memory blocks, tools, system prompts with character limits |
|
|
| **Memory Architecture** | Core Memory (in-context blocks) + Archival/Recall Memory (vector DB) |
|
|
| **Transparent Reasoning** | All agents must show their work - reasoning separated from user communication |
|
|
| **Tool Integration** | 7,000+ tools via Composio, custom Python tool editor |
|
|
| **Production Modes** | Simple/Interactive/Debug modes for different use cases |
|
|
|
|
### Architecture Highlights
|
|
- **Core Memory**: Editable in-context blocks (`core_memory_append`, `core_memory_replace`)
|
|
- **Archival Memory**: Vector database for free-form storage (`archival_memory_insert`, `archival_memory_search`)
|
|
- **Recall Memory**: Automatic conversation history tracking (`conversation_search`)
|
|
- **Context Pruning**: Recursive summarization + message pruning to manage window size
|
|
|
|
### Strengths
|
|
✅ Memory-first design (MemGPT heritage)
|
|
✅ Transparent reasoning by design
|
|
✅ Context window controls
|
|
✅ Real-time tool execution in ADE
|
|
✅ Production deployment ready
|
|
|
|
### Letta Code CLI Features
|
|
- Client-side tool execution (Bash, Read, Write execute locally)
|
|
- Streaming API with background mode for long operations
|
|
- Conversations API for parallel sessions with shared memory
|
|
- Subagent spawning via Task tool
|
|
- Memory-first coding with persistent context
|
|
|
|
---
|
|
|
|
## 2. Intent by Augment Code
|
|
|
|
### Core Philosophy
|
|
> "Spec-Driven Development puts the spec at the center of your workflow"
|
|
|
|
Intent uses **living specifications** that update as agents work, preventing the "outdated PRD" problem.
|
|
|
|
### Key Features
|
|
|
|
| Feature | Implementation |
|
|
|---------|---------------|
|
|
| **Spec-Driven** | Living spec as source of truth - updates as code changes |
|
|
| **Coordinator Pattern** | Coordinator → Specialists → Verifier pipeline |
|
|
| **Parallel Work** | Isolated git worktrees for concurrent agent execution |
|
|
| **Specialist Agents** | Investigate, Implement, Verify, Critique, Debug, Code Review |
|
|
| **BYOA** | Bring Your Own Agent (Claude Code, Codex, OpenCode supported) |
|
|
| **Context Engine** | Semantic dependency analysis across 400,000+ files |
|
|
|
|
### Architecture: Coordinator/Specialist/Verifier
|
|
|
|
```
|
|
Coordinator Agent
|
|
↓ analyzes codebase, drafts spec, generates tasks
|
|
Specialist Agents (parallel in isolated worktrees)
|
|
↓ execute scoped tasks
|
|
Verifier Agent
|
|
↓ validates against spec before merge
|
|
Changes Tab
|
|
↓ human review, merge/stage/create PR
|
|
```
|
|
|
|
### Specialist Roles
|
|
- **Investigate** - Explore codebase, assess feasibility
|
|
- **Implement** - Execute implementation plans
|
|
- **Verify** - Check implementations match specs
|
|
- **Critique** - Review specs for feasibility
|
|
- **Debug** - Analyze and fix issues
|
|
- **Code Review** - Automated reviews with severity
|
|
|
|
### Unique Features
|
|
- **Git Worktree Isolation**: Each agent runs in independent working directory
|
|
- **WARP.md**: Compatible with agents.md, claude.md for agent behavior
|
|
- **Context Engine**: Call-graph and dependency-chain understanding
|
|
- **Verifier Agent**: Catches misalignment before human review
|
|
|
|
### Compliance
|
|
- SOC 2 Type II (zero deviations, Coalfire audited)
|
|
- ISO/IEC 42001 (AI governance certification)
|
|
- Customer-Managed Encryption Keys (CMEK)
|
|
- Air-gapped deployment options
|
|
|
|
### Strengths
|
|
✅ Living specs prevent drift
|
|
✅ Verifier catches misalignment
|
|
✅ Enterprise compliance (dual certification)
|
|
✅ BYOA prevents lock-in
|
|
✅ Context Engine handles massive codebases
|
|
|
|
---
|
|
|
|
## 3. Warp Oz (Terminal-Native ADE)
|
|
|
|
### Core Philosophy
|
|
> "Break out of your shell" - Terminal as the primary surface for agentic development
|
|
|
|
Warp reimagines the terminal as an agent platform with **Oz orchestration**.
|
|
|
|
### Key Features
|
|
|
|
| Feature | Implementation |
|
|
|---------|---------------|
|
|
| **Full Terminal Use** | Agents can run interactive CLI apps (REPLs, debuggers, top) |
|
|
| **Cloud Agents** | Background agents on Warp infrastructure or self-hosted |
|
|
| **Local Agents** | Real-time interactive coding in Warp terminal |
|
|
| **Auto-Tracking** | Every agent produces link + audit trail |
|
|
| **Multi-Model** | Mixed-model approach with fallback chains |
|
|
| **Skills** | Reusable instructions (compatible with Claude Code, Codex) |
|
|
|
|
### Architecture: Oz Platform
|
|
|
|
**Local Mode:**
|
|
- Run directly in Warp app
|
|
- Real-time, interactive assistance
|
|
- Multi-step planning, debugging, fixing
|
|
|
|
**Cloud Mode:**
|
|
- Run on Warp infrastructure (or self-hosted)
|
|
- Scheduled agents (cron-like)
|
|
- Event triggers (Slack, GitHub, webhooks)
|
|
- Parallel execution across repos
|
|
|
|
### Oz Capabilities
|
|
- **Environments**: Docker containers + git repos + startup commands
|
|
- **Session Sharing**: Links to track and steer agents
|
|
- **Artifacts**: PRs, branches, plans automatically tracked
|
|
- **Skills**: Any Skill can become an agent automation
|
|
- **API/SDK/CLI**: Fully programmable agent stack
|
|
|
|
### Unique Features
|
|
- **Multi-Repo Changes**: One agent can work across repos
|
|
- **Computer Use**: Visual verification via screenshots
|
|
- **Agent Session Sharing**: Hop into any running agent
|
|
- **Cloud Mode**: Background automation with full visibility
|
|
|
|
### Performance Claims
|
|
- Terminal-Bench: #1 ranked (52% → 61.2%)
|
|
- SWE-bench Verified: 71%
|
|
- 60%+ merged PRs created by Oz
|
|
- 700K+ active developers
|
|
|
|
### Security
|
|
- SOC 2 Type 2 certified
|
|
- Contractual Zero Data Retention (ZDR) with Anthropic, OpenAI, Fireworks, Google
|
|
- Configurable permissions (Never/Always allow/Prompt/Let agent decide)
|
|
- Agent Profiles (Prod mode/YOLO mode)
|
|
|
|
### Strengths
|
|
✅ Full terminal control (unique in market)
|
|
✅ Cloud agent infrastructure
|
|
✅ Multi-repo changes
|
|
✅ Contractual ZDR across all providers
|
|
✅ Terminal-native workflow
|
|
|
|
---
|
|
|
|
## 4. Feature Comparison Matrix
|
|
|
|
| Feature | Letta ADE | Intent | Warp Oz |
|
|
|---------|-----------|--------|---------|
|
|
| **Orchestration Model** | Memory-driven | Coordinator/Specialist/Verifier | Local + Cloud agents |
|
|
| **Core Abstraction** | Context windows + Memory | Living specs + Git worktrees | Terminal + Environments |
|
|
| **Multi-Agent** | Subagents via Task | Parallel specialists | Cloud agent pool |
|
|
| **Isolation** | Memory blocks | Git worktrees | Docker environments |
|
|
| **Context Strategy** | Hierarchical memory | Semantic Context Engine | Codebase indexing + MCP |
|
|
| **Verification** | Tool return validation | Verifier agent | Human-in-the-loop |
|
|
| **BYOA** | Open source, BYOK | Claude/Codex/OpenCode | Multi-model, BYOK |
|
|
| **Compliance** | SOC 2 | SOC 2 + ISO 42001 | SOC 2 + ZDR |
|
|
| **Scale** | Terminal-Bench #1 | 400K+ files | 700K+ developers |
|
|
| **Unique** | Memory-first | Spec-driven | Terminal-native |
|
|
|
|
---
|
|
|
|
## 5. Community ADE Recommendations
|
|
|
|
Based on this research, here's what a **Letta Community ADE** should prioritize:
|
|
|
|
### Phase 1: Foundation (Letta Already Has)
|
|
- ✅ Memory-first architecture (Core/Archival/Recall)
|
|
- ✅ Context window transparency
|
|
- ✅ Subagent spawning (Task tool)
|
|
- ✅ Real-time tool execution
|
|
- ✅ Multi-model support
|
|
|
|
### Phase 2: Enhanced Orchestration (From Intent)
|
|
- **Git Worktree Isolation**: Execute subagents in isolated branches
|
|
- **Coordinator Pattern**: Formal coordinator/specialist/verifier roles
|
|
- **Approval Queue Enhancement**: Structured task delegation
|
|
- **Spec Tracking**: Document what was planned vs executed
|
|
|
|
### Phase 3: Scale Features (From Warp)
|
|
- **Cloud Agent Mode**: Background agents with session tracking
|
|
- **Multi-Repo Support**: Cross-repository changes
|
|
- **Skills System**: Reusable agent instructions
|
|
- **Session Sharing**: Links to share agent runs
|
|
|
|
### Phase 4: Advanced Features
|
|
- **Verification Layer**: Automated spec compliance checking
|
|
- **Context Engine**: Semantic dependency analysis
|
|
- **Scheduling**: Recurring agent tasks
|
|
- **Event Triggers**: React to GitHub/Slack events
|
|
|
|
---
|
|
|
|
## 6. Key Implementation Insights
|
|
|
|
### From Intent: Spec-Driven Works
|
|
The "living spec" concept prevents the most common agent failure mode: drift between intent and implementation. Letta's memory blocks could serve this purpose with explicit "plan" vs "execution" blocks.
|
|
|
|
### From Warp: Terminal is Underrated
|
|
Full terminal control enables agents to use the same tools developers use (REPLs, debuggers, etc.). Letta Code's Bash tool already supports this, but could be enhanced with "terminal session" preservation.
|
|
|
|
### From Letta: Memory is Differentiating
|
|
Neither Intent nor Warp have Letta's tiered memory architecture. This is a unique strength to build upon - memory as the coordination layer, not just context.
|
|
|
|
---
|
|
|
|
## 7. Sources
|
|
|
|
1. [Letta ADE Blog](https://www.letta.com/blog/introducing-the-agent-development-environment)
|
|
2. [Letta ADE Docs](https://docs.letta.com/guides/ade/overview/)
|
|
3. [Intent by Augment](https://www.augmentcode.com/product/intent)
|
|
4. [Intent ADE Guide](https://www.augmentcode.com/guides/what-is-an-agentic-development-environment)
|
|
5. [Warp Oz Platform](https://www.warp.dev/oz)
|
|
6. [Warp Oz Launch](https://www.warp.dev/blog/oz-orchestration-platform-cloud-agents)
|
|
|
|
---
|
|
|
|
*Generated by Ani (Letta agent) - March 17, 2026*
|