Before you buy an agentic data platform, build it yourself
Claude Code and DuckDB are all you need to start an agentic analytics project. And dex demo makes it even easier.
Co-Founder & CEO
Quite provocative, since an entire trillion dollar industry exists around this "quick build". Let me explain.
You want to answer a question about the business. Somehow, the first decision on the table is which data platform to buy.
Then come the cloud account, the permissions, the ingestion setup, and the conversation about what the warehouse will cost. You still haven’t established what counts as a sale.
There is useful work you can do before that commitment. Build a local prototype. Work through the joins. Define a metric. Find out which assumptions survive contact with data.
Claude Code and DuckDB give you a place to start: a coding agent to investigate and write code, and a database that runs analytics on your laptop. Dex is an open-source analytics-engineering toolkit for coding agents. It gives the agent commands to explore data, check its assumptions, and propose changes to SQL models, tests, and documentation.
For an analytics or data engineer, that makes a small local project a useful way to try the workflow before connecting company data. Dex includes a demo warehouse for exactly that purpose.
Start with a warehouse you can actually use
dex demo generates a local DuckDB database and configures Dex to read it. You get an e-commerce dataset with seven tables and 29,512 rows: customers, products, orders, order items, web events, warehouse locations, and returns.
The rows are generated from a fixed seed. There is no dataset to download and no warehouse credential to find.
Start in a fresh directory outside an existing Dex project. With uv, the Python package manager, installed, create an environment and install Dex with its DuckDB dependencies. In a macOS or Linux shell:
mkdir dex-sandboxcd dex-sandboxuv venv --python 3.11source .venv/bin/activateuv pip install "exmergo-dex-core[duckdb]"dex demodex explore map
The installation needs network access unless its dependencies are already cached. Once installed, demo generation and these local database commands work offline. Your coding agent has its own connectivity and usage costs; the DuckDB work creates no cloud warehouse bill.
The demo writes dex_demo.duckdb and .dex/config.yml. The first contains the data. The second tells Dex where it is, so subsequent commands need no connection flags. The generator refuses to replace an existing database file.
dex explore map then profiles the warehouse and records its findings: which tables matter, what appears to identify a row, likely relationships, and data-quality problems. It gives the agent an initial picture to investigate.
Give Claude Code a concrete first job
Open the directory in Claude Code and ask:
Use Dex’s CLI to investigate this demo warehouse. Run commands with the Python environment in.venv. Start withdex explore map, investigate the keys in order_items and products, and verify the inferred joins. Use Dex for all warehouse reads. Explain which findings would affect a daily sales model, with the evidence behind each. Propose the next steps before writing models.
The demo is deliberately flawed. A perfectly tidy dataset would tell you very little about how an agent handles the work that makes analytics difficult.
Take the order items. Inspect them with:
dex explore profile order_items products
There are 14,000 order-item rows and only 13,000 distinct order_item_id values. A batch was loaded twice. Summing those rows can overstate sales; joining another table to that ID can multiply matches.
Dex reports the duplicate counts and leaves the table’s grain — the meaning of one row — unresolved. The agent now has a specific defect to investigate before it writes a model that assumes one row per order item.
That is already a useful prototype result. You have found a question the eventual pipeline needs to answer: how should it handle repeated records?
Check the join that looks obvious
Next, measure the inferred relationships:
dex explore relationships --verify
Both web_events and customers have a column named customer_id. The names invite a join. The data disagrees: none of the web-event customer IDs match the customer table.
Dex reports the missing overlap and lowers its confidence in that inferred relationship. An inner join would discard those events. A left join would keep them with missing customer attributes.
If your next question is which customers’ visits convert into purchases, you have just discovered a missing piece of identity mapping. Buying a larger warehouse would leave that question exactly where it is.
Try the boundary, too
You can also see how Dex handles a request for personal data. The demo’s customer records are synthetic, but profiling still flags their email column. Run:
dex explore query "select email from customers"
Dex refuses to return the addresses. Its query firewall checks agent-authored SQL before execution. A measuring aggregate is allowed:
dex explore query "select count(distinct email) from customers"
That returns 1,200. The agent can answer the counting question without receiving the addresses. This small example lets you inspect a boundary you would want to understand before introducing real customer data.
Build your first working analytics model
An agentic data platform puts an agent to work investigating data, building models, and helping maintain them. You can build a small version of that workflow here: give Claude Code a business question, let it work through Dex, and review the project it produces.
Start with one deliverable: a table with one row per sales day and a documented sales total. Give the agent the next job:
Using the findings, propose a local dbt project for daily sales in DuckDB. Include staging and daily sales model SQL, tests, and documentation through Dex's transform workflow. Explain the proposed handling of duplicate order items. Identify unresolved decisions about order statuses, returns, and which timestamp defines the sales day. Present the diffs and assumptions for review before applying them.
dbt gives those transformations, tests, and definitions a home in ordinary project files. This is subsequent work: dex demo creates the warehouse and configuration; the agent authors the analytics project.
Review the proposed definitions before accepting the SQL. Which orders count toward sales? How are repeated order items handled? An empty returns table cannot establish that the business has no returns. Have the agent document the choices you make so the next person can understand the number.
Then take the proposal through to a working result:
Apply the reviewed plan through Dex and build the models on the local DuckDB dev target. Run the dbt tests. Check that the daily model has one row per date, that required keys are non-null, and that the modeled order items are unique under the agreed duplicate-handling rule. Reconcile the sales total against a separate aggregate over the source data using the same agreed rules. Show the results through Dex and explain any discrepancies. Report what passed, what failed, and what remains unverified.
The result should be inspectable: model SQL, documented assumptions, test results, and a daily total you can trace back to its inputs. A successful build establishes that the SQL runs. The reconciliation checks whether the transformation preserved the sales total you intended to calculate.
You now have a concrete basis for evaluating a platform. Can it investigate the broken join? Preserve your definitions? Produce changes you can review? Check its own work against the source? You have a small project to ask it to handle and evidence to compare against.
Build something you can carry forward
The value you carry forward is the reviewed logic, the tests, and a clearer understanding of the questions your real data must answer. Production still needs real-source validation, deployment, access controls, and adjustments for the target database.
You can make those decisions with a working example in front of you.
Start with open-source Dex, run dex demo, and give your agent the first investigation. Before you buy the platform, build enough to know what you need from it.
Resources