You're on Letta: Give Long-Running Data Agents Governed Context and a Safe Way to Change Data
Building long-running data agents on Letta? Register Data Workers as an MCP server so they read governed definitions, lineage and owners, and change data through approvals.
Your team builds agents that stay. On Letta, an agent is a persistent identity with its own memory, model settings, tools and message history. Its long-term memory lives in MemFS, a git-backed memory filesystem, and dreaming runs background subagents that consolidate what it learned. The agent runs on schedules, loads skills, answers in Slack and keeps the same memory across the Letta app, the CLI and the Agent SDK, on Letta Cloud or a local backend you host. Some now work on data, like a RevOps analyst that posts the morning bookings briefing. Letta is where your agents' memory lives. Data Context Wizard is where every agent reads the data estate's governed context, next to lineage, quality and usage, with a named owner on every fact.
That split matters the first morning a long-running agent reports a number that broke overnight. Data Workers is the agentic data platform that holds that context and does that work. Registered as MCP servers in your Letta agent's session, it gives the agent governed definitions, lineage, owners and quality before it answers, and it routes any change the agent asks for through a named approver, a reversible change and a receipt.
Key takeaways
- •Letta keeps its job. Stateful agents, MemFS, dreaming, schedules, skills, subagents and your permission modes stay as they are. Data Workers joins as MCP servers in the agent's session.
- •Two kinds of memory, one answer. The agent remembers what it learned in MemFS, and Data Workers never writes there. Data Context Wizard holds what the business agreed about its data: definitions, lineage, owners and quality, with provenance on every fact.
- •Agents ask, owners approve. A Letta agent never needs warehouse write credentials. Your Letta host approves the tool call, the model owner approves the change in Spellbook, and every change is reversible with a receipt.
- •Start with a pilot. One long-running agent, read tools first, then one fix class in one domain, on the ladder from L0 manual to L4 autonomous.
Letta holds the agent's memory. Data Workers holds the data estate's context and does the data work.
Letta built a runtime for agents that learn: the Letta agent harness (also called Letta Code) drives the agent, connects models to persisted context, manages turns and executes tools. Memory follows the agent across conversations, models and computers, and the agent edits it as it learns. That is the right home for what one agent knows about its users and its job.
The data estate is a different body of knowledge that many people and agents depend on. "Bookings" has one approved definition, a dbt model, a Fivetran sync and a Salesforce field upstream, a quality score and an owner. Data Context Wizard keeps that context across every platform and serves the same governed view to a Letta agent, a coding agent and an analyst alike.
Here is a Tuesday morning with both connected. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 01:50 | Salesforce | Sales ops splits the Closed Won opportunity stage into Closed Won - New and Closed Won - Expansion |
| 03:00 | Fivetran | The sync lands the updated opportunities in Snowflake |
| 04:15 | Airflow + dbt | The nightly DAG run succeeds; fct_bookings filters on the old stage value, so new deals drop out, and its tests pass |
| 04:40 | Data Workers | The volume check on fct_bookings fails at 38% below the trailing four-week same-weekday level; Data Workers traces lineage to the Salesforce stage change and opens an incident with the owner |
| 07:00 | Letta | The RevOps agent's daily schedule fires. Before drafting, it calls explain_table on fct_bookings over MCP for the definition and owner, then get_incident_history for the last 24 hours, which returns the open incident from 04:40 |
| 07:02 | Slack | The agent posts the briefing with pipeline and win rates, and holds bookings with a note: under repair, incident linked |
| 07:05 | Data Workers | The agent asks for the fix; the Letta host approves the tool call; Data Workers proposes a dbt diff that maps both new stage values, with its blast radius: three models and one Looker Explore |
| 08:30 | Spellbook | The analytics engineer who owns fct_bookings reviews the diff and approves; dbt CI passes |
| 08:40 | Airflow | Data Workers reruns the DAG for the affected partitions |
| 09:00 | Snowflake | Data Workers re-runs its checks, confirms bookings are back on their monitor_metrics baseline and writes the receipt |
| 09:05 | Slack | The agent posts the corrected bookings number with the receipt, and records in its own memory that Closed Won is now two stage values |
Letta did its job well: the agent ran on time, checked before it spoke and kept the team informed. Data Workers was already on the break at 04:40, and the fix went through two approvals, one in your Letta host and one from the model's owner, before anything changed.
| Job | What Letta does | What Data Workers does |
|---|---|---|
| The agent | Keeps a persistent identity with memory, model settings, tools and conversations | Gives that agent governed tools for the data estate over MCP |
| The memory | Stores what the agent learned in MemFS and consolidates it with dreaming | Stores what the business agreed about its data, with provenance and a named owner |
| The routine | Runs schedules, subagents and skills | Watches the tables the routine depends on and flags breaks before it runs |
| The question | Reasons over memory and tool results to answer | Supplies the definition, lineage, quality score and freshness behind the number |
| The tool call | Applies permission modes and lets your host approve, deny or edit each call | Proposes the change with its blast radius and routes it to the owner |
| The fix | Never needs warehouse write credentials in this pattern | Lands the change in dbt and the orchestrator, reversibly, after approval |
| The proof | Streams every tool call and result | Verifies the result and writes a receipt with cause, diff, approver and rollback |
Why doesn't Letta just do this itself?
Because Letta built the best place for an agent to own its context. Its design puts the agent in charge of its own memory and gives developers sharp controls over each tool call: permission modes from unrestricted to strict, allow and deny rules, a cross-agent memory guard, and in the Agent SDK a canUseTool callback that can approve, deny or edit any call. That is the right boundary for a general-purpose harness that runs coding agents, personal assistants and AI coworkers alike, with a lean base toolset extended by skills.
Deciding which of five systems' definitions of bookings is right, scoring a table's trust from quality, freshness, usage and ownership, routing a conflict to its owner, and changing production data with a blast radius, rollback and a receipt is a different product with a different liability. Those changes land in Salesforce mappings, dbt models and Airflow DAGs that Letta doesn't run and shouldn't have to know.
Letta makes the agent stateful. Data Workers makes the data it works on governed and safe to change.
Every tool owns a slice. Data Workers covers the whole lifecycle
Letta owns one slice of the stack outright: stateful agents that remember and learn. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the agents you already run on Letta.
| Stage | Data Workers | Letta | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 9.5 | Letta's home stage: every agent keeps its own long-term memory in MemFS, a git-backed context repository, with memory blocks in context every turn and dreaming to consolidate what it learned. Data Workers adds governed facts about the data estate next to it, with lineage, quality, usage and a named owner. |
| Analytics & Insights | 8 | 5 | Letta agents run code and shell commands, so they can query and analyze data through skills; Letta is not a metrics engine. Data Workers' Insights agent answers through governed metric definitions. |
| Data Quality | 8 | 3 | Letta keeps memory tidy with dreaming and memory upkeep inside the agent. Data Workers checks the tables and definitions the agent works from and repairs the breaks. |
| Observability & Incidents | 8.5 | 3 | The harness streams every tool call and result, so you see what the agent did. Data Workers detects a broken table or a changed definition, traces it across systems and fixes it. |
| Pipelines & Ingestion | 8.5 | 5 | Schedules, subagents and code execution let an agent run recurring jobs and write scripts. Data Workers builds, reruns and backfills the data pipelines themselves with approvals. |
| Schema & Migration | 8 | 2 | Letta has no view of warehouse schemas by design. Data Workers catches upstream schema changes in the dbt manifest and in review and assesses their impact. |
| Governance & Access | 8.5 | 6 | Organization roles, private-by-default agents and conversations, permission modes and allow and deny rules govern the agent. Data Workers proposes and applies grants across your data platforms by policy. |
| Security & Privacy | 8 | 6 | Secrets storage, credential redaction in tool output, a cross-agent memory guard and a local backend that keeps state on your own infrastructure. Data Workers flags sensitive column names in pull request review and proposes masking for the owner. |
| Cost / FinOps | 8 | 2 | Letta bills its own usage and lets you bring your own model keys. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 8 | Letta's other home stage: model-agnostic agents that keep one identity and memory across providers and models, and improve with use through memory and skills. Data Workers keeps the data under your models healthy and connects to MLflow and W&B. |
How Letta and Data Workers work together
Your agents stay on Letta, in the app, the CLI, Slack or your own product. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, its blast radius, who approved it and how to roll it back. Between them, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.
Two memories with two owners. The Letta agent's memory is its own, and Data Workers never writes into it. Context Wizard holds the facts many agents share, such as the approved definition of bookings and its owner, with provenance on every one. Facts the agent proposes back, such as the new stage split, wait for a named owner before they become authoritative. For the pattern across semantic layers, ontologies and memory products, see the hub, bring your own context.
Setup over MCP today. In the Letta Agent SDK, you pass MCP servers by name when you create or resume a session (stdio, Streamable HTTP or legacy SSE); the connections run in your application's Node.js process and each tool is namespaced mcp__<server>__<tool>. Data Workers' agents are MCP servers from the open-source repository: clone it and point each server at start-agent.sh, as the client setup docs show. Use permissionMode: "strict", where nothing is auto-approved, so your canUseTool callback decides every call: allow the read tools, and send anything else to a person.
// Example: a Letta Agent SDK session with Data Workers registered as MCP servers
import { LettaAgentClient } from "@letta-ai/letta-agent-sdk";
const DW = "/path/to/dataworkers-claw-community/start-agent.sh";
const READ_TOOLS = new Set([
"mcp__dw-context-catalog__explain_table",
"mcp__dw-context-catalog__trace_cross_platform_lineage",
"mcp__dw-context-catalog__resolve_metric",
"mcp__dw-context-catalog__search_across_platforms",
"mcp__dw-quality__run_quality_check",
"mcp__dw-quality__get_quality_score",
"mcp__dw-schema__assess_impact",
"mcp__dw-incidents__get_incident_history",
]);
const client = new LettaAgentClient({ backend: "cloud", apiKey: process.env.LETTA_API_KEY });
await using session = client.resumeSession("agent-revops", {
mcpServers: {
"dw-context-catalog": { command: DW, args: ["dw-context-catalog"] },
"dw-quality": { command: DW, args: ["dw-quality"] },
"dw-schema": { command: DW, args: ["dw-schema"] },
"dw-incidents": { command: DW, args: ["dw-incidents"] },
},
permissionMode: "strict",
canUseTool: async (toolName) =>
READ_TOOLS.has(toolName)
? { behavior: "allow" }
: await askOnCallEngineer(toolName), // your app's approval prompt
});The stdio servers run on the SDK host, which needs the cloned repository and Data Workers' read credentials in environment variables or a secret manager. To reach a central deployment instead, point the session at the Data Workers product endpoint over Streamable HTTP: { type: "http", url: "https://<your-data-workers-host>/mcp", headers: { Authorization: "Bearer <key>" } }. That endpoint takes an API key as a bearer token, or OAuth through your own identity provider, such as Okta or Microsoft Entra ID, with Data Workers verifying each token against your provider's published keys; your host application completes the sign-in and passes the access token, as Letta's docs describe. In the Letta app and CLI, Letta recommends skills over MCP, and a skill can call the same Data Workers servers through a bundled script. Registering servers through the Letta API (client.mcp_servers.create) is still documented, marked legacy.
Where writes go. Fixes land where your team already reviews change: a dbt diff for the owner to merge, an Airflow rerun of the affected partitions, a mapping change to the ingestion job. The agent asks, Data Workers proposes, your Letta host and the owner approve, and Data Workers applies the change reversibly, verifies it and keeps the receipt. If you are weighing building this layer yourself, read build it ourselves with Claude Code and MCP servers: the connection is the easy part; cross-system context, approvals and rollback are where the work is.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Data Workers is connected but not acting. Your engineer checks the tables behind the briefing by hand.
- •L1 observe. Data Workers watches the tables the agent depends on, flags breaks before the schedule fires and gives the agent the cause and owner. Nothing changes.
- •L2 propose. When the agent asks for a fix, Data Workers drafts the dbt diff or the rerun with its blast radius. The owner approves in Spellbook.
- •L3 act reversibly. For change classes with a proven record, such as rerunning a failed load, Data Workers applies the change, verifies it and can roll it back.
- •L4 autonomous. For a scoped, trusted class like late syncs feeding one briefing, Data Workers fixes and verifies on its own and posts the receipt.
For the safety model behind each step, read is it safe to let AI agents change production data, and for where data and credentials live, where does our data go. Teams pairing a memory layer with their agents will find the same pattern in our guides for Mem0 and Zep, with background in persistent memory layers for agents and memory pipelines for data agents.
What changes for your team
Teams building on Letta spend real time on work that isn't agent work: checking last night's tables before a briefing goes out, handing out warehouse credentials, explaining why an agent said what it said. With Data Workers next to Letta, those jobs run on autopilot at the level you set.
- •Incidents. A broken source is caught, traced and fixed before a scheduled agent reports the number.
- •Data quality. Every table an agent relies on carries a quality score and an incident history the agent reads before it answers.
- •Cloud spend. Cleanups of scratch tables and extracts agents created for one-off analyses are proposed to the owner after a dependency check.
- •Access. An agent's request for new data arrives as a time-boxed grant proposal for its owner, instead of a broader service account.
- •Audits. Every data change an agent asked for carries an approver, a diff, the verification and a rollback path.
- •Migrations. When the warehouse under your agents moves, tables move in parity-checked waves while the agents keep reading.
The agent team gets its week back for the agents themselves.
Keep Letta, or consolidate?
Keep Letta if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most teams, the answer is to keep it: stateful agents and their memory belong on Letta. What teams consolidate is the tooling around their data agents: a homegrown freshness check in a skill, a write-capable service account the agent never needed, a spreadsheet of which table backs which metric, a separate data-quality tool. Data Workers runs those jobs with one context, one approval flow and one audit trail, for every agent on Letta and every other agent in the company.
The case for your CFO
The outcome: the agents the company invested in can be trusted with numbers. A RevOps or finance agent that runs every morning is only as useful as the tables under it, and Data Workers keeps those tables right and the definitions consistent.
The risk story is plain. Letta agents never hold warehouse write credentials. Every change an agent asks for shows its blast radius, passes your Letta host's approval and a named owner's in Spellbook, lands through the pipelines your team already runs, is verified and leaves a receipt: who approved it, what it touched and how to undo it. Autonomy is set per domain from L0 manual to L4 autonomous and can be dialled back at any time. There is zero migration: Letta, the warehouse, dbt and Airflow stay where they are.
Why now: long-running agents act on their own schedule, so a bad table reaches a briefing or a customer before anyone looks. The first win is one agent with its tables watched, read-only, so the next upstream change is held and fixed before the agent reports it. What stays the same: your agents, their memory, your Letta plan, your warehouse permissions and your review process. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Our agents remember how to do the job; Data Workers makes sure the data they use is right, and every change they ask for has an approver and a receipt."
Getting started
Start with a pilot. Pick one long-running Letta agent that already works on data, such as the morning bookings briefing, register Data Workers' read tools in its session, and let Data Workers watch the tables behind it for a few weeks before enabling the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers write to our Letta agents' memory? No. Each Letta agent owns its memory in MemFS. Data Workers serves governed facts through its tools; the agent decides what to remember. Facts it proposes back to Context Wizard wait for a named owner.
Which Letta surface do we use to connect Data Workers? The Letta Agent SDK, which takes MCP servers per session over stdio, Streamable HTTP or SSE. In the Letta app and CLI, Letta recommends skills, and a skill can call the same servers. Registration through the Letta API is still documented, marked legacy.
Do our agents need warehouse credentials? No. Read tools use the credentials Data Workers is configured with, and changes go through Data Workers' approvals into dbt or the orchestrator, so the agent never holds a write-capable service account.
How do approvals work with Letta's permission modes? They stack. Letta's strict mode with a canUseTool callback lets your app decide each tool call. Data Workers then routes the change itself to the owner of the model or table in Spellbook, with its blast radius and rollback path.
What happens when the agent's memory disagrees with the governed definition? The agent reads the governed definition from Data Workers each time it answers, so a stale memory doesn't decide the number. When two systems disagree, Context Wizard routes the conflict to a named owner and shows both candidates until they decide.
Sources
- •Letta, Letta documentation index (llms.txt), https://docs.letta.com/llms.txt (checked Oct 2, 2026)
- •Letta, Terminology (Letta agent harness, Letta Code, Letta Cloud, Letta API), https://docs.letta.com/reference/terminology/ (checked Oct 2, 2026)
- •Letta, Stateful agents, https://docs.letta.com/concepts/stateful-agents/ (checked Oct 2, 2026)
- •Letta, MemFS, https://docs.letta.com/concepts/memfs/ (checked Oct 2, 2026)
- •Letta, Agent SDK memory and dreaming, https://docs.letta.com/agent-sdk/memory/ (checked Oct 2, 2026)
- •Letta, MCP and client tools (Agent SDK), https://docs.letta.com/agent-sdk/mcp/ (checked Oct 2, 2026)
- •Letta, MCP tools (legacy Letta API registration), https://docs.letta.com/v1-sdk/tools/mcp-tools/ (checked Oct 2, 2026)
- •Letta, Agent SDK permissions, https://docs.letta.com/agent-sdk/permissions/ (checked Oct 2, 2026)
- •Letta, Agent SDK reference (session options: mcpServers, permissionMode, canUseTool), https://docs.letta.com/agent-sdk/reference/ (checked Oct 2, 2026)
- •Letta, Permissions (permission modes, cross-agent memory guard), https://docs.letta.com/configuration/permissions/ (checked Oct 2, 2026)
- •Letta, Configuring team permissions, https://docs.letta.com/teams/permissions/ (checked Oct 2, 2026)
- •Letta, Skills, https://docs.letta.com/configuration/skills/ (checked Oct 2, 2026)
- •Letta, Schedules, https://docs.letta.com/configuration/schedules/ (checked Oct 2, 2026)
- •Letta, Frequently asked questions (skills, MCP and mods), https://docs.letta.com/reference/faq/ (checked Oct 2, 2026)
- •Letta, letta-code releases (v0.34.2, Oct 2, 2026), https://github.com/letta-ai/letta-code/releases (checked Oct 2, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
- •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)