Personalized, self-improving data agents
A generic agent repeats the same mistake next week and ignores how your team really works. Data Workers agents take in your runbooks and definitions, remember every correction, flag context that has gone stale, and work to your conventions, with a named person owning what counts as right.
Before and after
| Today | With Data Workers |
|---|---|
| An agent that gives the same wrong answer every week | A correction made once and remembered |
| Runbooks, definitions and "never use that table" rules in a few heads and a stale wiki | Your team's knowledge brought in and used by every agent |
| Agent output in a generic style that reviewers rewrite | Pipelines, models and docs that follow your conventions |
| Out-of-date context reused until someone gets a wrong answer | Stale context flagged to its owner before it is reused |
| Every new agent starting from zero | Agents that start from what your team has already settled |
Agents are only as useful as their fit with your estate, and most teams find out how poor the fit is one wrong answer at a time. The cost lands on your senior engineers, who end up correcting the same thing again and again. This page is the operating model for agents that adapt to your team; the deep dives are what an agent should remember about your data and the corrections log.
How it works
1. Bring in what your team already knows
Point the Data Context & Catalog agent at the runbooks, definitions and rules your team already holds, such as "revenue means net of refunds" or "never use the staging copy of orders" (import_tribal_knowledge). Every other agent works with that knowledge from the first request, so a new agent does not start from a generic template.
2. Correct it once
When an answer is wrong, a person says so in plain terms (correct_response) and the agents remember. The same mistake does not come back next week. Your data engineers stay the authority on what is correct, and each correction has a person behind it.
3. Flag what has gone stale
Context ages. The agents flag definitions and documentation that no longer match the data (flag_stale_context) and the gaps where nothing is written down yet (flag_documentation_gap), and send them to the owner instead of quietly reusing them. New work, such as the next pipeline from the Pipeline Building agent (generate_pipeline), follows your conventions.
The impact metrics we move
- •A team's runbooks and rules usable by agents: from about 2 weeks to 1 day
- •A correction put in place after a wrong answer: from about a day to ~15 min
- •Stale context found and routed to its owner: from about a month to 1 day
Where teams start
- •The definitions people argue about. Revenue, active customer and churn: import the agreed meaning once and correct the agents against it.
- •Your senior engineers' repeat corrections. Take the five things they fix most often in agent output and make each a one-time correction.
- •Runbooks for the on-call rotation. Bring in the pages the team already trusts so incident work follows your steps, not a generic playbook.
- •Naming and modelling conventions. Let new models and pipelines follow the way your team already builds, starting with one dbt project.
- •A new joiner's first month. Capture the answers they ask for most and let the agents carry them from the first day.
What powers it
The Data Context & Catalog agent takes in your team's knowledge, records corrections and flags stale context. The Data Context Wizard holds the shared understanding of your estate that every agent works from, and keeps it current from what the agents and your team do. Spellbook Data Catalog (in preview) is where people see and edit that context, and Autopilot Routines check for stale context on a schedule. Autopilot Standards turn your conventions into rules, and the Autonomous Data-Conductor routes the work across the Data-Agents Swarm. This shows up in data discovery, in enterprise AI context and in AI-ready data teams. Already keeping notes for an assistant? See how tribal knowledge becomes agent context, or the six layers of context behind it. On Mem0? Read keeping remembered facts true.
The climb: from assisted to autonomous to agentic
Every transformation runs on the ladder from our thesis. Agents start by watching and suggesting (L0 to L2 run today), and a domain can move further up on evidence from its own record. As corrections accumulate, a domain has more evidence to point to, and its owner decides how much autonomy to extend.
The pilot
- •Scope. One domain and one team: its runbooks, its definitions and the stack it builds on.
- •First week. Agents start by watching and suggesting. They take in your runbooks and rules, and your engineers correct what they get wrong while we record a baseline of repeat corrections.
- •By week two. Corrections are remembered, stale context is flagged to its owner, and new drafts follow your conventions. Anything sensitive stays with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •A team's runbooks and rules usable by agents: from about 2 weeks to 1 day
- •A correction put in place after a wrong answer: from about a day to ~15 min
- •Stale context found and routed to its owner: from about a month to 1 day
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Does the agent get better on its own? It improves through what your team gives it: imported knowledge and corrections. Out-of-date context is flagged rather than quietly reused, and your people decide what is right.
Who should correct an agent? The data engineers and stewards who own a domain. Starting there means every correction has a named person behind it.
What if a correction is wrong? It is a change a person made and can be changed by a person. Sensitive decisions still go to a named approver before anything changes in production.
Which stacks does this work with? The agents work alongside the warehouse, dbt project and orchestrator you run today. Nothing has to be migrated first.
How is this different from agent memory? Memory alone keeps whatever it was told, true or not. Here the context sits next to the data estate, and out-of-date facts are flagged instead of reused. The agent memory guide covers what to remember and what to re-read live.