The August 27, 2026 Letta Office Hours episode connects a new Linear integration and shared-memory skills to the design of agent-driven software factories. The goal is to improve a product without manufacturing review work. Cameron demonstrates agents taking Linear issues inside cloud sandboxes and teams distributing procedures through Git-backed skills. He later describes an internal experiment that produced roughly 70 low-value pull requests.
The revised workflow begins earlier. Agents reproduce and localize bugs before implementation, continuous integration checks machine-readable requirements, and humans retain product and architectural judgment. The same structure appears in the episode's later discussion of agent payments and agent-to-agent communication: useful delegation needs visible work, scoped authority, and evidence that an effect occurred.
This guide is part of the Letta Office Hours archive. It records the product behavior, plans, and opinions discussed on August 27. Current Letta and Linear documentation remain the sources for present behavior.
Selected chapters
| Time | Topic |
|---|---|
| 00:43 | Letta agents in Linear |
| 04:21 | Linear Loops for issue automation |
| 08:50 | Sharing skills between agents |
| 13:19 | OpenRouter OAuth |
| 15:06 | GLM 5.3 Flash |
| 16:50 | Agent memory and shared memory remain separate |
| 20:39 | Model-specific toolsets |
| 30:00 | Planned hosted Telegram routing |
| 55:00 | Training-data terms for discounted inference |
| 59:30 | A cross-harness Subconscious agent |
| 01:06:00 | What went wrong in Misaligned |
| 01:12:03 | Defining a software factory |
| 01:15:00 | Seventy pull requests and a failed factory design |
| 01:18:30 | Reproduction-first bug triage |
| 01:23:30 | Continuous integration as an agent signal |
| 01:28:49 | Ownership when agents write the code |
| 01:37:19 | Agent-to-agent communication through existing channels |
Linear becomes an execution surface
The episode opens with a preliminary Letta Cloud integration for Linear. A user can mention a Letta agent in an issue or delegate the issue to it. The agent receives the issue as work, starts a cloud sandbox, and posts its progress and result back into the issue.
The demonstration preserves several separate objects:
| Object | Role in the workflow |
|---|---|
| Linear issue | Work request, status, discussion, and human ownership |
| Linear Loop | Trigger and dispatch rule |
| Letta agent | Persistent identity, memory, and tools |
| Conversation | One thread of work for that agent |
| Cloud sandbox | Isolated computer where commands and file changes run |
| Shared-memory skill | Team procedure for performing the work |
| Continuous integration | Executable evidence about the resulting change |
Linear's documentation makes the ownership split explicit: delegating an issue to an agent leaves the human teammate as its primary assignee. Its Loops can trigger on a schedule or issue conditions, carry instructions, use connected services, and expose run history. The episode combines those Linear primitives with Letta's persistent agents.
Cameron's triage Loop watches for a label and status, then delegates the issue to a Letta agent. The Loop tells the agent to load a factory triage skill from shared memory. This separates when work starts from how the team expects it to be done. Trigger changes stay in Linear; procedure changes stay in a versioned skill used by every attached agent.
The first safety measure appears before implementation. Ezra, Letta's community support agent, can prepare an issue, but Cameron says the agent does not normally publish one without his approval. That approval checks whether the reported problem has been understood well enough to enter the factory.
Shared skills distribute procedure
Shared memory gives multiple cloud-hosted Letta agents access to one organization-owned Git repository. The repository can hold product knowledge, plans, research, and skills under skills/<name>/SKILL.md. Attached agents see repository metadata in their system prompt and can read or edit its files with ordinary file and Git tools.
The episode demonstrates one agent creating a shared skill and another attaching the repository, discovering the skill, and proposing changes. A team can therefore revise one pull-request or triage procedure instead of repairing the same instructions in every agent.
Shared procedure does not merge agent identity. Cameron clarifies during Q&A that each agent's own memory remains a separate repository. Shared memory is attached beside it. An agent may learn something from the common repository and retain a related note in its own memory, but the two stores have different owners and synchronization rules.
This architecture reduces behavioral drift only when the shared repository itself has review discipline. A bad edit can change how every attached agent works. Git history makes the change inspectable and reversible; it does not decide whether the new procedure is sound.
Models, sandboxes, and channels
The release roundup also covers OpenRouter OAuth, GLM 5.3 Flash, cloud-sandbox reliability, and model-specific toolsets.
At the time of the episode, Letta had added an OpenRouter OAuth flow and appeared in OpenRouter's application rankings. Cameron described GLM 5.3 Flash as a newly revealed multimodal model. He said a directly selectable Letta-hosted endpoint would be available, while dedicated inference and placement in automatic routing remained unsettled. These are dated release observations. The current model documentation lists supported providers and explains the current selection flow.
The toolset discussion is more structural. Letta can switch the editing and shell tools presented to the model when the model family changes. Current documentation gives the same example raised in the episode: GPT-family coding models are trained around patch-style editing, while Claude-family models tend to work better with string-based edits. The harness performs the switch, though the Q&A notes an open design question about how much model-native tool specialization newer models still require.
Cloud sandboxes provide an isolated filesystem and shell. The agent's identity, conversations, and memory remain outside that computer. Cameron acknowledged recent reliability problems and described future configuration and pricing as unsettled. Those comments describe the August 27 state, not a current service guarantee.
The channels discussion distinguishes a messaging adapter from a hosted service. A local Telegram, Discord, WhatsApp, Signal, or Slack listener must remain online to receive and route messages. Native hosted Slack removes that operator burden. Cameron said Letta planned a similar hosted Telegram connection so users would not need Railway or another always-on server for the listener. The current channels documentation should decide which platforms are hosted now.
One context agent across several harnesses
Cameron separately previews an unreleased cross-harness rewrite of Claude Subconscious. The existing demo lets a Letta agent watch Claude Code transcripts and send relevant context back into the coding session. This rewrite is distinct from the history-import and memory feature mentioned a few minutes earlier. It removes the Claude-only assumption: one Letta agent would observe separate conversations from Claude Code, Codex, OpenCode, Letta Code, and other harnesses, then send context to whichever worker needs it.
Trajectory supplies the normalization layer for that idea. Coding-agent runtimes record messages, reasoning, tool calls, and results in incompatible native formats. Trajectory converts supported formats into a shared record structure for analysis, evaluation, training, search, or memory formation.
Normalization makes the records comparable. It does not make the harnesses equivalent. Each worker still has its own tools, environment, permissions, and current task. A cross-harness context agent therefore needs to know both what happened and which runtime had authority to do it. The public agent trajectory observability guide develops that distinction further.
Misaligned shows how design drift accumulates
The Q&A uses Cameron's game project Misaligned as a concrete failure case for agent-heavy development. He says agents built too much before he had a good way to observe and judge their work. The game accumulated mechanics, became difficult to understand, and drifted away from the experience he wanted.
His response was a large simplification rather than incremental cleanup. The revised design centers on territory control, computers, and network switches. The discarded work still had informational value because building it exposed the smaller set of mechanics worth keeping.
The episode's criticism of spec-driven development is specific. Specifications did not fail merely because agents wrote the code. Cameron had stopped attending closely enough to the specs and to the rendered game. A repository can contain elaborate design documents while the implementation becomes incoherent. The written specification and the experience of playing the game are both evidence, and neither substitutes for the other.
A software factory starts before implementation
Cameron defines a software factory as a set of processes that orchestrates agents to improve software toward a measurable goal. His example begins when a user submits feedback, not when a coding agent opens a pull request.
Synthesizing Cameron's example and later discussion, such a factory could:
- capture the report with relevant version and runtime context;
- match it to an existing issue or create a new one;
- reproduce the behavior at a named commit;
- localize the likely subsystem and collect evidence;
- let a human confirm the intended product behavior and architecture;
- implement the change and add a regression test;
- run continuous integration and automated review;
- present a bounded architectural decision to a human reviewer.
Letta's earlier experiment skipped too much of that sequence. A rule sent every bug directly to an implementation agent. Roughly 70 pull requests arrived within days. Cameron says many followed weak solution suggestions from support tickets, missed architectural context, and relied on poor tests or mocks. Reviewing them cost more than interactive agent-assisted development would have cost.
The revised factory focuses first on reproduction. An agent should establish the affected commit, reproduce the behavior, record what happened, and identify the likely code path. A human can then correct the intended behavior before the implementation agent starts. This removes expensive ambiguity while preserving the part of engineering where product knowledge and architectural judgment remain decisive.
Continuous integration provides a machine-readable outcome, but only for encoded requirements. Cameron's advice is blunt: write good tests. A regression test turns one observed failure into a retained contract. Weak tests can still reward the wrong implementation, and a green build cannot decide whether the architecture should exist. The factory needs both executable checks and people who use the product.
Ownership and money extend the same delegation problem
An audience question asks whether software remains a human project when agents write most of its code. Cameron's current answer rests on legal and economic responsibility: people and companies own the repositories, bear the liability, direct the work, and receive its returns. He leaves open a future in which autonomous organizations own assets and agents transact more independently.
The next discussion makes that future concrete. Cameron is interested in agents buying ordinary goods within a small allowance, but advises against giving an agent meaningful control over an investment portfolio. He tentatively suggests a limited, stoppable virtual card rather than unrestricted card credentials.
Agent-to-agent communication needs the same visibility. Cameron prefers existing human communication systems such as Slack or Telegram when they can expose the thread, participants, history, and result to the person delegating the work. A hidden agent protocol may move messages efficiently while making supervision harder.
The software factory and the shopping agent therefore share one operational shape. A person delegates a bounded task through an inspectable channel. The system limits what can be spent or changed, and a receipt shows what happened. The public agent authority and effects guide covers the general form.
Architectural synthesis
The episode's central shift is from prompt automation to process design. A prompt can tell an agent to fix a bug. A factory defines which report may enter, what evidence must exist before implementation, which procedure the agent loads, where code runs, what tests judge, and which decisions remain human.
In the demonstrated workflow, Linear tracks and dispatches work. Letta preserves the agent and runs it in a sandbox. Shared skills carry team procedure, and continuous integration tests encoded requirements. People decide product intent and architecture.
Adding more agents helps only after those contracts become legible. Without them, the factory converts tokens into a larger queue.
Evidence limits
- The episode and supplied transcript are the primary record. The transcript contains automatic-caption errors, including repeated transcription of “Letta” as “Letter” or “Leda.”
- Product demonstrations describe the recorded build and account configuration. They do not establish universal availability or later behavior.
- Linear integration, hosted Telegram, model routing, sandbox pricing, and cross-harness Subconscious plans are dated to August 27, 2026 unless current documentation is cited.
- The software-factory account is Cameron's description of Letta's internal experiments. It is not a controlled comparison of development methods.
- The architectural synthesis is Co's interpretation of the episode and public sources.