[ENHANCEMENT] Native Letta Provider Integration

[Jdo300]

Title: [ENHANCEMENT] Native Letta Provider Integration

Problem

While Roo Code is my daily driver for all things development, I have been using Letta for a while and absolutely love its rock-solid memory management capabilities. However, there is no native way to bring Letta's stateful agents directly into Roo Code. Using generic OpenAI-compatible endpoints doesn't cut it, as it loses the context of Letta's advanced, independent conversation threads and memory systems.

Context

As a developer who uses RooCode as my primary interface for agentic tasks, my own use-case is the main driver here: I want the best of both worlds. I prefer Roo Code’s UI and tool integration leaps and bounds over LettaCode, but I want to seamlessly connect Letta agents (whether hosted at app.letta.com or self-hosted locally) to leverage their long-term memory across my workspaces.

Desired behavior

Add a native "Letta" provider to Roo Code so users can connect directly to any Letta agent.
This integration should include:

• A dedicated Provider settings UI for Letta (Base URL, API key, Agent selector).
• Full support for Letta's Conversations (threads/shared memory).
• A "Conversation Mode" dropdown with three options:
  1. Manual Select: Dropdown of existing conversations + "Create New".
  2. Auto per Workspace: Automatically pick/create a conversation based on the current workspace/folder name and persist it.
  3. New per Roo Code Task: Auto-create a fresh conversation for each new task.
• Seamless tool execution, streaming where possible, and graceful error handling.

Constraints / preferences

The integration should feel exactly like using Letta Code inside Roo Code—zero friction, seamless tools, full state/memory, and no confusion. It should leverage the Letta TypeScript SDK or REST SSE to parse steps/tokens effectively.

Checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

---

Acceptance criteria

Given the user configures the Letta provider with their Base URL and API Key
When they select an existing Letta Agent and set the conversation mode to "Auto per Workspace"
Then Roo Code creates or resumes a Letta conversation specific to that workspace
And the agent successfully executes Roo Code tools (like edit_file or run_command) while maintaining Letta's persistent long-term memory across sessions.

Proposed approach

1. Add lettaSchema to @roo-code/types provider-settings.ts.
2. Build a LettaHandler in src/api/providers/letta.ts that implements Roo Code's ApiHandler interface and handles Letta's streaming responses (step format or token streaming).
3. Create webview-ui/src/components/settings/providers/Letta.tsx with dynamic fetching for agents and conversations.
4. Integrate the new provider into ApiOptions.tsx and the core ClineProvider.ts message handler.

Trade-offs / risks

Connecting to Letta requires managing stateful conversations on Letta's end, which is slightly different from the stateless behavior of other LLM providers. Care must be taken to ensure Roo Code's task lifecycle maps correctly to Letta's conversation structure.

[Jdo300]

Claiming

[roomote]

I have analyzed this issue and explored the existing provider architecture. Here is my proposed implementation plan:

Proposed Implementation Plan

1. Types (packages/types/src/)

• Add "letta" to the providerNames array in provider-settings.ts
• Create packages/types/src/providers/letta.ts with:
  • Model definitions (Letta agent-based model info)
  • Default model ID and model info constants
• Add a lettaSchema to provider-settings.ts with fields:
  • lettaBaseUrl (string) -- Letta server URL (e.g., https://app.letta.com or http://localhost:8283)
  • lettaApiKey (string) -- API key for authentication
  • lettaAgentId (string) -- Selected Letta agent ID
  • lettaConversationMode (enum: "manual", "auto-workspace", "new-per-task")
  • lettaConversationId (string, optional) -- For manual mode conversation selection
• Register lettaSchema in the discriminated union and flat providerSettingsSchema

2. API Handler (src/api/providers/letta.ts)

• Create LettaHandler extending BaseProvider implementing ApiHandler
• Use the Letta REST API (or TypeScript SDK if available) to:
  • Send messages to the selected agent within a conversation
  • Stream responses using Letta SSE endpoints
  • Map Letta response steps/tokens to Roo Code ApiStream chunks (text, usage)
• Implement conversation management:
  • Manual: Use the user-selected lettaConversationId
  • Auto per Workspace: Derive a conversation name from the workspace folder, create-or-resume
  • New per Task: Create a new conversation for each Roo Code task
• Handle Letta tool execution responses (map Letta tool calls to Roo Code tool format)
• Register the handler in src/api/index.ts buildApiHandler() switch statement

3. Settings UI (webview-ui/src/components/settings/providers/Letta.tsx)

• Create a Letta provider settings component with:
  • Base URL input field
  • API Key input field
  • Agent selector dropdown (fetched dynamically from Letta API)
  • Conversation Mode dropdown (Manual / Auto per Workspace / New per Task)
  • Conditional conversation selector (shown only in Manual mode)
• Register in webview-ui/src/components/settings/providers/index.ts
• Integrate into ApiOptions.tsx provider switch

4. Tests

• Unit tests for LettaHandler (message creation, streaming, conversation management)
• Unit tests for the settings UI component
• Type tests for the new schema

Key Questions Before Proceeding

Before I implement, I would like to confirm a few things:

1. Letta SDK vs REST: The Letta TypeScript SDK (@letta-ai/letta-client) would simplify the implementation. Should I add it as a dependency, or should I use raw REST/SSE calls to minimize dependencies?

2. Tool mapping: Letta agents have their own tool system. Should Roo Code tools (edit_file, run_command, etc.) be registered as Letta tools on the agent, or should the handler intercept tool-call-like responses and map them to Roo Code's tool execution pipeline?

3. Conversation persistence: For "Auto per Workspace" mode, where should the workspace-to-conversation mapping be persisted? Options include VSCode workspace storage, a local JSON file, or the extension's global state.

4. Model info: Since Letta agents wrap underlying LLMs, should the model info (context window, pricing, capabilities) reflect the underlying LLM the agent uses, or should we use generic defaults?

Please mention @roomote in a comment saying that you approve this plan (with answers to the questions above if possible), and I'll proceed with the implementation.