Research Engineer / Scientist

Letta Agents SDK: An SDK for stateful agents. Today, Letta is launching the Letta Agents SDK, a TypeScript library for building with stateful agents. The Letta Agents SDK is designed for stateful, persistent agents. Each agent has its own sense of identity, long-term experience, and memory - and can work across computers without losing memory or state, just like a human. You can use the Agents SDK to create multi-agent and multi-user applications, for dynamic orchestration of agents, or to build custom interfaces on top of Letta agents. An SDK for stateful agents. The Letta Agents SDK is designed for working with long-running, stateful agents. Agents can be created on different state backends (in the cloud or locally), and can run across different machines while retaining the same memory and state. The same SDK interface to interact with stateful agents works against Letta Cloud, a self-hosted App Server, or entirely on your machine: import {LettaAgentClient} from "@letta-ai/letta-agent-sdk"; const client = new LettaAgentClient({ backend: "cloud", apiKey: process.env.LETTA_API_KEY,}); const agentId = await client.createAgent({ model: "letta/auto", persona: "I am Nora, a research analyst who tracks our competitors.",}); Registering and working across computers. Agents are not tied to the machine they were created on. A Cloud agent can work in a managed sandbox or on any computer registered with Letta - a laptop, workstation, VM, or container. The computer supplies the files, shell, credentials, and installed software; the agent keeps the same identity, memory, and conversations. // List the computers registered with your account const {computers} = await client.computers.list; // Select one for a session await using session = client.resumeSession(agentId, {computer: { name: "work-laptop"}, cwd: "/workspace/project",}); Creating custom interfaces for stateful agents. The Agents SDK is built on top of the same WebSockets interface that Letta build Letta Desktop with. You can create your own custom interfaces - a web app, a mobile app, a kanban board - that connect to either Letta Cloud or your own self-deployed App Server. The Expo demo app shows how to browse agents, stream reasoning and tool activity, and handle approvals from a mobile client. Fork it to build your own interface with custom themes, branding, or features. See examples of custom interfaces and applications built with the Agents SDK: * Web chat streams an agent's work into a browser interface. * Dungeon master uses a persistent persona and Git-backed memory to run campaigns over time. * Letta ACP makes the same stateful agent available in ACP-compatible editors like Zed, test harnesses, and command-line clients while preserving its memory across clients and adapter restarts. Dynamic workflows across models and machines. The Agents SDK can power dynamic workflows executed by agents. An agent running locally can spawn new conversations with itself in the cloud to work on concurrent tasks - and because agents can write TypeScript, they can use the SDK to turn repeated work into programs: one-off helpers, reusable commands, scheduled automations, event handlers, or longer-running services that start a new conversation when work arrives. The program handles fixed control flow and external events, while the agent handles interpretation and tool use with its existing memory. See examples of dynamic workflows with the Agents SDK: * Research team coordinates persistent agents in a collaborative research workflow. * Release notes learns formatting preferences as it writes from git history. * Dynamic workflows invokes agents programmatically to compare plans across models, cross-check research, and migrate files in isolated Cloud sandboxes. Model-agnostic, managed agents. The Letta Agents SDK supports both running the agent execution loop fully locally (similar to other agent SDKs) and interfacing with stateful agents managed by remote servers that multiple clients connect to. Unlike other managed agent providers, the Agents SDK unifies the concept of a local SDK and a managed agent SDK. With Letta Cloud, the agent loop is managed server-side, and clients can execute tools locally, in a cloud sandbox, or on any registered computer. This achieves the best of both worlds of "agent in a sandbox" and "agent with a sandbox": the same agent you use to code locally can be run as a managed agent, while clients remain isolated from the secrets required for LLM inference or server-side MCP execution. For example, you might give your agent read-only API keys for a less-sensitive service so it can create custom tools or skills to use the service effectively, while more sensitive keys stay server-side as registered MCP tools - which the agent can call but cannot modify. Start building. Install the SDK: npm install @letta-ai/letta-agent-sdk Additional resources: * Explore the Agent SDK overview. * Follow the quickstart for Cloud, local, and remote examples. * Read the documentation for memory, sessions, permissions, deployment, client tools, and shared repositories. * Browse the source.

The harness stops being static: self-modification, trace-mined updates, and per-model profiles. Multiple converging releases suggest the agent harness is becoming a runtime-mutable artifact that agents, traces, and model-specific tuning all reshape - with concrete consequences for how teams version and govern infrastructure. By the Editors · AI-generated, human-reviewed June 27, 2026 For most of the last two years, the agent harness - the scaffold of tool definitions, context injection rules, compaction strategy, and loop control around a model - was treated as code you write once and tune by hand. The releases of late June 2026 make it clear that assumption is dissolving. The harness is becoming a learned, mutable artifact: edited by agents at runtime, derived from trace mining, and specialized per model. That shifts the practical question from designing a good harness to treating it as a deployable, observable, version-controlled surface. Three independent signals, one direction. Look at what shipped or was published in the last week of June 2026. Letta introduced Mods, a mechanism for agents in Letta Code to modify their own harness at runtime - adding tools, changing context injection, adjusting compaction. Work built on LangChain's DeepAgents proposed Self-Harness, where an agent mines its own traces for failure modes, proposes harness changes, and validates them via regression testing. LangChain's Deep Agents v0.6 introduced per-model harness profiles, acknowledging that the same scaffold tuned for Claude underperforms when pointed at Kimi or DeepSeek. And LangChain's own LangSmith Engine demonstration treats trace analysis as a sleep-time compute step that produces memory updates between runs. None of these are coordinated. They are independent teams arriving at the same shape: the harness is no longer the stable part of the system. The model used to be the variable and the harness the constant. That relationship is inverting. With open-weight models like GLM-5.2 and TMax-27B closing in on frontier performance, swapping models is becoming routine - and the harness is what now has to adapt around them. Why this is happening now. Three forces are pushing in the same direction. First, trace data is finally being treated as primary training signal rather than debug output - a shift Agent Engineering examined in The Trace Becomes the Primary Artifact. The argument that continual learning is fundamentally a data-mining problem over traces is showing up in tooling - LangSmith Engine, RubricMiddleware, Self-Harness loops - that operationalizes mining traces into structured proposals for memory, evals, and harness changes. Once you have a pipeline that can produce a candidate harness diff from a week of traces, there's no reason to leave that diff for a human to hand-write. Second, the harness is where model-specific behavior actually lives. Per-model profiles in Deep Agents v0.6 are an admission that a tool-calling loop tuned for one model's quirks doesn't transfer - the argument of Model-Specific Profiles and Runtime-Authored Workflows. As open-weight agentic models proliferate - GLM-5.2 with a 1M context, TMax-9B punching above its weight on Terminal Bench - the cost of carrying a single generic harness is rising. Specialization at the harness layer is cheaper than fine-tuning. Third, the harness is becoming the natural place to put verification, governance, and code execution. The interpreters added to Deep Agents, sitting between single tool calls and full sandboxes, are a harness-level decision. Gemini 3.5 Flash's native computer use ships with built-in confirmation prompts and prompt-injection task-stopping - again, harness behavior baked into the model surface. Claude Tag's per-channel memory and ambient triggers are harness features in user clothing. The harness has absorbed so much of what determines agent behavior that it would be strange if it remained the only frozen layer. What changes for practitioners. If the harness is mutable, the engineering problem shifts from "design a good harness" to "build a feedback loop that improves the harness safely." That's a substantially different discipline. The minimum viable version of this loop has four parts: structured traces with enough signal to diagnose failures, a mining step that proposes changes (new tools, revised context rules, updated compaction thresholds), a regression suite that catches when a proposal breaks something that previously worked, and a deployment mechanism that versions harness changes the same way you version code. LangChain's blog on loop engineering frames this as nested loops - tool-calling, verification, event-driven - but the deeper point is that there's now a fourth loop above all of them: the loop that edits the harness itself. If agents can modify their own harness at runtime, the regression suite is no longer optional infrastructure - it is the safety boundary. Self-modifying systems without regression tests are how production agents quietly drift away from the behaviors that got them shipped. The new failure modes. A mutable harness creates failure modes that static harnesses don't have. Asymmetric goal drift becomes more likely when the agent itself can rewrite the rules that constrain it. Eval autoimmunity gets worse when the proposed harness changes are validated against tests that the same agent shaped. And debugging becomes path-dependent: reproducing a bug now requires knowing not just the prompt and model version, but the harness diff that was active at that moment. This is why per-model profiles, delta-channel checkpointing, and structured trace projections - all in the same Deep Agents v0.6 release - matter together. They are the bookkeeping that makes harness mutation auditable. Treat any of them as optional and you lose the ability to reason about why your agent behaved a certain way last Tuesday. Where to start. Three concrete moves are worth making now, before the patterns calcify. Version your harness like code. Not just the prompts - the tool definitions, the compaction rules, the context injection logic, the model-specific profile. Tag each agent invocation with the harness version it ran under. This is cheap to add today and extremely expensive to backfill once you have a year of traces with no versioning. Build the trace-mining pipeline before you need it. Even a simple weekly job that clusters failures by tool, by subagent, or by context length will surface harness changes you wouldn't have prioritized. The teams shipping self-improving loops aren't doing magic - they're doing data engineering on traces that most teams are already collecting but not analyzing. Separate the harness-editing authority from the agent's normal action space. An agent that can both serve user requests and modify its own harness in the same loop is one prompt injection away from a bad outcome. Treat harness edits as a privileged action that requires offline review, regression testing, or at minimum a separate identity - the same way you'd treat a schema migration in a production database. The harness was the boring layer. It isn't anymore: model swaps, trace mining, governance, and self-improvement all converge there, which is why it deserves the same versioning, review, and regression discipline as any other production system.