Has this happened to you? An AI Agent rebuilds an analysis in 15 minutes. You then spend two hours checking whether it used the wrong table, the wrong denominator, or an analytical path your team ruled out last week.
Agents can find columns, write SQL, run notebooks, create charts, and turn the output into a persuasive narrative. But ask, “Where exactly did this conclusion come from?” and the answer is often scattered across chat history, overwritten queries, a handful of notebook cells, and the analyst’s memory.
AI has accelerated analysis, and it has raised the cost of losing context.
We are managing a worker that can explore, execute, revise, and branch on its own with records designed for a human performing one step at a time. Faster execution also means faster, more expensive rework when the context is missing.
An AI Agent does much more than write SQL
Early analytical AI behaved like autocomplete. You described a request and received a SQL snippet. You pasted it into an editor, ran it, inspected the error, and returned with the next question. Every action passed through your hands, so you naturally remembered what had happened.
Today, an analytical Agent can accept a goal and carry out an entire sequence:
Business question
→ Find likely tables and columns
→ Generate SQL or Python
→ Execute and inspect the result
→ Revise automatically after errors or anomalies
→ Produce charts, summaries, and a report
Databricks Genie Code can plan work, retrieve relevant assets, run notebook code, read cell output, and correct errors. Microsoft Fabric Data Agent uses the question, schema, examples, and instructions to generate SQL, DAX, or KQL while exposing intermediate steps. This is no longer simply “AI suggests and a human operates.” The human sets the goal, the Agent executes, and the human reviews.
The dbt Labs 2025 State of Analytics Engineering likewise shows AI becoming common in analytics development, code, and documentation. The question is shifting from “Can AI write it?” to “Can we verify what it did?”
The exhausting part is rebuilding context
The friction in daily Agent collaboration is rarely SQL syntax. It is the follow-up investigation:
- Which SQL was the version we actually accepted?
- Which execution produced this chart, rather than the query currently on screen?
- Why did the Agent switch from table A to table B? Was A temporarily unavailable or proven unsuitable?
- Which definition, time window, and timezone does “active user” use in this report?
- Does the Agent in a new conversation know that a source was ruled out last week?
- When did a JOIN, denominator, or filter change, and which downstream conclusions did it affect?
A chat log can prove that something was discussed, but it is poor at expressing which decision remains authoritative. File history can show that text changed, but not necessarily what that change means for the evidence chain. A notebook preserves cells, but those cells may have run in a nonlinear order.
The authors of Data Analysis in the Era of Generative AI describe analysis as repeated movement among task formulation, data collection, exploration, visualization, validation, and communication. The work was never a straight line. Agents speed up those iterations and multiply the branches, often beyond what one person can hold in working memory.
Why software’s Plan → Result history is not enough
Software development and data analysis both move from planning to execution to results, and both benefit from version control. What differs is the signal that tells us whether a path is valid.
Software certainly has hidden risks, but many failures produce direct feedback: code does not compile, a test fails, a type is incompatible, an API returns an error, or a diff clearly exposes a behavioral change. When an implementation passes its acceptance checks, a history from requirement to change to result often captures much of what matters.
The most dangerous analytical failures are technically successful and analytically wrong:
- The SQL runs, but a JOIN triples every order.
- The chart renders, but the denominator includes ineligible users.
- A replacement table has columns with familiar names but lacks the historical coverage required by the method.
- The notebook reports no error, but its cell execution order makes the result irreproducible.
- The number matches the prior version only because two mistakes cancel each other out.
The program can run successfully while the analysis remains invalid.
A record that says only “this Plan produced this Result, then a new Plan produced a new Result” misses the information that matters most: why the earlier path stopped, which assumptions were rejected, which partial findings remain usable, and whether the next path replaces, extends, or restarts the work.
AI scales silent failures along with output
An analyst who manually tries three queries will usually remember why the first was abandoned. An Agent can inspect ten tables, rewrite several queries, create intermediate results, and place one version of a number into charts and prose within minutes.
That speed is genuinely useful. It also makes four things easier to lose:
- The rejected path: why source A was unusable, rather than simply not selected.
- The reason for a transition: whether changing A to B fixed a bug, changed a definition, or introduced a new assumption.
- The identity of the evidence: which actual execution the report cites.
- The authoritative version: which of several apparently finished artifacts is the formal conclusion.
If this information exists only in chat, changing Agents, compacting context, or reopening the project a week later can turn a previously rejected path into a “new” idea and send the team down it again.
A failed analytical path should not be deleted or called complete
An analysis that cannot continue is not necessarily worthless.
Suppose a team plans to use event data to estimate a feature’s effect on 30-day retention. Validation reveals that historical events are retained for only 14 days. That path cannot answer the original question, but it may already have established the event definition, data quality, and usable date range. The right response is neither to delete the history nor label it “complete.”
It should say clearly:
- the path stopped; it did not succeed;
- it stopped because historical coverage was insufficient;
- these checks were completed and these partial findings remain valid;
- this new method or narrower scope replaces it.
That may look like a status-label distinction. In practice, it protects future humans and Agents: do not mistake a path already proven infeasible for one nobody has tried.
Data Lineage is not enough; we need Analysis Lineage
Data Lineage explains how data moves:
Raw source → Cleaning → JOIN → Aggregation → Dashboard
It helps a team understand which tables and reports an upstream change may affect. It does not usually explain why a table was selected, which metric definition was rejected, which execution supports a conclusion, or why a previous method stopped.
Analysis Lineage traces how a conclusion became justified:
Business question
→ Analytical paths, assumptions, and definitions
→ SQL / notebook executions that actually ran
→ Validation, partial results, and stop reasons
→ Charts, reports, and final conclusions
One does not replace the other:
Data Lineage traces how data moves. Analysis Lineage traces how a conclusion becomes justified.
A useful Analysis Lineage does not need to preserve every private reasoning token from an Agent, nor should it become an infinite chat backup. At minimum, it should let a person or an Agent answer five questions:
- Which formal artifact and execution produced the conclusion under discussion?
- Which data, query, definition, filters, and time range did it use?
- Which upstream analytical paths were stopped or replaced, and why?
- Which artifacts are formal evidence, and which are historical context or partial results?
- Is the evidence chain complete? If not, which link is missing?
This context has to live outside the chat
If Analysis Lineage is visible only to the current Agent, it is not a team asset. Built-in Agents, external Agents, and human reviewers should read the same relationships. Those relationships must remain with the analytical artifacts instead of depending on a particular conversation staying in context.
In Lantide Data, we apply this principle by connecting analytical Plans, stopped or replaced paths, executed results, and Reports. A user can inspect the Analysis Lineage directly, while an Agent can follow the same context from the current report back through upstream plans and evidence. That makes the next question, handoff, or rerun possible without reconstructing history from clues.
Whatever tools you use, a minimal rule is a good place to start: every formal conclusion must point back to executed evidence, and every abandoned path must retain its stop reason and replacement relationship.
Conclusion
AI Agents free analysts from manually performing every operation. They also make “I remember what I did” an inadequate foundation for trust. The next generation of analytical workflows cannot preserve only the final SQL and final report. It must retain the traceable relationships among the question, choices, failures, validation, evidence, and conclusion.
AI Agents make analysis faster. Analysis Lineage ensures we know where they actually took us.