Get the data right first. Everything interesting comes after that.

There is a tempting shortcut in every data project: build the interface, wire it to whatever tables exist, demo it. It works for exactly one demo, on one dataset, with the person who built it holding the mouse. The order below is slower and holds up.

1. 01Ingest. Boring connectors, idempotent loads, replayable history.
2. 02Model. Explicit grain, explicit keys, explicit definitions.
3. 03Name the metrics once, in a typed layer that humans and models both read.
4. 04Only then put conversational access on top.
5. 05Only then let agents act — and score every action against outcomes.

The bottleneck in most teams is not the dashboard, it is the translation step: someone has a question in business language and someone else has to turn it into a query. Removing that step changes who is allowed to be curious. But it only works if questions resolve against a semantic layer instead of raw tables — otherwise you have built a machine for producing confident mistakes.

Once agents act on data, "does it feel right" stops being an acceptable answer. I treat an agent run like a landing page variant: define the outcome, record the whole run, score it on three axes, keep what wins.

1. 01Correctness — did it resolve against the semantic layer, or invent a column?
2. 02Cost — tokens, latency, tool calls. A right answer in ten seconds is a different product than in one.
3. 03Consequence — did the action move the metric it claimed it would?

The same foundation serves a creator with one audience and a mid-size company with fifty accounts. Different scale, identical questions: what is working, what is it worth, what should happen next. That overlap is the part I find genuinely interesting.