Building an Autonomous Data Science Agent with TabFM and Neon
How TabFM, an LLM agent, and branched Postgres on Neon combine to run safe, agentic churn prediction without data leakage.
What is TabFM and why does it matter for data science agents?
TabFM is a tabular foundation model from Google Research built to make predictions on table data without training a custom model for every new dataset. Instead of the usual cycle of cleaning data, engineering features, and fitting a gradient boosted tree model from scratch, you feed TabFM the rows where you already know the outcome, append the rows you want predicted, and it infers the missing values in a single pass. The dataset itself becomes the prompt. That’s the same shift that happened to text when GPT-3 made task-specific NLP models mostly obsolete. Tables never had that moment until TabFM.
The catch: TabFM alone doesn’t understand what your columns mean. Pairing it with an LLM agent and a database that supports safe experimentation (like branched Postgres on Neon) turns it into something closer to an autonomous data science system.
TL;DR
- TabFM makes predictions without training on your data first, using labeled rows as context and inferring outcomes for unlabeled rows in one pass, similar to few-shot prompting for tables.
- The model was trained entirely on synthetic data generated from random causal graphs, which means it learned a general strategy for learning from tables rather than memorizing any real dataset.
- TabFM has no concept of column semantics, treating every value as a plain number, so it can’t tell a timestamp from a dollar amount or know that zero means “missing” instead of a real measurement.
- Pairing TabFM with an LLM agent (the TabFusion Auto pattern) fixes the semantic gap, with the LLM inspecting column names, writing transformation code, and calibrating predictions while TabFM stays frozen as the inference engine.
- Data leakage is the biggest risk when agents build their own pipelines, since an agent can latch onto a feature that only exists because of the outcome it’s trying to predict, like a cancellation flag that’s only populated after a customer initiates a cancellation.
- Neon’s instant database branching lets an agent experiment safely, spinning up a copy-on-write clone of the production database for each test run and discarding it if something breaks, without ever touching live data.
- TabFM weights are currently non-commercial and research-only, so this entire setup works best as an architectural pattern to study rather than code to drop into production today.
One coffee. One working app.
You bring the idea. Remy manages the project.
How does TabFM actually make predictions without training?
TabFM was built by sampling random causal graphs and generating synthetic tables from them, then training the model to predict held-out cells within those synthetic tables. Because it never saw a single real-world dataset during training, it can’t memorize patterns specific to any domain. What it learned instead is a general-purpose algorithm for inferring unknown values from known ones in tabular form.
In practice, this means you hand TabFM a table where some rows have labels (say, whether a customer churned) and some don’t. It looks at the labeled examples, picks up the statistical relationships, and scores the unlabeled rows in a single inference pass. There’s no training loop, no hyperparameter tuning, and no repeated groundwork for every new problem. On a synthetic SaaS churn dataset with customer profiles, product usage, invoices, and support tickets, this zero-feature-engineering approach on a single table already outperformed a tuned tree-based model, even though the raw score (around 0.60) still left room for improvement.
Why does TabFM need an LLM agent on top of it?
The weak point is semantic blindness. TabFM treats every column as an undifferentiated number. It has no way to know that one column is monthly spend and another is a temperature reading, or that a “0” in one field means “not measured” while a “0” in another is a legitimate zero value. Real-world tables carry exactly this kind of meaning, and ignoring it caps how good the predictions can get.
This is where a large language model fits in. LLMs are good at reading column names, inferring what a field probably represents, and writing the transformation logic needed to make sense of it. Google researchers formalized this into an architecture called TabFusion Auto, which keeps TabFM frozen as the core inference engine while an LLM-powered agent sits above it, inspecting columns, selecting relevant context rows, writing feature code, and calibrating the final predictions. According to the people behind it, this combination reached top-rank results on the TabArena benchmark. The original TabFusion Auto code isn’t public, but the pattern itself (frozen tabular model plus an LLM orchestrator) is reproducible with any capable coding model acting as the agent and any LLM acting as the orchestrator.
How does Neon’s branched Postgres prevent data leakage?
Letting an autonomous agent write its own feature engineering code is risky if it has direct access to a live production database. Three architectural pieces address that risk.
First, the agent needs semantic grounding before it writes any code. Storing a data dictionary directly as column comments in Postgres gives the agent both the schema and plain-language descriptions of what each field means, right where it’s querying.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Second, the agent needs a sandbox. Every experiment an agent runs should happen on an isolated copy of the database rather than the production instance. Neon’s branching creates a full copy-on-write clone of the database in about a second. The agent can create feature tables, test joins, drop columns, and run its pipeline entirely inside that branch. If the experiment fails or the agent does something wrong, the branch gets deleted and production is never touched.
Third, and most important, the agent needs protection against data leakage: features that look predictive today but wouldn’t have existed at the time the prediction needed to be made. In a churn-prediction test case, one column recorded whether a customer had already initiated a cancellation. That field is a near-perfect predictor of churn, but only because it’s populated after the fact. It’s not information you’d actually have when trying to predict churn in advance. In roughly half of test runs, the agent spotted the correlation and used the leaky column anyway, producing a pipeline that looked great in a snapshot but performed worse than a clean model when tested against what customers actually did the following month.
The fix is to restore the agent’s training branch to the exact timestamp before the prediction window, so the leaky column simply doesn’t exist yet in that version of the data. That forces the agent to build its pipeline only from information that would genuinely have been available at prediction time.
Is this architecture ready for production use?
Partially. The infrastructure pattern (Postgres with inline semantic comments, instant branching for sandboxed experiments, and point-in-time restores to prevent leakage) is production-grade today and works with any model stack. For a recurring workload, the pattern extends naturally: an agent’s finished pipeline gets saved into the database, and a scheduled function rebuilds features nightly, queues the scoring job, and writes predictions back to a live table alongside an exported at-risk list.
What isn’t production-ready is TabFM itself. Its weights are released for non-commercial research use only, so teams can study and prototype with the architecture but shouldn’t expect to deploy TabFM directly inside a commercial product. Treat it as a blueprint: the database architecture, the leakage safeguards, and the agent-orchestration pattern are reusable right now, even with a different tabular model underneath.
Frequently Asked Questions
What is TabFM used for?
TabFM is a tabular foundation model designed to predict missing or unknown values in table data, such as customer churn, fraud flags, or sensor anomalies, without training a dedicated model for each new dataset. You provide labeled examples as context and it infers the rest in one pass.
Why can’t TabFM understand column names or labels?
TabFM was trained exclusively on synthetic tables generated from random causal graphs, with no real column headers or semantic labels involved. As a result, it treats every value purely as a number and has no built-in sense of what a column represents.
What is data leakage in an agentic data science pipeline?
Data leakage happens when a model or agent uses a feature that wouldn’t actually have been available at prediction time, often because that feature is a downstream consequence of the outcome being predicted. An example is a cancellation flag that only gets set after a customer has already decided to churn.
How does database branching prevent an agent from corrupting production data?
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Branching creates a full copy-on-write clone of the database that an agent can freely modify, query, and experiment on. If something goes wrong, the branch is discarded and the production database remains untouched, since the agent never writes directly to it.
Can I use TabFM commercially right now?
No. The TabFM weights referenced here are released for non-commercial research purposes only, so the model itself isn’t cleared for commercial deployment. The surrounding architecture (semantic column comments, branched sandboxes, leakage-safe timestamps) can still be studied and reused with other models.
