The Data Team Operating Model When Agents Do The Routine Work
What changes for roles, approvals and on-call when agents handle the repetitive load, and what stays human
The data team operating model when agents do the routine work is a split of responsibilities: agents execute repeatable, well-specified tasks (triage, schema diffs, test generation, lineage lookups), and humans own the policies those agents run under, review the exceptions, and answer for outcomes. The idea borrows from Google's definition of toil in the SRE book chapter on eliminating toil: manual, repetitive, automatable work that scales with load and produces no lasting value. Most data teams spend a large share of their week on exactly that kind of work, and we think the operating model should be redesigned around removing it, not just around adding a chatbot.
Author's note: this is our opinion, built from how we run Data Workers and from conversations with data teams. It is not a benchmark, and we give no productivity percentages because we do not have audited ones.
Key Takeaways
- •Agents take the routine, specifiable work; humans keep policy, judgment and accountability. The team's output shifts from tickets closed to rules written and exceptions resolved.
- •The scarce resource in this model is not engineers typing code, it is written-down intent: contracts, ownership, access rules and approval thresholds.
- •Roll out in stages that go from read-only answers to supervised writes to bounded autonomy, with a named human gate at each stage.
- •Incident response is the clearest first win, because diagnosis is mostly cross-system lookup, which agents do well, while the decision to change production stays with a person.
- •The model fails where the data is undocumented, ownership is unclear, or the work is genuinely novel. Fix those first or the agents will only amplify the mess.
The data team operating model when agents do the routine work
Most data teams today are organised around a queue. Requests arrive (a broken dashboard, a new column, an access request, a slow pipeline), an engineer picks one up, investigates across four or five tools, makes the change, and moves on. The engineer is the integration layer between the warehouse, the orchestrator, the catalog, the BI tool and the ticketing system. Throughput scales with headcount, and so does the interrupt load.
When agents do the routine work, the queue changes shape. An agent picks up the request, gathers the evidence across those systems, proposes a change, and a human approves or rejects it. The human's unit of work is no longer the investigation, it is the review. That sounds like a small shift. In practice it changes who you hire, how you run on-call, and what you write down.
This also changes what an agent needs from the team. An agent can only act on what it can read: tests, contracts, ownership metadata, and the history of past decisions. We covered that side of the problem in our context layer piece, and the broader argument for removing manual operations in our autonomous data ops and zero data ops pages. This post is narrower: it is about the team, the roles and the rules, not the architecture.
What counts as routine work
We draw the line with three tests. Work is routine if it is repeatable (the same shape every time), specifiable (you could write the acceptance criteria in advance), and reversible (a wrong answer can be caught and undone before it costs anything). Work that fails any of the three stays with a person.
| Work item | Passes the three tests? | Who owns it in the new model |
|---|---|---|
| Answering "what changed in the orders schema since last deploy?" | Yes, read-only and checkable | Agent answers, human spot-checks |
| Diagnosing why row counts dropped 40% overnight | Mostly: evidence gathering is routine, the root-cause call is not always | Agent assembles evidence, human confirms |
| Generating tests and documentation for a new model | Yes, reviewable in a pull request | Agent drafts, human reviews the diff |
| Checking the blast radius of dropping a column | Yes, a lineage lookup | Agent reports, human decides |
| Applying a fix to a production pipeline | Only with an approval and a rollback path | Human approves, agent executes |
| Deciding what a metric should mean | No, it is a business judgment | Human |
| Designing a new data product | No, it is novel | Human, with agent assistance |
How roles change
We do not think this removes data engineers. We think it moves them up a level of abstraction, and the job descriptions change accordingly.
- •Data engineers write and maintain the contracts, tests and runbooks that agents execute against, and review agent-authored changes the way they review a colleague's pull request.
- •Analytics engineers spend less time on boilerplate models and more on metric definitions, semantic consistency and the review of generated transformations.
- •Data stewards and governance owners become authors of machine-readable policy (who may see which columns, which tables are certified) and not gatekeepers of tickets.
- •On-call becomes exception handling: the engineer on call sees the incidents the agents could not close, with the evidence already attached, rather than every alert.
- •Data leaders measure the team on outcomes (freshness, quality against SLA, time to resolution, cost) and on how much of the routine load is genuinely off the humans, not on tickets closed.
The skill that gains value is writing precise intent. If your definition of a "certified table" lives in one senior engineer's head, an agent cannot follow it, and neither can the new hire.
What a policy and an approval rule actually look like
Vague talk about guardrails is not useful, so here is the shape of the rules we mean. These are examples of what a team would write down, expressed as plain statements you can later turn into configuration.
- •Read access: agents may query metadata, lineage and query history for all schemas, and may never return raw values from columns tagged as PII.
- •Write scope: agents may open pull requests against the transformation repo, and may not merge to the main branch without one human approval.
- •Production changes: any change that alters a table consumed by a certified dashboard requires approval from that table's named owner.
- •Spend: an agent may not run a query estimated to cost more than a threshold you set without asking, and must log the estimate.
- •Rollback: every automated production change must reference a tested rollback step, or it is routed to a human.
The point of writing these is that they are reviewable. A rule in a repo can be argued about, versioned and audited. A habit in someone's head cannot.
A staged rollout with a human gate at each stage
We recommend moving through the stages in order and not skipping ahead. Each stage has an explicit human gate: the person or role who must sign off before the next stage starts.
| Stage | What agents may do | Human gate | Exit criterion |
|---|---|---|---|
| 1. Ask | Answer questions from metadata, lineage and query history. Read-only. | Data lead approves connections and the scope of what is readable | Answers are correct on a sample the team checks by hand |
| 2. Diagnose | Investigate incidents and attach evidence to the ticket or alert | On-call engineer reads and confirms every diagnosis | The team trusts diagnoses enough to stop re-deriving them |
| 3. Propose | Open pull requests: tests, docs, fixes, schema migrations | Code owner reviews and merges every change | Review rejects are rare and the reasons are understood |
| 4. Act with approval | Execute approved changes in production with a logged rollback | Table owner approves each change before it runs | No unplanned rollbacks over an agreed period |
| 5. Act within bounds | Auto-resolve a narrow, named class of low-risk incidents | Data lead signs the allowed class and reviews a weekly log | Auto-resolved items are audited and the error rate is acceptable to the owner |
Most teams should expect to live in stages 2 to 4 for a long time. Stage 5 is a deliberate decision about one narrow class of problem, not a destination for the whole platform.
Where Data Workers fits, and where it does not
Data Workers is an open-source set of MCP-native agents for pipelines, quality, schema, governance and insights. Each agent is an MCP server, so it can be called from Claude Code, Cursor or any client that speaks the Model Context Protocol. That matters for the operating model because the review step happens where your engineers already work. In Claude Code (see the Claude Code docs), a diagnosis or a proposed change arrives in the terminal and the repo, not in a new dashboard someone has to remember to check.
The open-source edition runs locally and is read-only by default, which maps to stages 1 and 2 above. Writes, approval workflows and audit trails belong to the Pro edition, which maps to stages 3 to 5. Check the product pages on the site for the current edition split before you plan around a specific capability.
Where it does not fit: if you have a handful of pipelines and one engineer who knows them all, you do not need an agent layer, you need documentation. If your data has no owners and no tests, agents will produce confident answers on top of unreliable inputs. And if your problem is a strategy or modelling question, no amount of automation of the routine work addresses it. A single agent in a coding tool, with no shared context between ingestion, quality and governance, is often enough for a small team, and we say so in our single-agent versus coordinated-agent comparisons.
Risks we would watch
- •Review fatigue: if agents produce more pull requests than humans can honestly review, approvals become rubber stamps. Cap the volume, do not raise the approval speed.
- •Skill atrophy: if no one investigates incidents by hand anymore, nobody can tell when the agent is wrong. Rotate people through manual diagnosis on a schedule.
- •Unowned policy: rules written once and never revisited drift from reality. Give each policy a named owner and a review date.
- •Data exposure: keep sensitive columns and credentials out of any agent's reach by default, and prefer tools that run inside your own infrastructure with an audit trail you can inspect.
Frequently Asked Questions
Does this operating model replace data engineers? No. It changes what they spend time on. The routine investigation and boilerplate shrink, while contract writing, review, architecture and incident judgment grow. We have no data suggesting teams shrink, and we would be sceptical of anyone who claims it from a small sample.
What should a data team automate first? Start with read-only questions and incident diagnosis. Both are checkable, both are reversible, and both remove the cross-system lookup work that eats on-call time. Leave production writes until you trust the diagnoses.
How is this different from adopting a data observability or catalog tool? Observability and catalog tools detect problems and record metadata. The operating model asks a further question: who does the work between "something is wrong" and "it is fixed", and under what rules. Tools supply signals, and the model decides how humans and agents act on them.
Do we need Claude Code or Cursor to do this? No. Any MCP-compatible client works, and the model itself does not depend on a specific tool. Claude Code and Cursor are where many engineers already spend their day, which makes the review step cheaper.
When should a team not adopt this? When ownership, tests and documentation are missing, when the data estate is small enough for one person to hold in their head, or when leadership will not fund the time to write policy. In those cases, fix the foundations first.