Discovery
The living semantic catalog knows what data exists, what it means, where it lives — and what's already been built. The agent answers in seconds what used to take weeks of hunting, and discovery gets richer with every request resolved.
Most AI agents for data engineering die between pilot and production. This page walks the full request lifecycle on Tabsdata — what the agent sees, what it does, and where a human approves — and why it works where bolted-on agents fail.
create a new project finance, and create a finance source collection using info at ~/finance.txt
Done — project and source collection are up, and the connection checks out live.
explore finance source
Cached catalog was already fresh — no live re-scan needed. finance is a subscription-billing OLTP schema, 6 tables.
Clean star shape — customer_subscriptions is the fact-like hub, joining out to customers, plans, prices and payment methods, with the events table as its history.
Every data request your team resolves goes through the same four stages — find the data, check it isn't already built, build it right, prove it didn't break anything. Today, each stage is days or weeks of engineering time. On Tabsdata, the agent runs all four with full context, and a human approves what ships.
The living semantic catalog knows what data exists, what it means, where it lives — and what's already been built. The agent answers in seconds what used to take weeks of hunting, and discovery gets richer with every request resolved.
Before building anything, the agent checks prior deliveries for whether the answer — or a partial one — already exists. Redundant pipelines never get built; prior work is a first-class input to every new request.
Without one catalog, nobody can prove it already exists.
The agent assembles the dataflow step by step, and every intermediate step is an immutable versioned table the requester can inspect directly. Nothing propagates unvalidated.
Bolted-on agents deliver a big reveal — and hope.
Every change is tested against prior versions before it lands. Acceptance is a measured comparison, not a judgment call.
In a mutable stack, there's no prior version to test against.
An agent is only as good as what it can see. In Tabsdata, context isn't fetched from surrounding tools or reconstructed from logs after the fact — it's a property of the system the agent operates in, present the moment it acts.
What every piece of data means and what's already been built — kept current automatically as sources and destinations are connected and as dataflows are delivered.
What every piece of data depends on, produced by execution itself rather than reconstructed from logs.
Every state of every table, past and present, so nothing the agent acts on is hidden or lost.
That's the difference between an agent that reasons over your estate and one that guesses at it. And through Tabsdata MCP, all of it is available to any agent your team already uses — no integration project, no context pipeline to build and maintain.
make the project a medallion data arch one, and import finance data into the bronze layer
Scaffold is up. One fork worth flagging before I generate anything: finance_source advertises only MySQLSrc as a compatible publisher kind — true binlog CDC isn't reachable from the connection we built.
@publisher(
source=MySQLSrc(queries=[
"SELECT customer_id, external_id, name, email, country,"
" default_currency, is_active, created_at, updated_at"
" FROM customers"
]),
output_tables=["customers_snp_raw"],
)
def publish_customers_snapshot(df: TableFrameSpec) -> TableFrameSpec:
return df
All 12 registered, and each transformer auto-wired a trigger on its raw table — so bronze follows the publisher without anyone scheduling it.
The agent proposes; a human approves. Every change the agent makes passes through an approval gate before it lands — and because every change creates a new immutable version, approval is reviewing a concrete, inspectable diff, not trusting a description. Tabby, the built-in operational agent, follows the same rule: it traces failures to root cause and suggests the fix, but it is advisory by design.
Nothing in Tabsdata acts autonomously on your data. Safety is a property of the architecture, not a supervision policy.
The industry pattern through 2026 is consistent: the large majority of enterprises are piloting AI agents for data work, and only a small fraction ever reach production. The failure mode is nearly always the same — missing context. An agent bolted across disconnected tools renames a column and moves on; twelve downstream models break the next morning, because the agent had no view of the dependency graph. Warehouse-native agents have lineage inside their own walls and go blind the moment a workflow crosses a platform boundary — which real workflows do constantly.
The math makes it worse. Agents work in sequences, and errors compound: a twenty-step chain at 99% per-step reliability is right about four times in five overall; at 95%, it fails almost two times in three. You don't fix that with a smarter model. You fix it with a system where each step is validated before it propagates and where a mistake creates a new version instead of destroying an old one — so errors can't compound silently.
That's the design argument for Tabsdata in one sentence: the agent isn't better because it's smarter; it's better because it's the only one that can see.
One system where the agent sees everything — fast and safe.