Amazon shows agentic analytics architecture built on SageMaker, Athena and Quick

AWS has shown an architecture in which the agentic assistant Amazon Quick turns lakehouse analytics into self-service for business teams. The setup combines S3, SageMaker, AWS Glue and Athena so that users can ask questions about data in natural language rather than through SQL.

How the setup works

In its demonstration, AWS uses the TPC-H dataset and builds a multi-layer lakehouse on top of it. Data is stored in Amazon S3, metadata is managed through AWS Glue, and Amazon Athena serves as a single SQL layer for querying different storage formats. The example uses ordinary external CSV tables, Iceberg tables in Parquet and managed S3 Tables at the same time.

This approach is not about architectural elegance: the company is showing that the same business question can be directed at heterogeneous sources without manually building data marts for each scenario.

On top of this, Amazon Quick adds a user layer:

• SPICE datasets for fast answers and dashboards
• Topic as a semantic layer for business terms
• a dashboard with natural-language queries
• a Knowledge Base built from documentation and specifications
• Quick Space and a chat agent as a single interface

What the agent does

The key part is not just a chat over tables but the combination of Topic, Space and Knowledge Base. Topic acts as a semantic layer: it maps familiar phrasing such as revenue, customer segment or last quarter to specific fields, dates and filters in the dataset.

Inside Quick, data is first loaded into SPICE, so dashboards and answers to typical questions should run fast even as the source lakehouse grows. For large datasets, AWS advises joining tables in advance in Athena via Custom SQL and only then passing the flat result to Quick.

So that the agent answers with more than numbers, AWS adds unstructured context to the structured tables. The TPC-H specification in PDF is loaded into the Knowledge Base through a web crawler, and the Topic, the knowledge base and a ready-made dashboard are placed in a Quick Space. The chat agent then gets a single managed knowledge environment: it can answer questions about revenue and order statuses, and also pull field definitions, query business logic and the meaning of benchmark queries from the documentation. The idea is simple: one interface instead of a set of scattered BI screens and wiki pages.

Where the payoff is

For business, the main gain is that analytics stops being a queue to SQL specialists and the BI team. A user can ask in plain language about revenue by segment, order trends, discounts or product items and get an answer tied to data and visualizations.

AWS stresses separately that this model is meant for more than demo mode: access is restricted by roles, and visibility boundaries are inherited from IAM and Lake Formation. In other words, an employee sees only the tables, columns and sources they already have permissions for.

But the post also shows the price of this convenience. Before launch, you need to configure the Glue catalog, Lake Formation permissions, the Athena connection, SPICE loading, Topic, Space, the dashboard and a separate agent. AWS is not promising out-of-the-box magic: agentic analytics appears where a lakehouse, access models and careful data semantics are already in place. In exchange, the company gets a shorter path from question to answer and less manual work for analysts.

What this means

AWS is effectively promoting the next stage of BI: not a new dashboard, but an agentic interface layer on top of an existing lakehouse. If the approach catches on, business users will increasingly turn to data through conversation, and data teams will focus not on one-off exports but on the quality of models, permissions and context.