This Letta episode examines how persistent agents keep work visible, return to tasks, and coordinate across tools and conversations. Cameron introduces the Agent Tray, Wake, structured decisions, and Watch PR, then uses a live bug report to demonstrate a Linear workflow. The Q&A connects those features to asynchronous messaging, external chat applications, and the difficulty of correcting an agent's memory.
The guide records what the episode demonstrates and proposes. Feature availability and interface details describe the recording, rather than a guarantee about the current product. The series index collects earlier recordings and explanatory guides.
Selected chapters
| Time | Topic |
|---|---|
| 00:00 | Agent Tray and cross-conversation notes |
| 02:58 | Wake and one-time follow-ups |
| 04:40 | Jev Decisions in workflows |
| 07:28 | Watch PR |
| 17:00 | Classification, routing, and evaluation |
| 29:14 | Agent messages versus subagent tasks |
| 36:20 | Communication between different users' agents |
| 42:20 | Building channels with the Agent SDK |
| 51:45 | Secrets and a reported redaction failure |
| 56:08 | Live Linear and bug-triage demo |
| 01:11:48 | Dreaming and memory accuracy |
| 01:14:08 | Agent review of memory updates |
| 01:18:24 | Linear versus Notion for personal projects |
A visible tray and two ways to return to work
The Agent Tray is an agent-scoped Markdown panel shared across conversations. In the demo, both the user and agent edit its contents. Tables, checkboxes, and code blocks make it useful for showing tasks, open questions, or information that should remain visible when the conversation changes. At the time of the recording, Cameron says agent-side editing requires a cloud sandbox; the panel is shown in Desktop and discussed for the web interface.
The tray gives a person a compact view of what the agent considers important. It does not establish that a displayed task has been executed. A checkbox is still a representation of work whose result may live elsewhere.
Wake packages a one-time scheduled prompt into a tool. Cameron asks an agent to return two minutes later and shows its subsequent response. The point is convenience: an agent can schedule a follow-up without constructing a scheduling workflow for each request.
Watch PR follows activity on a GitHub pull request, including checks, comments, and reviews, and notifies the agent of events it can act on. Cameron introduces it as a new tool he has not yet used extensively. Wake is suited to a known future time; Watch PR is suited to changes in an external task. Neither introduction demonstrates that every requested follow-up will succeed.
Structured decisions inside a workflow
Jev produces constrained decisions rather than an unrestricted prose answer. The episode shows how a workflow can ask for a choice, a yes-or-no judgment, or a score. For example, a worker might collect evidence about unexpected behavior, and a decision step might classify it as a bug or expected behavior.
Constrained outputs make the next program step easier to write. An email workflow could choose among archive, retain, and flag; a routing workflow could select a worker from an explicit list. The model still has to make the right judgment. Cameron recommends evaluating it on the intended task rather than treating a structured answer as evidence of reliability.
The discussion also considers tool selection. A classifier could examine a request and choose which tools to attach before the primary agent needs them. This is presented as an idea for a mod, not as a demonstrated shipping feature.
Classification can shift costs elsewhere
Routing between language models may save inference cost while losing prompt-cache reuse. A prompt cache lets a provider reuse computation for a repeated input prefix. Switching models can require that work to be performed again, depending on the provider and routing design. The episode raises this as a reason to measure the complete workflow, rather than only the classifier's speed.
A related debate concerns removing supposedly unnecessary messages from conversation history. Deleting an early message changes the prefix seen by later requests, potentially invalidating much of the cached input. It may also remove information needed for a later task. The discussion leaves the quality question open: assess both cache cost and performance on long-running work before replacing an existing compaction strategy.
Messaging and delegation have different completion rules
An asynchronous message asks another agent to handle information independently. The sending agent can continue working, and the recipient must send a reply if a reply is needed. Acceptance of the message therefore does not establish that the requested work has finished.
Invoking an agent through a subagent task has a different contract: the parent receives a completion notification when that task ends. The episode explains that an existing persistent agent can also be invoked this way. The useful distinction is how the work is tracked and returned, rather than whether the recipient already has an identity and memory.
For a bounded research or implementation assignment, a completion notification helps the parent collect the result. For ongoing coordination between agents with independent work, asynchronous messages let each participant decide what to do next. The sender still needs to specify whether it expects an acknowledgment, a result, or no reply.
Cross-user communication adds an authorization problem. A shared channel can provide a meeting place; direct platform access may require credentials with much broader powers. Cameron discusses an opt-in routing service with a permissions table as a possible design. The episode does not establish that such a service is available, and it does not make exchanging account keys a safe default.
A chat connection needs an incoming path
The Agent SDK discussion separates receiving a message from giving an agent a tool to answer it. A conventional Model Context Protocol (MCP) tool can expose an action such as sending a Telegram reply. An incoming message still needs a listener that invokes the agent.
Cameron outlines a Telegram-style application:
- Register a webhook so the service receives incoming messages.
- Wrap each message with its origin and reply information, including the relevant chat identifier.
- Deliver that envelope to the agent through the SDK.
- Provide an outbound action that sends the response to the originating conversation.
This is an architectural explanation, not a complete production implementation. A deployed relay must also authenticate incoming traffic, handle retries, and prevent one conversation's response from reaching another. The recording's central distinction is useful even for a small application: the send tool and the incoming event path solve different parts of the connection.
A live bug report becomes a Linear workflow
During the secrets discussion, a viewer reports that an agent can see a secret after writing it to a file and reading it back. Cameron first describes redaction as expected behavior, then accepts the reported result as a bug. The subsequent investigation identifies an apparent gap between shell-output scrubbing and a later file-read tool. That is the demo's diagnosis, not independent verification that every affected path has been repaired.
The Linear demonstration splits the response into two tasks: search for an existing issue and inspect the relevant code. The agent is then asked to create a self-contained ticket. The distinction between identifying a problem, recording it, and fixing it remains important; the recording does not show a completed deployment of the repair.
A second workflow looks through tickets for tractable work and asks the agent to surface short decisions for the human. Instead of handing back a large undifferentiated backlog, the proposed workflow identifies what needs approval or clarification before implementation can proceed.
The demo also shows work starting from Linear. Assigning an issue to the agent integration opens an agent session, while a mention can initiate another interaction. Linear's automation rules can route tickets based on conditions such as a label and triage status. The agent's instructions or shared skill then determine how it handles the assigned issue. A team can therefore work from either direction: ask an agent to inspect tickets, or use the ticket system to invoke the agent.
Memory quality depends on how errors get corrected
Agent memory can preserve useful knowledge and repeat mistakes. In the Dreaming discussion, Cameron describes an approach in which background reflection updates memory and later evidence corrects errors. A coding agent can encounter an interface in the repository that contradicts its stored description, giving the system concrete evidence for a correction.
Companion interactions often lack that external check. A person may have to notice and correct a mistaken account of their own life. The episode argues that this correction burden makes approximate memory updates more consequential in companion use than an engineering example might suggest.
Two controls are discussed. Disabling Dreaming limits background updates but increases the need to manage memory deliberately. Enabling agent review lets a reflection process propose changes for the primary agent to inspect before merging. Additional instructions can draw attention to recurring errors, such as inaccurate personal facts. Cameron recommends the review option for many users while noting its extra token cost; it is a recommendation, not a guarantee of factual accuracy.
Human review of every memory change is discussed as a possible future interface, with scale as an obstacle. Agents learning across many conversations could generate more changes than a person can reasonably inspect. The episode distinguishes that proposal from the agent-review control already being described.
Choosing a shared work surface
The closing comparison places Linear's opinionated issue workflow beside Notion's more flexible databases and views. Linear supplies a structure for moving tickets through a project. Notion allows users to design a broader workspace, including a task board shared by agents on different systems, but requires more choices about organization.
Co's synthesis of the episode is that persistent agents need separate mechanisms for visible state, future activation, task completion, and memory correction. The tray displays state; Wake and Watch PR bring attention back; messages and subagent tasks determine how results return; a ticket system organizes work; memory review governs what the agent carries forward. Keeping those responsibilities explicit makes it easier to diagnose an agent that appears active but has not delivered the requested result.