Amazon unveiled an agentic analytics architecture based on SageMaker, Athena, and Quick

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

How the Architecture Works

In the demonstration, AWS uses the TPC-H dataset and builds a lakehouse with multiple layers on top of it. Data is stored in Amazon S3, metadata is managed through AWS Glue, and Amazon Athena becomes a unified SQL layer for queries across different storage formats. The example simultaneously uses regular external CSV tables, Iceberg tables in Parquet, and managed S3 Tables. This approach isn't just for architectural elegance: the company shows that the same business question can be addressed to heterogeneous sources without manual construction of data marts for each scenario. On top of this, a user layer is assembled in Amazon Quick:

• datasets in SPICE for fast answers and dashboards
• Topic as a semantic layer for business terms
• dashboards with natural language queries
• Knowledge Base based on documentation and specifications
• Quick Space and chat agent as a unified interface

What the Agent Does

The key part is not just a chat over tables, but a combination of Topic, Space, and Knowledge Base. Topic acts as a semantic layer: it links familiar formulations like 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 work fast even as the source lakehouse grows.

For large datasets, AWS recommends pre-combining tables in Athena via Custom SQL, then passing the flat result to Quick. To make the agent answer not just by numbers, AWS adds unstructured context to the structured tables. In the Knowledge Base, a web crawler loads the TPC-H specification in PDF, and in Quick Space, Topic, the knowledge base, and a ready-made dashboard are assembled.

After that, the chat agent receives one managed knowledge loop: it can answer questions about revenue and order statuses, and at the same time extract field definitions, business logic of queries, and the meaning of benchmark queries from documentation. The idea is simple: one interface instead of a set of disparate BI screens and wiki pages.

Where the Effect Lies

For business, the main benefit is that analytics stops being a queue to SQL specialists and BI teams. The user can ask about revenue by segment, order dynamics, discounts, or product items in ordinary language and get an answer tied to data and visualizations. AWS particularly emphasizes that this model is designed not only for demo mode: access is restricted by roles, and visibility boundaries are inherited from IAM and Lake Formation.

That is, an employee sees only those tables, columns, and sources for which they already have permissions. But the post simultaneously shows the price of such convenience. Before launch, you need to configure the Glue catalog, Lake Formation permissions, Athena connection, loading into SPICE, Topic, Space, dashboard, and a separate agent.

That is, AWS doesn't promise out-of-the-box magic: agentic analytics appears where a lakehouse, access models, and careful data semantics are already in place. But in return, the company gets a shorter path from question to answer and less manual work on the analytics side.

What This Means

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