Amazon Quick Suite’s semantic layer runs on what AWS calls Topics, joining the same category as Snowflake’s semantic views, Databricks’ Unity Catalog Metrics, dbt’s Semantic Layer, and Atlan’s Enterprise Data Graph: business logic that turns raw warehouse fields into terms your team and its AI agents can query consistently. A single Topic joins up to 12 datasets, each needing its own metadata first.
That’s the whole idea behind a semantic layer: one governed definition of “revenue” that every dashboard, chat query, and AI agent resolves the same way, instead of guessing from a raw column name. Quick Suite builds that through business rules, relationships, synonyms, and calculated fields attached to whatever datasets you’ve loaded. A full context layer extends that same idea past Quick Suite’s boundary.
- Topics are dataset-bound: relationships, synonyms, and calculated fields exist inside a single Topic, not your whole data estate.
- A Topic joins up to 12 datasets before you need a second model, and each dataset needs its own metadata first.
- AWS is moving the same logic into the dataset itself through semantic datasets, one governed asset instead of two.
- Every answer routes through Quick Suite’s own chat and analysis sheets, nothing outside it.
Below: how Topics work, what changed with semantic datasets, where this layer earns its keep, where it runs out of road, and how it compares to one built for every system an enterprise runs.
| Aspect | Detail |
|---|---|
| What it’s called | Topics (multi-dataset semantic layer), evolving toward semantic datasets |
| Where it lives | Amazon Quick Suite, formerly QuickSight, renamed again to Amazon Quick in 2026 |
| Scope per Topic | Up to 12 datasets, SPICE or Direct Query, not mixed in the same model |
| What it defines | Relationships, synonyms, calculated fields, custom instructions, semantic types |
| Who can query it | Quick Suite chat and analysis sheets only |
| Announced | QuickSight to Quick Suite: October 9, 2025. Multi-dataset Topics and semantic datasets: 2026 |
What is Amazon Quick Suite, and where do Topics fit?
Permalink to “What is Amazon Quick Suite, and where do Topics fit?”Amazon Quick Suite is the BI-plus-agent workspace that used to be Amazon QuickSight, and Topics do the semantic-layer work described above. AWS renamed QuickSight to Amazon Quick Suite on October 9, 2025, folding BI together with a chat agent, research, and workflow automation under one name, per AWS’s own announcement. By 2026, AWS shortened that again to Amazon Quick, with BI surviving inside it as a component still called Quick Sight.
This page stays narrowly on the semantic layer. For the full picture, see what Amazon Quick Suite actually is and Amazon Quick Suite vs. Atlan for data catalog. Every BI platform with a chat interface needs a way to ground its answers, and Atlan’s research into metadata AI agents actually need shows why: an agent looking at a column named cust_seg_cd has no way to know it means enterprise customer, so it guesses.
The name has changed three times since 2020. What hasn’t changed is the boundary around the feature, and that boundary is the real story here.
What is a semantic layer, and how does Quick Suite build one?
Permalink to “What is a semantic layer, and how does Quick Suite build one?”A semantic layer is the governed translation layer between raw data and the people and AI agents asking questions of it: it maps technical fields to approved business terms so a metric means the same thing everywhere, per Atlan’s own definition. Quick Suite builds that layer through an object it calls a Topic.
AWS defines a Topic as the multi-dataset semantic layer bringing enriched datasets into a unified data model, letting Quick Suite perform runtime joins whether you’re building analysis visuals or asking a question through chat. That puts Quick Suite in the same category as Snowflake’s semantic views, Databricks’ Unity Catalog Metrics, and dbt’s Semantic Layer, the broader class of semantic layers built for analytics: platform-native logic, built to serve the platform it lives in first. It’s a different question than the one an ontology answers; a Topic resolves “how much revenue did we make,” not “what is a customer.”
Where Quick Suite’s Topic sits on Atlan’s four-level semantic maturity model, physical, logical, universal, active, matters more than what AWS calls it this year. It’s logical, BI-embedded, with an agent chat bolted on, not universal or active, and that ceiling shows up the moment your data lives anywhere else.
How do Topics work in Amazon Quick Suite?
Permalink to “How do Topics work in Amazon Quick Suite?”A Topic starts with the datasets underneath it, and each needs its own semantic metadata before joining the model. AWS’s 2026 blog on multi-dataset Topics lays out the mechanics: normalized sources, enriched datasets, a unified Topic holding the relationships, and consumption through chat or analysis sheets.
| Element | What it defines |
|---|---|
| Relationships | Join keys mapped between dataset pairs, for runtime joins |
| Synonyms | Alternative terms for a column, so “headcount” resolves without a matching name |
| Semantic types | Tags like City, State, Currency, or Date that sharpen field interpretation |
| Custom instructions | Plain-language rules guiding disambiguation |
| Calculated fields | Metrics computed across datasets inside the same Topic |
Quick Suite chat maps terms to columns, traverses relationships for the join path, generates SQL, and returns a visualization with that SQL available for inspection. AWS describes the agent as one that “traverses relationships across datasets, generates cross-dataset SQL with appropriate joins, and returns unified answers.” A text-to-SQL engine is only as accurate as the SQL intelligence underneath it, exactly what a Topic’s metadata supplies.
Star-schema modeling is the recommended shape; AWS discourages circular joins and many-to-many relationships, and a Topic maxes out at 12 datasets before a split. Every rule above lives inside one Topic, one workspace: enough structure for one BI surface, not yet the shared vocabulary an enterprise needs across every tool touching the same data.
Legacy Topics vs semantic datasets: what changed in 2026
Permalink to “Legacy Topics vs semantic datasets: what changed in 2026”AWS is restructuring where this business logic lives, and the direction matters more than the old object model. The original architecture, now a legacy Topic, stores relationships, synonyms, custom instructions, and calculated fields as a separate object linked to a dataset.
The newer approach, semantic datasets, bakes that context directly into the dataset’s own metadata, per AWS’s 2026 migration guide: one asset to permission and audit instead of two, with dependent assets inheriting definitions automatically. Migration isn’t automatic; it requires a dataset on the newer data-prep architecture and a script that extracts the Topic’s metadata and reapplies it.
Folding the layer into the dataset is a genuine improvement over a traditional data mart’s duplicated logic. It still doesn’t cross Quick Suite’s boundary: a semantic dataset governs one dataset in one AWS service, not the CRM or ticketing system where the same customer record also lives, exactly the gap between a semantic layer and a data catalog.
Where does Quick Suite’s semantic layer earn its keep?
Permalink to “Where does Quick Suite’s semantic layer earn its keep?”Topics do real work for a specific kind of team: one standardized on Quick Suite for BI, with data in a small number of SPICE or Direct Query datasets, asking questions through Quick chat. There’s no separate product to buy, since Topics ship inside the same platform as the dashboards.
Enrichment gets authored once per dataset and reused across sheets and chat, a real gain over rebuilding join logic in every workbook. Teams already running Amazon Bedrock agents, or comparing AWS DataZone against Glue Data Catalog, get a natural on-ramp.
For a single-platform team, that’s a legitimate reason to use what’s there. The tradeoff shows up the moment a second BI tool, cloud, or AI agent enters the picture, which is most enterprises.
Where does Quick Suite’s semantic layer run out of road?
Permalink to “Where does Quick Suite’s semantic layer run out of road?”The same design that makes Topics fast to stand up limits them outside Quick Suite. A Topic tops out at 12 datasets; a bigger model needs a second Topic, and the two don’t share definitions. A Topic also can’t mix SPICE and Direct Query datasets in one model.
The bigger limit is consumption. AWS lists exactly two places to use a Topic, analysis sheets and Quick chat, and neither is a third-party tool. Extending those rules to Salesforce, Zendesk, or a warehouse Quick Suite doesn’t already read from means loading that data in first, the same catalog-versus-context-layer gap that shows up whenever a platform’s own metadata store stops at its own edge.
Most enterprises don’t run one BI platform. Forrester analyst Boris Evelson found that 61% of organizations use four or more, with 25% running ten or more, which is why teams comparing AWS-native graph options like Amazon Neptune hit the identical wall from a different angle.
Why do AI agents need more than a BI-embedded semantic layer?
Permalink to “Why do AI agents need more than a BI-embedded semantic layer?”AI agents fail the same way analysts used to when a term is ambiguous, except an agent acting on a wrong number inside an automated workflow rarely gets a chance to double-check it first. Gartner projects that by 2027, organizations that prioritize semantics in AI-ready data will see up to 80% higher agentic AI accuracy and up to 60% lower costs, exactly the gap between a definition an agent can see and one it can’t.
That gap widens once a question involves more than one agent. In agent-to-agent workflows, where an orchestrator delegates sub-tasks to specialized agents, every agent in the chain needs the same definitions or the results won’t reconcile. It’s the same split that separates agent memory from RAG and a knowledge graph: a semantic layer scoped to one dataset universe grounds one agent’s queries; it can’t ground a knowledge graph built for a whole fleet of agents touching different systems.
The industry is building a cross-vendor answer to this. The Open Semantic Interchange specification, finalized in January 2026, lets a semantic layer on one platform expose its definitions to agents built on another. Snowflake, Salesforce, dbt Labs, and Atlan are named partners; as of the current list, AWS is not, so a Topic’s definitions have no standard way out of Quick Suite even as the rest of the industry builds toward one. That’s why enterprises reach for an agent context layer instead of stopping at one platform’s built-in vocabulary.
The question worth asking isn’t whether Topics count as a semantic layer. They do. It’s whether the agent asking only ever needs data Quick Suite already has, and for most enterprises running AWS alongside a dozen other systems, that answer is no.
How does Quick Suite’s semantic layer compare to a cross-system one?
Permalink to “How does Quick Suite’s semantic layer compare to a cross-system one?”Quick Suite’s Topics and a cross-system semantic layer solve the same problem at different altitudes: the difference is scope, not sophistication.
| Dimension | Amazon Quick Suite (Topics) | A cross-system context layer |
|---|---|---|
| Scope | Up to 12 datasets loaded into Quick Suite | Metadata across 100+ systems, AWS and beyond |
| Consumption surface | Quick Suite chat and analysis sheets only | Any tool or agent, via MCP server (built for enterprise data) |
| Governance | Business rules per dataset or Topic | Lineage, ownership, and access policy at query time |
| Maturity tier | Logical, BI-embedded, agent chat added | Active, metadata-governed |
| Best fit | Teams standardized on Quick Suite for BI | Agents that need data outside one platform |
Neither replaces the other for most AWS shops. Topics ground business users’ questions inside Quick chat well. Reading that same metadata, along with Snowflake and Databricks, through the same MCP servers, lets every agent get the same answer, not just the one inside Quick Suite. See implementing an enterprise context layer for AI for what that build actually takes.
The real decision was never one platform versus another. It’s whether the layer your agents rely on stops at one AWS service’s edge, or follows the data wherever it lives, a question that belongs to whoever owns AI governance as much as the team building the Topic.
The real limit isn’t Topics. It’s the boundary around them
Permalink to “The real limit isn’t Topics. It’s the boundary around them”Topics are a well-built feature. AWS gave Quick Suite a real semantic layer: relationships, synonyms, custom instructions, calculated fields, and now, through semantic datasets, a cleaner way to keep that logic attached to the data it describes. None of that is a criticism of the engineering.
The criticism, if there is one, is of the boundary around it. A Topic knows what “enterprise customer” means for the 12 datasets loaded into it, not what the same term means in Salesforce, a warehouse outside AWS, or the ticketing system a CX team runs. That’s not a bug AWS needs to fix. It’s the nature of a semantic layer built into a single platform: it can only govern what it can see.
Most enterprises don’t run one platform. Forrester puts the median enterprise on four or more BI tools alone, before counting the CRM, the support desk, and whatever agent framework engineering adopted this quarter. A semantic layer scoped to one tool answers correctly inside it and guesses everywhere else. Teams getting real accuracy out of their AI agents treat the layer as infrastructure built to survive every system an agent touches, not a feature that shipped with the BI tool they bought first.
Frequently asked questions
Permalink to “Frequently asked questions”1. What is Amazon Quick Suite’s semantic layer called?
Permalink to “1. What is Amazon Quick Suite’s semantic layer called?”A Topic, or for newer datasets, a semantic dataset: the object storing relationships, synonyms, custom instructions, and calculated fields so Quick Suite’s chat answers accurately. Semantic datasets fold that same information into the dataset directly.
2. How many datasets can one Topic in Amazon Quick Suite join?
Permalink to “2. How many datasets can one Topic in Amazon Quick Suite join?”Up to 12. AWS recommends a star-schema shape and advises against circular joins or many-to-many relationships, which make SQL generation less reliable.
3. What is the difference between a legacy Topic and a semantic dataset?
Permalink to “3. What is the difference between a legacy Topic and a semantic dataset?”A legacy Topic is a separate object linked to a dataset. A semantic dataset bakes those rules into the dataset’s own metadata: one asset to audit instead of two, with definitions inherited automatically.
4. Does Amazon Quick Suite’s semantic layer work outside Quick Suite?
Permalink to “4. Does Amazon Quick Suite’s semantic layer work outside Quick Suite?”No. It answers questions inside Quick Suite’s own chat and analysis sheets, not through a standard API any other tool or agent can call.
5. Is Amazon Quick Suite the same as Amazon QuickSight?
Permalink to “5. Is Amazon Quick Suite the same as Amazon QuickSight?”QuickSight was renamed Amazon Quick Suite on October 9, 2025, then shortened again to Amazon Quick in 2026. BI survives inside it as a component still called Quick Sight.
6. Does Amazon Quick Suite’s semantic layer replace a data catalog?
Permalink to “6. Does Amazon Quick Suite’s semantic layer replace a data catalog?”No. A Topic defines business terms for queries; it doesn’t document what data exists or how it moves between systems. AWS Glue Data Catalog remains the separate metadata store underneath.
7. Can Amazon Quick Suite’s Topics ground AI agents built outside AWS?
Permalink to “7. Can Amazon Quick Suite’s Topics ground AI agents built outside AWS?”Not directly. Topics answer through Quick Suite’s own chat. An agent on a different framework needs its own connection to that data, or a context layer that unifies both.
Sources
Permalink to “Sources”- Reimagine Business Intelligence: Amazon QuickSight Evolves to Amazon Quick Suite. AWS, October 2025. https://aws.amazon.com/blogs/business-intelligence/reimagine-business-intelligence-amazon-quicksight-evolves-to-amazon-quick-suite/
- Build a Unified Semantic Layer Across Datasets With Multi-Dataset Topics in Amazon Quick. AWS, 2026. https://aws.amazon.com/blogs/machine-learning/build-a-unified-semantic-layer-across-datasets-with-multi-dataset-topics-in-amazon-quick/
- Enrich Your Datasets With Business Context: Migrating to Semantic Datasets in Amazon Quick. AWS, 2026. https://aws.amazon.com/blogs/machine-learning/enrich-your-datasets-with-business-context-migrating-from-legacy-topics-to-semantic-datasets-in-amazon-quick/
- Working With Amazon Quick Sight Topics. AWS Documentation. https://docs.aws.amazon.com/quick/latest/userguide/topics.html
- AWS Transform Now Offers BI Migration Agents for Power BI and Tableau to Amazon Quick. AWS, May 2026. https://aws.amazon.com/about-aws/whats-new/2026/05/quick-bi-migration/
- Gartner Announces the Top Data & Analytics Predictions. Gartner, June 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-17-gartner-announces-top-data-and-analytics-predictions
- The BI Fabric Baby Is Slowly But Surely Growing Up. Forrester. https://www.forrester.com/blogs/the-bi-fabric-baby-is-slowly-but-surely-growing-up/
- Announcing the Agent2Agent Protocol (A2A). Google, April 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
- Market Guide for Active Metadata Management. Gartner. https://www.gartner.com/en/documents/4004082
- Open Semantic Interchange (OSI) Specification. https://open-semantic-interchange.org/
- Amazon Takes on Microsoft and Google With New “Quick Suite” AI Platform. GeekWire, October 2025. https://www.geekwire.com/2025/amazon-takes-on-microsoft-and-google-in-the-workplace-with-new-quick-suite-business-ai-platform/
Topics are what a well-resourced cloud vendor builds when it takes the semantic layer seriously. That’s real, and it’s still bounded by the same wall every platform-native semantic layer runs into: it governs what it can see, and an enterprise’s AI agents almost always need to see further.
