The tutorial demonstrates how to build a stateful engineering copilot using Letta by moving beyond simple prompt-based chat. The setup creates inspectable core memory blocks that the agent updates autonomously, while exposing them for programmatic synchronization and shared access across multiple agents.
Technical components
The architecture extends with archival vector memory for semantic retrieval. A custom server-side tool handles deterministic risk estimation. Streaming allows observation of agent execution, while server-side message history ensures persistent conversations. Finally, .af export provides portability. Together, these components form an integrated system where persistent state, retrieval, tools, multi-agent collaboration, and execution traces work in unison.
The code begins by installing the Letta client SDK. Compatibility helpers manage API variations across Letta versions. A dynamic model selection process picks from a preferred list including OpenAI and Anthropic models, or falls back to the first available handle.
Core memory blocks
The tutorial creates a stateful agent named Mnemo with four specific memory blocks. Each block has a defined limit and purpose:
- persona: Defines the agent as terse and concrete, refusing to invent facts.
- human: Stores durable facts about the engineer, such as name, role, and stack.
- project_state: Tracks live project milestones, blockers, and decisions. This block remains dense and current, deleting stale lines.
- lessons: An append-only list of mistakes to avoid in future work.
Initial inspection shows the agent at birth with empty project and lesson blocks.
Updating memory through interaction
The agent receives instructions from a user named Priya, a staff engineer at Northwind. She is building a Rust ingestion service called Halo, shipping on November 14. She requests bullets or code over essays. The current blocker is a Kafka consumer rebalancing every four minutes under load.
After a second turn, the agent learns the cause: a 5s max.poll.interval.ms setting combined with slow batch commits. The decision is to move commits off the poll loop. The agent is explicitly told not to suggest bumping session.timeout.ms again, as that failed previously.
Programmatic state updates
The code allows external scripts to write directly into the context window. A function retrieves the current project_state block. The script appends a new line noting that a CI test for integration/kafka_rebalance_test is failing and is flaky.
When the user asks what to know before starting the day, the agent references the updated state immediately.
Multi-agent collaboration
The tutorial sets up shared memory between two agents. A block named policies is created as read-only. It contains non-negotiable rules: no direct pushes to main, every fix must ship with a regression test, and customer data never leaves EU regions.
A second block, team_scratchpad, is created for shared working notes. Both the copilot and the reviewer agent can read and write here. Entries must be prefixed with the user’s name.
A reviewer agent named Argus is created. This agent is described as paranoid and looks for failure modes others skip, citing team policies by number. The reviewer is attached to both the policies and scratchpad blocks.
The copilot is instructed to write a proposed fix for the rebalance issue into the team_scratchpad block. The limit is four lines. The tutorial concludes by showing what the reviewer sees in the shared block, which was written by the other agent.
What it means
This approach separates memory from conversation. Engineers can treat the agent’s context as a database of facts rather than a chat log. Updates to project state or policy rules happen via code, ensuring consistency. Multiple agents can read the same shared blocks, allowing a reviewer to see a copilot’s proposed fix without the copilot needing to re-explain the context.
