Architecture Overview

This page shows how Agent Studio is put together: where requests enter, what the runtime is responsible for, and which systems it talks to. It is written for architects and platform teams evaluating Agent Studio for an enterprise deployment.

For the identity and permission checks applied along these paths, see the Security section.

System architecture

Agent Studio sits between the channels your users already work in and the systems that hold your data. Every channel converges on the same runtime, so agents behave the same way regardless of where they are invoked from.

Three properties of this layout matter for an enterprise review:

1. One runtime, many channels. Slack, MCP clients, the web UI, plugins, and the REST API all call the same agents and tools, so access rules are defined once and enforced everywhere.
2. The Knowledge Layer is the grounding source. Agents retrieve catalog context and data product definitions through tools, which means responses inherit the governance already applied in Alation.
3. Warehouse access is mediated. Agents never hold raw database credentials. Queries run through stored connection credentials that Alation resolves per user and per data product.

The layers, bottom to top

Layer	What it provides	Where it is documented
Alation Knowledge Layer	Trusted catalog metadata and data products that ground every agent	Key concepts
LLMs	Reasoning over user intent; OpenAI, Anthropic, or your own model	Models
Tools	Actions an agent can take: search the catalog, run SQL, generate charts	Tools
Agents	LLM + prompt + tools, composed to complete a task	Agents
Flows and schedules	Multi-step orchestration and recurring runs	Flows
Channels	Slack, plugins, MCP, REST API, SDK	Integrations

Deployment models

Agent Studio runs in two deployment models.

Alation Cloud (default)

The Agent Studio runtime runs in Alation’s cloud alongside your Alation instance. Requests from your users reach Alation over TLS, and warehouse queries are executed through the same connections your catalog already uses.

Zero Data

In a Zero Data deployment, customer data never passes through Alation’s cloud. The runtime runs on a k3s-based agent inside your environment, next to your databases and your LLM endpoint, and reaches back to Alation’s cloud only for catalog metadata and session context over an mTLS tunnel.

Choose Zero Data when your security policy requires that query results and LLM traffic stay inside your network boundary.

Zero Data overview The Zero Data topology in detail, including the in-environment components.

Zero Data infrastructure requirements The PostgreSQL, Redis, and LLM endpoints you provision before installing.

Where identity is enforced

Every hop in the diagrams above re-checks the caller’s identity. The Security section traces a single request end to end and documents the one place where identity is translated (the warehouse hop).

For security reviews

Start with the request lifecycle page. It answers the most common security-review question, “whose identity is used at each step?”, with a hop-by-hop diagram.