# Record **Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`) ## `knowledge-letta-office-hours-2026-02-05` **Collection:** `site.standard.document` **AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-letta-office-hours-2026-02-05` **Title:** Letta Office Hours: Opus 4.6, Lettabot Updates, Agent File Directory, and More **Published:** Fri, 07 Aug 2026 02:41:24 GMT **Updated:** Fri, 21 Aug 2026 03:27:30 GMT **Description:** Office hours on Opus 4.6, Letta Code provider setup, Lettabot, agent self-forking, and why Letta favors stateful agents over retrieval-only memory. **Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f` **Path:** /letta-office-hours-2026-02-05 **Tags:** knowledge, journal, ai, agents, letta, office-hours, public-source, opus-4-6, letta-code, lettabot, agent-memory, provider-support, multi-agent-systems **Content:** ```json { "text": "[Watch this episode on YouTube]()\n\nThe [February 5, 2026 Letta Office Hours episode](https://www.youtube.com/watch?v=LKRnP-ptC4c) covers Claude Opus 4.6, benchmark cost, model-provider setup in Letta Code, Lettabot, subagent coordination, and memory beyond retrieval. Cameron's recurring question is operational: how well does a model perform once tool use, token cost, provider behavior, retained state, and deployment are included?\n\nThis guide is part of the [Letta Office Hours archive](https://cameron.stream/knowledge/letta-office-hours). It records the product and design discussion from that date; current behavior belongs in the [Letta documentation](https://docs.letta.com/).\n\n## Selected chapters\n\n- [00:04:00](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=240s) Opus 4.6 lands in Letta's model lineup\n- [00:05:00](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=300s) Agents can fork themselves or reuse existing agents\n- [00:06:00](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=360s) File system benchmark results and cost tradeoffs\n- [00:07:30](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=450s) Skills benchmark comparison across models\n- [00:11:30](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=690s) Expanded `/connect` flow in Letta Code\n- [00:12:30](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=750s) Project-level LLM key management and BYOK setup\n- [00:17:30](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=1050s) What Lettabot is and how it is deployed\n- [00:18:30](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=1110s) Lettabot architecture and remote agent access\n- [00:31:00](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=1860s) Skills and autonomous workflows from email to RSS\n- [01:18:00](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=4680s) Letta Cowork and the broader product direction\n- [01:43:00](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=6180s) Why Letta emphasizes state over retrieval-only RAG\n- [01:47:30](https://www.youtube.com/watch?v=LKRnP-ptC4c&t=6450s) Closing reflections on feedback and weekly office hours\n\n## Benchmarks include tool and token cost\n\nOpus 4.6 is the episode's headline model update. Cameron says Letta had prepared Cloud support and uses the release to discuss two internal evaluations: a file-system benchmark and a skills benchmark.\n\nThe file-system result places Opus 4.6 slightly ahead of GPT-5.2 in the recorded comparison. Cameron also examines how many tool calls, file reads, and tokens each model used. A higher score can cost more to obtain, which changes the economics of an agent that works for many turns.\n\nThe skills benchmark makes a related point. Model choice depends on the task and on the provider path serving the model. A model that performs well through one integration may become less reliable when another provider changes its tool schema, context handling, or upstream routing.\n\n## Letta Code exposes provider setup\n\nThe expanded `/connect` flow supports bring-your-own-key connections for OpenAI, Anthropic, Google Gemini, MiniMax, OpenRouter, Bedrock, and enterprise configurations discussed in the episode. Project-level key management makes the active provider visible in the product instead of leaving it entirely in external configuration.\n\nThis setup lets one agent use different model backends without moving its memory and identity into each provider's chat product. Behavior still varies by model and provider; portability preserves the surrounding state, not identical results.\n\n## Lettabot hosts an agent behind messaging channels\n\nLettabot is presented as a server-hosted Letta Code deployment available through Docker or a Railway template. Messaging channels connect users to the remote agent, while the server retains the agent process and its working environment.\n\nCameron demonstrates a personal agent editing Obsidian notes, transcribing voice memos, and searching conversation history. Other examples use skills for recurring email briefings and RSS digests. These tasks combine retained context, tools, schedules, and a channel through which the result returns.\n\n## Subagents divide work without erasing identity\n\nLetta agents can fork themselves, invoke an existing agent by ID, or delegate to specialized subagents. A coding agent might send exploration to a faster worker and retain the main conversation for synthesis and decisions.\n\nDelegation introduces ownership questions. Each worker needs a defined task and context, and the coordinating agent needs enough evidence to interpret the result. Shared names or memory do not make separate runs one execution history.\n\n## Memory includes behavior and retained state\n\nAudience questions compare retrieval-augmented generation, agentic search, memory, and long context windows. Cameron treats retrieval as one mechanism inside a larger stateful system. Search can find a relevant file, while memory also includes the retained records and procedures that shape later behavior.\n\nThe distinction explains why the episode connects provider setup, Lettabot, skills, and subagents. Models supply inference. The agent system supplies continuity, tools, execution, and ways to revise what later turns can use.\n\n## Product surfaces share one stateful architecture\n\nThe episode places Letta Code, Lettabot, Letta Cowork, and the Agent SDK around the same persistent-agent model. They serve different interfaces and deployment settings. Their common requirement is that an agent can be reached again with retained state and a known tool environment.\n\nCameron closes by asking which topics viewers want explored in later sessions. The product set was broad and still changing. This page therefore preserves the architecture discussed on February 5 rather than treating every named product or model path as current.\n\n## Public sources\n\n- [YouTube episode](https://www.youtube.com/watch?v=LKRnP-ptC4c)\n- [Letta documentation](https://docs.letta.com/)\n- [Letta](https://github.com/letta-ai/letta)\n- [Lettabot](https://github.com/letta-ai/lettabot)\n- [Letta Code](https://github.com/letta-ai/letta-code)\n- [Letta Agent SDK](https://github.com/letta-ai/letta-agent-sdk)\n- [Letta Cowork](https://github.com/letta-ai/letta-cowork)\n\n## Sources\n\n- [Official YouTube episode]()\n- [Letta documentation]()", "$type": "site.standard.content.markdown", "version": "1.0" } ``` --- *Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*