You're on Zep: Keep the Facts Your Agents Remember About Data as True as the Warehouse
Already on Zep? Data Workers keeps the facts your agents remember about data in step with the warehouse, with owner approval, provenance and receipts.
Your agents run on Zep. Each user has a user graph, each account and domain a shared Context Graph addressed by graph_id, and the Context Lake serves them on Konig, Zep's graph database service. CRM records, tickets, playbooks and warehouse extracts arrive as episodes through graph.add or a nightly zep-ingest job; Zep extracts facts, stamps them with valid_at and invalid_at, and can invalidate an old fact when newer data contradicts it. Agents pull a Context Block each turn, and through the Memory MCP Server your people reach the same memory from Claude, ChatGPT, Cursor or Codex with single sign-on. Zep calls itself "the unified context layer for enterprise data": business data, documents and conversations combined into shared, governed context for agents. Under the managed service runs Graphiti, Zep's open-source framework for temporal knowledge graphs.
Some of those facts are about data: how a metric is defined, which table a number comes from, what score counts as "at risk". They change when the warehouse changes, and a dbt pull request is not an episode. Zep is the context layer your agents read from. Data Workers is the agentic data platform that keeps the data estate and its meaning right, and acts on it: Data Context Wizard holds governed, owner-approved facts about the data, flags the remembered facts a warehouse change made stale, and hands the approved replacement to the ingestion path that already feeds Zep.
Key takeaways
- •Zep keeps its job. Context Graphs, Context Blocks, the Memory MCP Server and your ingestion jobs stay as they are; Data Workers works next to them from day one.
- •Data facts get an owner. Data Context Wizard holds facts about your data estate, each with its source, lineage, quality, usage and the named owner who approved it.
- •Stale remembered facts get caught. When a dbt change or a new definition makes a fact in a Context Graph wrong, Data Workers finds it and routes the fix before an agent repeats it.
- •Zep's temporal model does the rest. Approved facts enter Zep through your own
graph.addcall or ingestion job, Zep retires the old fact and keeps its history, and once the owner's assistant confirms the result, Data Workers writes a receipt. - •Start with a pilot. One shared Context Graph that describes data, read-only, then one fix class, on the ladder from L0 manual to L4 autonomous.
Zep is the context layer for your agents. Data Workers is the agentic data platform that keeps the data and its meaning right.
Zep is built for context that changes. Facts live on edges with four timestamps (learned, became true, stopped being true, learned that it stopped), source traceability ties each fact to its episodes, and ABAC and content policies decide who reaches a graph and what may enter it. When a customer says they switched plans, Zep can invalidate the old fact and keep the timeline. That is the right design for context about people, accounts and work.
Facts about data have a different source of truth. "Below 40 means at risk" is true only while the health score in dim_account runs from 0 to 100. When a dbt change rescales it, the fact is wrong, and no episode says so. Data Workers watches that side: the warehouse, the dbt project, the definitions and their owners.
Here is an afternoon with Data Workers next to a customer success team on Zep. This is an illustration, not a customer case; every name and number in the table is illustrative.
| Time | System | What happens |
|---|---|---|
| 15:30 | GitHub | The CS analytics team merges a dbt pull request that moves dim_account.health_score from a 0 to 100 scale to a 0 to 10 scale |
| 16:00 | dbt Cloud | The production job builds dim_account; its tests pass, because every score is present and in range for the new scale |
| 16:05 | Snowflake | Data Workers flags the change: the value check on health_score fails, with the median moving from 74 to 7.4, and the new definition is recorded with its owner |
| 16:10 | Zep | The agent owner's assistant searches the shared cs-playbooks Context Graph over the Memory MCP Server and hands Data Workers a valid fact from a playbook episode: "an account with a health score below 40 is at risk" |
| 16:20 | Spellbook | Data Workers routes the item to the account agent's owner ahead of the 02:00 sync: the stale fact, its source episode, the new definition, the replacement fact and the blast radius (in this illustration: one shared graph, the 2,300 account graphs the nightly sync feeds, one agent) |
| 17:05 | Spellbook | The CS operations lead approves the replacement: "since Oct 2, health score runs 0 to 10; below 4 means at risk" |
| 17:10 | Ingest service | The team's own service adds the approved fact with graph.add, with source and approval ID as episode metadata; Zep invalidates the old threshold and keeps its history |
| 02:00 | zep-ingest | The nightly account sync, a recurring zep-ingest import, sends scores on the new scale |
| 02:40 | Zep | The owner's assistant re-reads the graph over the Memory MCP Server: the old fact carries an invalid_at and the new one is valid. Data Workers confirms no account is flagged at risk by the old rule and writes the receipt |
| 09:15 | Account agent | A CSM asks which accounts are at risk before this week's business reviews; the list is right |
Without that check, the 02:00 sync would have sent a 7.4 for a healthy account while the playbook still said below 40 is at risk, and the agent would have flagged almost every customer. Zep did what it was built to do. The change happened in the warehouse, and the fix needed an owner who knew what the new scale meant.
| Job | What Zep does | What Data Workers does |
|---|---|---|
| The context | Builds temporal Context Graphs for users, accounts and domains from business data, documents and conversations | Holds governed facts about the data estate: definitions, tables, lineage, quality and owners |
| The timeline | Can invalidate a fact when newer data contradicts it, and keeps the history | Notices when a warehouse change makes a remembered fact about data wrong, even when no new episode arrives |
| The source | Traces each fact to the episodes it came from | Traces each data fact to the dbt model, column and source system it rests on, and to the person who approved it |
| The break | Ingests what it is sent | Detects the upstream change, traces it across GitHub, dbt and Snowflake to the Context Graphs that depend on it |
| The fix | Accepts new facts through graph.add, zep-ingest or add_memory_to_graph | Proposes the replacement fact with its blast radius, routes it to a named owner and hands the approved fact to your ingestion job |
| The proof | Holds the new fact and the invalidated one, with dates | Re-reads the graph, confirms the old fact is retired and writes a receipt with the cause, approver and rollback |
| Access | Limits which agents and users reach which graphs with ABAC policies | Proposes and applies grants on the warehouse tables those agents query, by policy |
Why doesn't Zep just do this itself?
Because Zep built a context layer for any agent and any domain, and its docs draw the line of its job clearly. Source traceability "records where information came from. It does not establish that the source content or a derived fact is true." Zep access policies "control which Zep context a caller can retrieve or change. They do not authorize an action in an external system." Its memory security guidance recommends exposing specific write operations rather than an unrestricted client.
That is a sound boundary for a service that runs Context Graphs for many teams. Deciding whether a fact about revenue, health scores or table grain is still correct means reading dbt, the warehouse, quality checks and lineage, knowing who owns each definition, and changing systems Zep does not run. That is a different product with a different liability.
Data Workers is that product: it knows what a warehouse change touches, which remembered facts depend on it and who approves the replacement, and it acts through your pipelines, verifies and keeps the record.
Every tool owns a slice. Data Workers covers the whole lifecycle
Zep owns one slice of the data lifecycle, and owns it outright: temporal context about users, accounts and domains, served to agents with governance. 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 memory you already run.
| Stage | Data Workers | Zep | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 9.5 | Zep's home stage: temporal Context Graphs for users, accounts and business domains, with facts that carry valid and invalid dates, served through the Memory MCP server, SDKs and Context Blocks. Data Workers adds governed facts about the data estate, with lineage, quality, usage and a named owner. |
| Analytics & Insights | 8 | 4 | Zep retrieves facts, entities, observations and summaries for an agent's task; it does not compute metrics. Data Workers' Insights agent answers through governed metric definitions. |
| Data Quality | 8 | 3 | Zep invalidates a fact when newer data contradicts it and keeps the history. Data Workers checks the tables and definitions those facts describe and repairs the breaks upstream. |
| Observability & Incidents | 8.5 | 2 | Webhooks report when an episode or a batch finishes processing. Data Workers detects a broken table or a changed definition, traces it across systems and fixes it. |
| Pipelines & Ingestion | 8.5 | 4 | graph.add, zep-ingest and the Batch API bring records, documents and conversations into Context Graphs. Data Workers builds, reruns and backfills the data pipelines themselves with approvals. |
| Schema & Migration | 8 | 2 | Custom entity and edge types shape the graph; warehouse schemas are outside its view. Data Workers detects upstream schema changes and assesses their impact before they land. |
| Governance & Access | 8.5 | 6.5 | Strong over its own context: RBAC for members, ABAC policies on API keys and UserGroups, source traceability and audit logs. Data Workers proposes and applies grants across your data platforms by policy. |
| Security & Privacy | 8 | 6 | Strong for its own estate: content policies, BYOK, bring your own LLM and BYOC deployment. Data Workers flags sensitive column names in pull request review and proposes masking for the owner. |
| Cost / FinOps | 8 | 2 | Zep runs its own extraction, retrieval and graph service. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 5 | Context makes agents reliable across sessions and tasks. Data Workers keeps the data under your models healthy and connects to MLflow and W&B. |
How Zep and Data Workers work together
Your engineers and agents stay where they are: Claude Code or Cursor for code, your agents on Zep's SDKs, the Memory MCP Server for off-the-shelf clients. Spellbook Data Catalog (in preview) is where the data team and agent owners look: each stale fact, its replacement, blast radius, approver and rollback. Underneath, Data Context Wizard keeps one governed context graph across every platform, the Data-Agents Swarm's 20+ specialist agents do the work, the Autonomous Data-Conductor runs each fix (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.
What Context Wizard does with your Context Graphs. It takes the facts your team's assistant brings in from the shared graphs you choose, matches each to the metric, dbt model and column behind it, records provenance (source, when observed, owner) and scores trust by quality, freshness, usage and ownership. When a warehouse change contradicts a remembered fact, the conflict goes to a named owner, and agents see both candidates and their sources until the owner decides. Only a named person can promote a fact to authoritative. Agents query it through tools such as explain_table, resolve_metric and get_authoritative_source.
Setup over MCP today. Zep connects over the Memory MCP Server or its API today, in your team's client alongside Data Workers' agents, which never call it. Zep's server is remote at https://api.getzep.com/mcp: you sign in through Google Workspace or your company's OIDC provider, and Zep's administrator sets what the connection may do (a connection can be read-only, and on Enterprise, UserGroup ABAC policies grant search or write per shared Context Graph). Data Workers' agents are MCP servers from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show.
// Example: .mcp.json for Claude Code (Cursor uses the same mcpServers shape)
{
"mcpServers": {
"zep": {
"type": "http",
"url": "https://api.getzep.com/mcp"
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-schema": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-schema"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
}
}
}For this pattern, grant search only, on the shared graphs that describe data, such as cs-playbooks. List the tools with your client's own command (/mcp in Claude Code). An engineer can then ask "which facts in cs-playbooks depend on dim_account, and are they still true?" and get facts from Zep's search_graph_in, lineage from trace_cross_platform_lineage, run_quality_check results, and load lag against the monitor_metrics baseline, in one answer.
Where writes go. Data Workers does not write into Zep, by design. Approved facts go where your team already controls what enters memory: your application's graph.add call, your zep-ingest job, or the owner's client with add_memory_to_graph. Each carries its source and approval ID as episode metadata, so Zep's source traceability and Data Workers' receipt point at the same decision. Fixes to the data itself land upstream, as a dbt diff for the owner to merge.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Connected, not acting; your team finds stale facts by hand.
- •L1 observe. Data Workers flags the data facts a warehouse change made stale, with cause and owner.
- •L2 propose. It drafts the replacement fact, or the dbt diff, with blast radius; the owner approves in Spellbook before anything is ingested.
- •L3 act reversibly. For a proven class, such as a renamed column, it hands the approved fact to your ingestion path, verifies Zep retired the old one and keeps the rollback.
- •L4 autonomous. For a scoped, trusted class in one domain, it runs the loop and posts the receipt for review.
The safety model behind each step is in is it safe to let AI agents change production data; where data and credentials live is in where does our data go. The same pattern holds for every source of meaning: see the hub, bring your own context, the guides for teams on Mem0, Letta and Cognee, and the background on temporal knowledge graphs for data, a persistent memory layer for AI agents and what is a context graph.
What changes for your team
Agent teams on Zep lose time tracing why an agent quoted a retired number, re-ingesting a playbook after a metric changed, or checking whether a nightly extract broke. With Data Workers next to Zep, those jobs run on autopilot at the level you set.
- •Incidents. A warehouse change that makes a remembered fact wrong is caught, traced and fixed before the next ingest.
- •Data quality. Tables that feed your Context Graphs get null and value checks and a load-lag baseline, so a broken extract never becomes a thousand new facts.
- •Cloud spend. Cleanups of warehouse extracts and staging tables built for retired ingest jobs are proposed to the owner after a dependency check.
- •Access. An agent that needs a sensitive table gets a time-boxed grant proposal for the table's owner, next to the graph access Zep already governs.
- •Audits. Every data fact an agent recalls carries its source, owner, approver and valid date.
- •Migrations. When the warehouse moves, extracts move in parity-checked waves and the graphs keep updating.
Keep Zep, or consolidate?
Keep Zep if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Context Graphs, Context Blocks and the Memory MCP Server belong in Zep. What teams consolidate is the tooling around it: a spreadsheet mapping playbook facts to tables, a script that re-ingests definitions when someone remembers, a separate quality tool on the extracts. Data Workers runs those jobs with one context, one approval flow and one audit trail. Thinking of building it yourself on Zep's SDK? Read build it ourselves with Claude Code and MCP servers: the connection is easy; knowing which facts depend on which tables, who owns each definition and how to roll back is the work.
The case for your CFO
The outcome: the agents that serve customers and run accounts give answers people can act on. They draw on Zep for context; Data Workers makes sure what they remember about the data, its thresholds and definitions, matches the warehouse every day.
The risk story is plain. Only the Zep facts your team's assistant brings in reach Data Workers; its agents never call Zep. Every replacement fact shows its blast radius, goes to a named approver, enters Zep through your own ingestion path, 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. Zero migration: Zep, your agents, the warehouse, dbt and your ingest jobs stay put.
Why now: agents read context from every client your people use, so one stale metric fact reaches every answer at once. The first win is one shared Context Graph that describes data, watched read-only, so the next warehouse change is caught before the nightly sync. What stays the same: your graphs, ontology, Zep plan, warehouse permissions and review process. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Zep gives our agents their context; Data Workers makes sure what they remember about our data is still true, with an owner's approval and a receipt."
Getting started
Start with a pilot. Pick one shared Context Graph that describes data, such as customer success playbooks or metric definitions, connect Zep's Memory MCP Server with search-only access next to Data Workers, and let it watch the definitions and tables behind that graph before you enable 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 Zep graphs? No, by design. Your team's assistant reads the shared Context Graphs you grant over the Memory MCP Server, side by side with Data Workers. Approved facts enter Zep through your application's graph.add call, your zep-ingest job or the owner's client, with source and approval ID as episode metadata.
Zep already invalidates outdated facts. Why add anything? Zep invalidates a fact when new data contradicts it. A dbt change or a new metric definition happens in the warehouse and never arrives as an episode on its own. Data Workers notices it, flags the remembered facts your team's assistant brings in that it affects, and routes the approved replacement to your ingestion path, so Zep's temporal model can do its job.
Which facts in Zep does Data Workers care about? Only facts about data: metric definitions, thresholds, table and column meanings, sources of numbers. Context about users and conversations stays Zep's alone.
How does this fit with Zep's access policies? Zep's ABAC policies decide which agents and Memory MCP users reach which graphs. Your team's assistant works inside them with its own grant, and Data Workers adds approvals for changes to the warehouse and the facts about it, both audit trails linked by the approval ID.
We use Graphiti, not Zep Cloud. Does this work? The pattern is the same. Graphiti's Python library and its experimental MCP server expose episodes and search over the graph database you run; your team's assistant reads the graph, Data Workers routes stale data facts to an owner, and your code adds the approved episode.
Sources
- •Zep, homepage and positioning, https://www.getzep.com/ (checked Oct 2, 2026)
- •Zep, documentation overview ("the unified context layer for enterprise data"), https://help.getzep.com/ (checked Oct 2, 2026)
- •Zep, Context Lake, https://help.getzep.com/context-lake (checked Oct 2, 2026)
- •Zep, Facts and bi-temporal timestamps, https://help.getzep.com/facts (checked Oct 2, 2026)
- •Zep, Zep vs Graphiti, https://help.getzep.com/zep-vs-graphiti (checked Oct 2, 2026)
- •Zep, Governance, https://help.getzep.com/governance (checked Oct 2, 2026)
- •Zep, Source traceability, https://help.getzep.com/source-traceability (checked Oct 2, 2026)
- •Zep, Memory MCP Server, https://help.getzep.com/memory-mcp-server (checked Oct 2, 2026)
- •Zep, Connecting a client to the Memory MCP Server, https://help.getzep.com/memory-mcp-server/connect (checked Oct 2, 2026)
- •Zep, Configuring Memory MCP authentication and writes, https://help.getzep.com/memory-mcp-server/authentication (checked Oct 2, 2026)
- •Zep, Create an ingestion pipeline with zep-ingest (0.1, alpha; for bulk and recurring imports), https://help.getzep.com/zep-ingest (checked Oct 2, 2026)
- •Zep, graph.add and episode metadata, https://help.getzep.com/adding-business-data (checked Oct 2, 2026)
- •Zep, Memory MCP shared graph authorization, https://help.getzep.com/memory-mcp-server/standalone-graph-authorization (checked Oct 2, 2026)
- •Zep, Memory security best practices, https://help.getzep.com/memory-security (checked Oct 2, 2026)
- •Zep, Webhooks, https://help.getzep.com/webhooks (checked Oct 2, 2026)
- •Zep, Changelog (Context Lake and source traceability docs, Sep 23, 2026), https://help.getzep.com/changelog (checked Oct 2, 2026)
- •Zep, Graphiti MCP Server, https://help.getzep.com/graphiti/getting-started/mcp-server (checked Oct 2, 2026)
- •GitHub, getzep/graphiti releases (v0.30.2, Sep 8, 2026), https://github.com/getzep/graphiti/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)