Series Guide and Product Positioning

In one sentence: Lantide Data is a local-first data analysis IDE with a built-in Agent runtime (Harness) designed for analysts—reviewable deliverables, governed execution authorization, and querying and tooling unified with a DuckDB workspace, rather than "a chat window where you paste a CSV."

For step-by-step instructions, see the User Guide. This series explains why it is designed this way, and the product and engineering trade-offs behind it. For terminology, see the Appendix: Glossary at the end.

Series Position

Suggested order: Series Guide and Product Positioning → Agent-Era Data Analysis Workflow → Governable Agent Memory → Prompt and Context Engineering → AI Agent Architecture → Unified Query Layer.

1. What Gap Are We Filling

"AI can do data analysis" is no longer novel; the pain point is the lack of an Agent execution environment (Harness) purpose-built for analytical work.

Many people still cobble together an analysis chain using a general-purpose chat model plus an Excel / SQL client: fragmented tools, intermediate results that are hard to trace, and AI-generated SQL they dare not treat as a formal deliverable. To make "a dedicated analysis environment" clear, we can roughly divide the market into three tiers (for comparison, not a complete competitive map):

A Strong Representative in Tier C: Julius AI

Julius AI is a highly mature member of Tier C: upload CSV/Excel or connect Snowflake / BigQuery → natural-language Q&A → charts, statistics, notebooks, scheduled reports. Its product narrative emphasizes "no need to write SQL."

Behind the scenes, the model generates and executes Python / R / SQL inside a session sandbox—this can be called an analysis abstraction layer (the hidden DA, where the Data Analyst execution layer is concealed): trading hidden code for speed, with its strength in the Insights endpoint—getting quickly from data to charts and conclusions.

Common Gaps in This Kind of Harness

Belonging to Tier C does not mean the upstream and governance are already sufficient. The common trade-offs of Julius-style products are:

• Upstream preparation is mostly done inside the session: cleaning and alignment are hard to trace and hard to rerun as formal intermediate results.
• Delivery leans toward charts and conclusions: shareable, but the definition logic is hard to review, annotate, and sign off like a document.
• Workflow is conversation-driven: even with a notebook, there is still little boundary of "write the contract first, then formally run only after a human presses the button."

These gaps do not deny Tier C's value; they illustrate that the Harness already exists, but there is another route that puts more weight on traceable intermediate results, collaboratable definitions, and authorized Execute (the Silver / Insights stages of Medallion below)—and this is the route Lantide Data takes.

Therefore: What Lantide Data Aims to Fill

Our position is: analysis is not a one-off answer, but a set of work products that can be discussed, versioned, and rerun; the Agent should explore, draft, and execute within the same IDE, while humans retain the pace and authorization. Rather than building yet another "chat Harness that produces charts," we make the path leading up to insight a governable artifact within Tier C.

Differences from Julius-Style Harnesses

To help readers place the category and trade-offs, this is not a feature evaluation or market ranking. For the full SQL-first methodology, see Agent-Era Data Analysis Workflow §3.

An Analyst's Day: Pipeline Stages and Work Products

We borrow Medallion terminology to mark pipeline stages (not a claim that Lantide is in-warehouse ETL). The table below aligns a typical day with each stage—and also shows that Lantide's home turf is the traceable Silver and the sign-off-ready Insights, not merely competing for the endpoint charts:

The whole flow happens within the same IDE, not scattered across chat windows and spreadsheets.

Product boundaries (to tighten the scope): We are also not a general-purpose coding agent decoupled from the workspace (great at editing a repo, but unconcerned with Plan, Report, or cache lineage), nor a memory product that auto-feeds conversations into a vector store by default. In form, it is a local-first desktop analysis IDE (a local DuckDB carrying CSV / ATTACH / MCP) with an embedded ReAct Agent runtime (a state-filtered tool matrix + UICommand); cross-conversation definitions are written to the knowledge file only after approval via Queued Knowledge review, rather than accumulating in a black box.

Portability (.lantide): For sharing analytical context and results, use a Project export; for collaborative handoff or switching machines, use a Workspace (a Full backup moves multiple workspaces + the Application at once). Workspace / Full backup do not include local CSV/Parquet by default, but you can opt in to package physical data (choose either Extract on the new machine or Rebind to a local directory); all four export types can optionally be passphrase-encrypted at the outer layer. For selection and operation, see User Guide §11.1.0.

2. Series Structure

The main body has five articles: two on methodology (Workflow, Memory) + three on engineering support (Context, Agent architecture, Query layer). Together they explain how the Tier C (analysis Agent Harness) above is designed and implemented; missing any one link would degrade it into "a smart chatbot." For each article's core question, see §4.

3. What These Articles Answer

Lantide Data puts "querying local files with SQL" and "doing analysis with AI" in the same desktop IDE. What readers truly care about is often not just whether the model can write SQL, but:

• Can the analysis process be seen, reviewed, and traced?
• Where is the division of labor between humans and the Agent (who can Execute, who can change the Plan)?
• How are memory and context kept controllable, rather than piling up in a black box?
• Why build a custom Agent loop instead of adopting a general-purpose Agent framework?

This series answers the above with two articles on methodology (Agent-Era Data Analysis Workflow, Governable Agent Memory) and three on engineering support (Prompt and Context Engineering, AI Agent Architecture, Unified Query Layer); this article (Series Guide and Product Positioning) is responsible for the category and the reading map.

flowchart TB
  guide[Series Guide and Product Positioning]
  subgraph methodology [Methodology]
    workflow[Agent-Era Data Analysis Workflow]
    memory[Governable Agent Memory]
  end
  subgraph engineering [Engineering Support]
    context[Prompt and Context Engineering]
    agent[AI Agent Architecture]
    query[Unified Query Layer]
  end
  ug[User Guide_Operations]
  guide --> workflow
  guide --> memory
  workflow --> context
  memory --> context
  context --> agent
  agent --> query
  ug -.->|operational details| workflow

4. Overview of the Main Articles

5. Capability Map

6. How to Read This Series

By Role and Time

By Question

Each article opens with a "Series Position" table; for the complete guide, this article is authoritative.

7. Division of Labor with the User Guide

When there is overlap, the User Guide is authoritative; this series uses "see User Guide §X" to bring in operational details, without repeating lengthy step-by-step instructions.

8. Series Maintenance Conventions

A cross-article topic is written in full in only one article (SSOT), with the rest getting 1–2 sentences + a link. When patching in a new feature:

1. First check the table below to determine the authoritative article, then write it there.
2. Other articles only add a pointing link, without repeating the table.
3. Operational steps are still written only in USER_GUIDE.

Appendix: Glossary