Enterprise Data Concierge

The problem

Data democratisation is a common goal, but most business intelligence tools stay too complex for the average business user. Anyone outside the data team who wants a non-trivial answer — say, a breakdown of one metric segmented by another with a qualitative filter on top — typically ends up filing a ticket with data engineering.

Days later they get back a static dashboard, and any follow-up question restarts the cycle. What is actually wanted is the ability to converse with the data in plain language and receive insights, charts, and summaries instantly, while the security posture around that data stays exactly as strict as it already is.

Why these patterns

Agent-native lakebase replaces the brittle text-to-SQL pipelines of early gen-AI demos. Rather than prompting an LLM to generate complex joined SQL against a legacy warehouse — which fails often and fails silently — the lakebase exposes governed data products the agent can reason about with confidence. The agent can orchestrate insight gathering across structured tables and unstructured text embeddings in a single, unified flow.

Zero trust agent security is the precondition for internal adoption. It is unacceptable for the agent to answer a question about restricted data simply because someone phrased the prompt creatively. In a zero-trust design there is no "agent god mode": every query the agent runs is executed under the requesting user's identity. If the user cannot see the underlying rows, neither can the agent acting on their behalf.

The MCP gateway extends the concierge from a read-only oracle into a functional assistant. Once a user identifies something worth acting on, they can instruct the agent to take a downstream step — creating a ticket, pausing a workflow, drafting a notification. The MCP gateway handles the authentication translation between the internal chat interface and the external systems, and keeps every action auditable.

What breaks without zero trust

The most common failure in enterprise internal AI is privilege escalation via prompt.

If the agent's backend service account is given broad read access to the underlying stores (on the assumption that filtering will happen at the application layer), it is only a matter of time before someone phrases a request that tricks the agent into surfacing data it should never have exposed. The model does not have to be adversarial for this to happen — a creative rephrasing is usually enough.

Zero trust closes the hole at the bottom of the stack rather than at the top. The identity context is carried all the way to the data execution layer. Even if the LLM generates a query it should not, the engine itself rejects the read because the execution context is bound to the limited permissions of the requesting user.

Operational considerations

Deploying a concierge successfully is mostly an exercise in managing expectations and access.

Continuous identity verification. Tokens expire. The system has to handle cases where an agent is midway through a multi-step task and the user's session ends, prompting for re-authentication gracefully rather than producing a confusing backend error.

Data quality dictates output quality. If the underlying data is messy, duplicated, or missing metadata, the agent will confidently produce incorrect insights in perfect sentences. The semantic layer needs to be governed rigorously — an agent cannot paper over bad data engineering.

Explainability of queries. Whenever the concierge presents a metric, it must also expose how it arrived there. A "show work" affordance that surfaces the specific queries or API calls the agent ran is what lets a technical user build trust — or catch a subtle error before it becomes a decision.