Read time: ~6 minutes · Series: Analyst practice · Previous: Plan → Execute → Report · Next: Cache and Source Run
Why pull data with SQL instead of hiding it in the conversation
Many "upload CSV → AI produces charts" tools actually run Python/pandas in the background, and you only see the chart and a summary. How the denominator is filtered, how two tables join, whether it fans out—these often can't be saved as formal evidence.
Lantide chooses SQL-first:
- Plan states "what to compute and what the metrics are"
- SQL tabs state "how to compute it from the tables"
- Report states "the conclusions and limitations"
When a colleague questions a number, you open the SQL tab or View SQL in Cached, and you edit the same logic—not replay a chat.
An analyst's daily division of labor
| Layer | What goes in | Example |
|---|---|---|
| Plan | Business metrics, stages, checkpoints | "active = at least one paid order in the last 90 days" |
| SQL tab | FROM / JOIN / WHERE / GROUP BY |
Concrete filter conditions and join keys |
| Reference file | Large mappings, dictionaries (full text) | Status-code tables, column-rename lookups—see Reference docs |
| Conversation | Interpretation, follow-ups, revising the Plan | "The NULL ratio here is high—should we exclude it?" |
| Report | Numbers + limitations | "Conversion rate 12.3%; no reverse adjustment for refunds" |
The Agent helps you create tabs, write SQL, and run it; your responsibility is to review the Plan, review the SQL, and press Execute—not to write every query from scratch, but to ensure the artifacts are reviewable.
Manual SQL and the Agent can be mixed
Lantide has two paths (see USER_GUIDE §1.2):
- Path A: you write SQL yourself in the editor
- Path B: the Agent collaborates on Plan → Execute → Report
Within the same workspace, you can:
- Explore tables manually first, then have the Agent write a Plan
- Manually edit a tab the Agent created, then Execute
- Validate a join in Quick, then move it into the project Plan once satisfied
Consistent table names: the Agent and you share the same set of tables on DuckDB (local files, connections, cache tables).
Before Execute, the Agent often runs list_sql_tab first to enumerate the workspace's existing persist SQL tabs (including Label and project ownership), to avoid creating duplicate pipeline tabs. You can set Metadata (Label / Project) on a tab—see USER_GUIDE §5.6.
Which layer do statistical tools go in
The t-tests, regressions, clustering, etc. in the conversation (see statistical analysis tools) are built on top of a clean table the Agent prepared with SQL first:
- Pulling, cleaning, aggregating → SQL tabs (rerunnable, viewable)
- Testing, modeling → statistical tools, with results mainly shown in the conversation
During the Planning stage the Agent does not run formal statistics; after Execute, and before running a test, the Agent asks you to confirm the parameters.
The difference from "hidden data analysis" (analyst view)
| Chart-from-chat tools | Lantide | |
|---|---|---|
| Metric evidence | Mostly in summaries | SQL tabs + Plan |
| Rerun | Hard to reproduce | Run the same tab or Source Run |
| Collaboration | Repost the conversation | Annotate Plan / Report |
| Speed | Often quicker to pick up | A few more review steps, in exchange for sign-off-ready results |
If you only need one chart and will never be asked about the metrics, the former may be enough. If this number will go into a weekly meeting, a contract, or an audit six months later, SQL-first is a better fit.
Practical habits (three of them)
- Every "metric that will be cited" should be findable in SQL or the Plan—not only spoken or in chat.
- A persistent tab + running it produces a cache, which later SQL can reference with
FROM "tab_name"(see cache). - When you doubt a number, Data → Cached → View SQL is faster than scrolling through chat.