General-purpose Agents are already capable. People use Codex, Claude, and other Agents to organize documents, edit code, research topics, and connect tools to finish larger tasks.
That leaves vertical applications with a direct question: do they still need to build an Agent of their own?
If someone already has an Agent they know, why make them start a new conversation and explain the background again in every application? But if a vertical app only hands a set of tools to an external Agent, it is difficult to go deeply into the product's own workflow and state.
When I designed Lantide, my answer was to support both and give them different responsibilities.
An external Agent keeps its own reasoning and planning loop while Lantide provides searchable data analysis tools. Lantide owns the loop of its built-in Agent and uses a state machine to integrate it more deeply with the analytics workflow. Both entry points ultimately connect to one control plane and operate on the same data, SQL, Plans, results, and Reports.
An external Agent should not have to learn a second way of working
The main value of an external Agent is its generality.
The existing conversation may already contain requirements, documents, code, and information from other systems. When the task reaches data analysis, the Agent should be able to use Lantide directly instead of moving all that context into another chat.
Lantide therefore exposes its capabilities through MCP. The external Agent decides how to break down the larger task. Lantide tells it which tools are available, what state the workspace is in, and which actions require confirmation.
That creates a practical problem: the tool catalog keeps growing.
An early version exposed 114 tools in Admin mode. Their names, descriptions, and parameter schemas totaled about 158 KB. The capabilities were complete, but every Agent had to face the entire catalog as soon as it connected.
I later reduced the initial surface to 25 core tools and made the remaining capabilities searchable on demand. When an Agent needs statistics, HTML Report editing, or data source management, it searches in natural language and then calls the returned schema. The initial definitions fell to about 29 KB without removing the underlying capabilities.
The external Agent already has a loop. Lantide does not need to hide another Agent behind MCP to direct it. Lantide needs to be a data analysis environment that a general-purpose Agent can use well.
The built-in Agent understands product state
The fact that an external Agent can operate Lantide does not remove the value of a built-in Agent.
When someone works directly in Lantide, the product knows which workspace is open, which project has focus, and whether the user is exploring freely, planning an analysis, or executing an approved Plan. That state changes which actions make sense at a given moment.
This is why the built-in Agent uses a state machine.
During planning, it can inspect data, clarify the method, and create a Plan. Once execution begins, it receives the tools for formal SQL execution, progress tracking, and Report creation. When an action changes the project or Plan state, its tools and prompt update during the same turn.
The state machine does not perform the analysis for the model. The model still decides what to investigate and how to decompose the problem. The state machine tells it which stage of work it is in and what boundaries apply there.
The built-in Agent can also work directly with the interface. When it creates SQL, a real tab appears. When execution finishes, the result enters the workspace. When a decision requires approval, the flow pauses in the UI. That level of integration is difficult to create from an external tool description alone.
Two Agents cannot create two sets of domain rules
The easiest mistake when supporting both Agents is to build each path separately.
Two toolsets, two permission systems, and two document formats may look faster at first. They will eventually diverge, and work will stop carrying over when the user changes entry points.
I keep the differences at the Agent layer and bring the domain rules back into Lantide.
The built-in Agent has product states, Ask and Agent modes, and conversational confirmation. The external Agent has MCP Access Modes, sessions, and execution approval. Their entry-point governance differs, but both connect to shared tool definitions, domain services, and artifact contracts.
I call this layer Lantide's control plane. It manages workspace state, permissions, confirmation requirements, analysis objects, and execution records before sending work to the query, data source, and document services below it.
SQL and Reports created by an external Agent return to Lantide for continued review and editing. The built-in Agent can continue working on the same artifacts. Both paths update the same source state when they manage data sources. While an external Agent is writing, the built-in Agent pauses so they do not modify the same workspace at once.
Shared chat memory is not what lets the two Agents continue each other's work. Shared work products do.
What should a vertical application own?
As general-purpose Agents improve, vertical apps have less reason to rebuild capabilities those Agents already handle well. Users should be able to bring their Agent, context, and way of working with them.
A vertical application still has to own its working world: the objects that matter, how work progresses, which actions require confirmation, and what counts as complete.
The division in Lantide is clear. External Agents provide breadth. The built-in Agent provides domain depth. The control plane ensures that both operate on the same data and work products.
This design has a cost. Every capability has to account for built-in state and external permissions. Both entry points need validation. Tool search and state routing also have different failure modes. That cost does not buy another chat box. It lets Lantide be both a complete analytics product and an analytics environment that general-purpose Agents can use.
For vertical applications, the question is no longer whether to build an Agent. It is which layer of the product they need to keep under their own control.
My choice is this: an Agent can decide how to reason and plan; Lantide must define how the work happens and what counts as complete.