I recently attended a Warp x Sequoia event about creating software factories. The panel had Peter Steinberger (needs no introduction, legend), Paige Bailey from DeepMind, and Zach Lloyd, founder and CEO at Warp (I need to give their terminal a try). Pretty strong lineup.
The conversation stuck with me because it put words around something I have been thinking about a lot lately: agentic loops. The AI workflow where you stop prompting step by step and instead design a small AI system that keeps going by itself (through a suite of agents): inspect, act, check, write down state, repeat.
The point is that you go beyond just writing single prompts and instead design the machine that keeps prompting, checking, and deciding what happens next.
For software engineering, this is starting to make a lot of sense, especially when you have good tests in place.
An agent can inspect a repo, make a change, run the tests, fix what broke, open a PR, and leave you with a diff. It can still get things wrong, but the loop now has a heartbeat and can continue to evolve.
I've been wondering how this can translate to data science. So in this post I share that wondering with you.
Agents can write SQL and Python pretty accurately. They can also train models, make plots (and inspect them), build dashboards, or summarize experiments. So what's missing?
The hard part is knowing what problem is truly worth solving for the context you operate in and what "success" looks like.
The metric is the trap
A coding loop often has a decent stopping condition.
Tests pass. Lint is clean. The endpoint returns what it should. The app builds.
That does not mean the work is correct or most optimal, but there is a clear signal the loop can use.
Data science rarely gives you that for free.
You can improve AUC and still make the product worse. You can improve recall and bury an operations team in false positives. You can reduce average error and still fail on the only segment anyone cares about. You can build a beautiful dashboard that answers the wrong question.
This is where I think a lot of agentic DS workflows will quietly go wrong.
They will be very good at producing motion. New notebook. New chart. New model. New experiment. New summary.
But motion is not (always) progress.
Progress depends on the metric. And the metric depends on the problem.
In fraud for example, better might mean catching more fraud at the same review capacity. Or reducing customer friction while holding loss constant. Or improving calibration so downstream rules behave better. Or making alerts more useful for analysts. Or finding weird behavior early enough that someone can still act on it.
All of these are not the same problem and require a different metric to optimize over.
An agent needs to know which one it is solving or it will just happily pick one for you; explicitly or, worse, implicitly.
Data understanding is not a profiling report
The second hard part imho is the data.
Agents are already pretty good at shallow data understanding. Give them a table and they can profile it. Missing values, distributions, correlations, outliers, basic summaries. Useful for sure, but not enough.
But deep data understanding is different. It is knowing why a column exists. When it is populated. Whether it would exist at prediction time. Whether it leaks the future. Whether missing means missing, not applicable, delayed, broken upstream, or customer never answered.
It is knowing that labels are often political, delayed, incomplete, or just proxies for something we wish we could observe directly.
It is knowing that a clean-looking dataset can encode a messy business process.
This matters because a data science agent can very easily do the technically correct thing with the wrong interpretation.
And honestly, humans do this too. The agent just does it faster...
What would a useful DS loop actually do? Some first thoughts.
The version I would trust does not start by training models, but rather by trying to understand the setup.
What decision are we improving? Who uses the output? What happens if the model is wrong? What is the current baseline? What does success mean? What would make the work useless, even if the metric improves? These questions are already a lot harder to answer in an automated loop.
Once those (hard) questions are answered, the agent can look at the data.
Not just here are the nulls, but here are the things that might make this experiment invalid. Time leakage. Label delay. Weird joins. Segment drift. Suspiciously predictive columns. Data that exists offline but not in production.
Only after that should it start running experiments.
And even then, the loop should keep asking annoying questions.
- Did the metric improve on the right population?
- Did we beat a dumb baseline?
- Did we just overfit a time period?
- Did a small group get worse?
- Is the improvement big enough to matter?
- Would this survive production?
That is the shape I'd want.
Not an agent that blindly searches for a better score. An agent that keeps the problem, metric, and data assumptions in the loop.
The human does not disappear
But this is where I think the software factory metaphor gets interesting for data science.
A factory needs quality control. Otherwise it just produces more stuff (a.k.a. AI slop).
For data science, quality control is not only tests. It is metric design, slice analysis, baseline comparisons, leakage checks, business review, and (human?) judgment about trade-offs; though I do believe judgment can be learned by agents too for the record.
Some of that can be automated. Some of it can be delegated to (human-infused) evaluator agents. Some of it should be written down as durable project context.
But some of it is still (for now) just the data scientist saying: wait, this metric is not what we actually care about.
Or: this looks better offline, but I do not believe it will work in production.
Or: this segment matters more than the aggregate number suggests.
That judgment is the job.
The agent can make the loop faster. It can keep track of experiments, generate candidates, run evaluations, and summarize trade-offs. Great. I want that.
But if the loop does not understand the problem, it will happily optimize the wrong thing all night while I'm sound asleep.
Closing the loop
So yes, I think agentic data science loops are coming (and are already partly there).
The challenging part is to build loops that understand enough problem context to be useful. A loop that knows/understands the metric. A loop that remembers - and updates - the data assumptions through the process. A loop that compares against useful baselines. A loop that surfaces trade-offs instead of hiding them in a single score.
The loop is not closed when the model trains.
It is closed when the system can connect the experiment back to the problem we actually meant to solve.
That is the hard part imho.
And probably the fun part too.
In the coming weeks, I will experiment and play around more with these ideas, so I might post a part 2, we'll see.
So yes, I am excited about software factories. I just think the data science version only gets interesting once the factory learns to keep asking: are we still solving the right problem?