How Lantide lets external Agents keep their general capabilities, gives its built-in Agent deeper workflow integration, and connects both through one control plane
General-purpose Agents such as Codex and Claude can already organize documents, edit code, research topics, and connect tools. That creates a direct question for vertical applications: if users already have an Agent they know, why make them start another conversation and explain the context again?
Lantide's answer is to support both entry points, with different responsibilities. An external Agent keeps its reasoning and orchestration loop while Lantide exposes searchable analytics capabilities. The built-in Agent uses product state to integrate more deeply with the analysis workflow. Both ultimately operate on the same data, SQL, Plans, results, and Reports.
External Agents keep the broader task context
An external Agent may already have requirements, documents, code, and information from other systems in its conversation. When the task reaches data analysis, it should be able to use Lantide directly rather than move all that context into another chat.
Lantide exposes its capabilities through MCP. The external Agent decides how to decompose the task; Lantide reports the workspace state, available tools, and confirmation requirements. Because the catalog grows over time, the initial session exposes a compact core and lets the Agent search for long-tail capabilities such as statistics, HTML Report editing, or data-source management.
The external Agent already owns its loop. Lantide does not hide another Agent behind MCP to direct it; it acts as a governed analytics environment the general-purpose Agent can use.
The built-in Agent understands product state
When someone works directly in Lantide, the application knows which workspace and project are active and whether the user is exploring, planning, or executing an approved Plan. Those states determine which actions make sense.
During planning, the built-in Agent can inspect data, clarify the method, and create a Plan. After approval, it receives the tools for formal SQL execution, progress tracking, and Report creation. State and tool availability can update during the same turn.
The state machine does not perform the analysis for the model. It tells the model which stage it is in and which boundaries apply. It also lets the Agent integrate directly with the interface: SQL appears in real tabs, results enter the workspace, and approval pauses in the GUI.
Two Agents cannot create two domain models
Separate toolsets, permission systems, and document formats eventually diverge. Lantide keeps entry-point differences at the Agent layer and centralizes domain rules in a shared control plane.
The built-in Agent uses product states, Agent/Ask modes, and conversational confirmation. External Agents use MCP Access Modes, sessions, and execution approval. Both paths connect to shared tool definitions, domain services, artifact contracts, workspace permissions, and audit records.
Artifacts—not shared chat memory—make the two paths interoperable. SQL and Reports created externally return to Lantide for review; the built-in Agent can continue from the same artifacts. Both manage the same source registry, and the built-in writer pauses while an external writer owns the workspace.
What should a vertical application own?
As general-purpose Agents improve, vertical applications have less reason to rebuild general reasoning and orchestration. They still need to own their working world: the important objects, workflow transitions, confirmation boundaries, and definition of completion.
In Lantide, external Agents provide breadth, the built-in Agent provides domain depth, and the control plane ensures both operate on the same data and work products. An Agent can decide how to reason and plan; Lantide defines how the work happens and what counts as complete.