The Data Function Stops Taking Requests

“This is the first time in my career with no backlog.”

That’s Nick Ursa, who leads data engineering at MotherDuck, quoted in a post that grew out of a talk at the company’s Data Outpost conference last week.¹ The post names the job he now does: the Data Intelligence Engineer. I want to take its argument one step further than it goes.

A backlog is more than a pile of work. It’s the data team’s interface. The post’s own example: marketing has a question about churn, it becomes a ticket, the ticket goes to an analyst, then a data engineer, then back, and the dashboard ships too late to matter. If that queue is gone, the job hasn’t only gotten faster. It has a different shape.

What MotherDuck is naming

The post argues that models now write good SQL, learn business logic from context, and work through problems over many turns, so most of what a data team produced by hand can be prompted. What can’t be prompted is accountability. Ursa again: “Data eng, regardless of tooling or who does it, is an accountability function.”

The Data Intelligence Engineer holds that accountability. They conduct the agents that do ingestion and modeling, encode what the company knows into shared context, run evals (questions with known answers, asked repeatedly to detect breakage), and answer for the numbers. The goal is self-service. The post calls it “a role you play, whatever your title says,” which is why I’d rather call it a function.

I agree with nearly all of it. But the picture is still mostly request and response: a person asks, an agent answers, the engineer makes sure the answer was good. That’s the old interface with the wait removed.

The agent that waits

Three weeks ago Anthropic released a research preview called Claude Duet.² It isn’t a data product. It reads your email and calendar. I bring it up because of how it behaves: you don’t have to go to it. It checks your accounts on its own schedule, comes to you when something needs you, keeps working when you leave, and, in Anthropic’s words, “checks with you before it acts on your behalf.” The pattern is sometimes called ambient intelligence.

Put that posture in a data team. A request-driven agent answers the question someone thought to ask. An ambient one could notice the question nobody asked: the metric that moved more than it ever has, the new value in a column, the thread where two people are using different numbers for the same thing. Nobody files a ticket for these, so a team that works from a queue doesn’t hear about them until someone trips over the number.

The approval gates speak to the obvious worry, an agent changing numbers nobody asked it to change. Ursa’s line is that “agents need supervision proportional to their blast radius,” and the post sorts a company’s data into three circles: a wild west where anyone builds, a curated set kept working on best effort, and a core of metrics that have to be right. An ambient agent could use the same map. In the outer circle it fixes things on its own. In the core it drafts the fix and waits for a name.

The layer that heals

An agent that watches needs something to tend. In the first essay here I proposed a semantic layer that heals itself. Metric definitions live in plain files under version control. A bot asks the people who use a definition whether it still holds. When someone says a number is wrong, an LLM proposes a new definition, validates it against the warehouse, and posts the change for review. Part of this exists: NVIDIA’s open-source Auto Ontology has an LLM draft definitions and people certify them before agents rely on them.³

The MotherDuck post says context is a crutch that’s difficult to maintain, and that a clean data model is the better cure. I’d say both are difficult to maintain by hand, because what a business means by “active” or “revenue” moves with every pricing change. So I’d stop maintaining either by hand. The post’s evals and my check-ins look to me like one instrument pointed in two directions. An eval asks the machine a question with a known answer. A check-in asks a person whether the known answer is still right. Run both continuously and the loop can sense drift from either side.

Why I call it a control system

Cybernetics is the study of systems that steer themselves by feedback: sense the state of things, compare it with a goal, act, and sense again. The two halves map onto that loop directly. The ambient agent is the sensor and the actuator. Evals and check-ins are the comparison. The person sets the goal. And the semantic layer is the model the regulator steers by. There’s a theorem for why it needs one: Conant and Ashby showed that every good regulator of a system must be a model of that system.⁴ A service desk is open-loop by comparison. It acts when asked and rarely checks what its answer did.

What it would look like running

A thought experiment. A company launches a free tier on a Tuesday, and nobody tells the data team.

That night the agent’s eval for “active customers last month” comes back far outside its usual range, and a value it has never seen, free, has appeared in the plans table. It writes to the metric’s owner: “Active customers jumped on Tuesday. The new free plan is being counted. Should it be?” The owner says active means paying. The agent drafts the change, runs it against the warehouse, and posts the old number, the new number, and the diff. Because the metric sits in the core, it waits for sign-off before merging.

If it ran this way, there’d be no ticket and no analyst finding the problem weeks later. The first human involved would be the one who knew the answer, and it would cost them a sentence. Whether real signals are this clean is the open question. An agent that pings owners too often will be muted, and then it’s a backlog again.

What’s left for the person

Everything on MotherDuck’s list: the data model, the context, the evals, the accountability. An ambient loop adds a few decisions. Which metrics sit in the core, and who owns each. What the agent may change alone. And what it’s allowed to watch, since an agent that reads continuously has more chances to read something it shouldn’t trust. I argued for declaring those inputs in the last essay.

So less of the Data Intelligence Engineer’s day goes to answering questions, or checking answers one at a time. More goes to designing the loop, setting its limits, and signing their name to what comes out.

None of this is shipped as one system, as far as I know. Duet is a personal assistant in preview, and Anthropic says it can misjudge what’s urgent. The self-healing layer is a design with open-source pieces that get partway. MotherDuck’s post argues the data team isn’t going away, and I think that’s right. If the rest of this holds, what changes is that it stops taking requests.

Jordan Tigani, “The dawn of the Data Intelligence Engineer,” MotherDuck, November 11, 2026. First presented at the company’s Data Outpost conference in San Francisco on November 4, 2026. MotherDuck sells a data warehouse and the post closes by mapping the role onto its products, so read it as a vendor’s view. ↩
Anthropic, “Introducing Claude Duet,” October 21, 2026. The preview is waitlisted, limited to individual subscribers in the United States, and not yet offered on team or enterprise plans. ↩
NVIDIA/auto-ontology, Apache-2.0. It stops short of asking people unprompted, which is the part the check-ins add. ↩
Roger Conant and W. Ross Ashby, “Every good regulator of a system must be a model of that system,” International Journal of Systems Science, 1970. The Wikipedia entry is a fair summary. ↩