From 90 Minutes to Under 5: How Amazon Quick Is Putting Enterprise Data in Plain English

Data analysis just stopped being a specialist’s job. Amazon Quick, AWS’s AI-powered business intelligence tool, now lets any employee ask a dataset a question in plain language and receive a structured answer — complete with the SQL generated, the tools invoked, and the assumptions made — in seconds. The consequence is not incremental: according to AWS ML Blog, the AWS Technical Field Communities program cut query resolution time from 90 minutes to under 5 minutes after deploying Quick’s Dataset Q&A feature. That is an 18-fold compression of decision latency, achieved without retraining analysts or rebuilding data pipelines.

The mechanism behind this speed is a layered agentic system — a coordinated set of AI agents and foundation models (large AI systems trained on broad data, used here to interpret language and generate database queries) that interprets what a user actually means, not just what they literally typed. When a user asks about “escalations,” the system can correctly match that intent to a column labeled “tickets,” bridging the gap between business vocabulary and technical schema. This semantic understanding is what separates Amazon Quick from a simple query interface.

The broader shift is structural: conversational AI is moving data access from a gated, analyst-mediated process to an immediate, self-service capability. Dashboard creation that previously took days can now be completed in minutes, with early-access authors reporting reductions in creation time of 90 percent or more, as documented in the AWS ML Blog release notes. The question worth asking is whether that speed comes with hidden costs in transparency, auditability, and vendor dependency.

A Semantic Layer That Speaks Business, Not Just SQL

At the core of Amazon Quick is Dataset Q&A, which allows users to pose natural language questions directly to datasets. The system generates SQL automatically and returns results in seconds — but the more consequential feature is what happens alongside that answer. Chat explanations surface a full reasoning chain: which tools were invoked, what SQL was produced, and what assumptions the system made. This transparency is deliberate. Without it, a non-technical user has no way to judge whether the answer is correct or whether the system misread the question.

Semantic enrichment extends this further. Dataset authors can annotate their data with business context — defining what a column means in operational terms, not just its technical label. This author-supplied metadata feeds the AI’s understanding, improving accuracy before a single question is asked. The agentic system then uses a semantic layer to search across structured data assets and identify the right source for any given question, even when the user’s terminology does not match the underlying schema. For multi-step questions, the orchestrator — the component that plans and sequences the AI’s reasoning — identifies which specialized agents and tools to invoke at each step, then assembles a coherent answer from multiple capabilities. This is not keyword search with a conversational wrapper; it is intent-driven query planning.

The infrastructure layer has also been updated: Amazon Quick now connects directly to Apache Iceberg tables stored in S3 buckets without requiring an intermediate query engine. Authors can choose between SPICE mode, optimized for high-concurrency sub-second dashboards, or Direct Query mode, which prioritizes data freshness. In Direct Query mode, both dashboards and AI agents read from the same live data — eliminating the synchronization lag that has historically made real-time BI unreliable. As the AWS ML Blog puts it: “Talk to your data directly.”

Speed Claims, Vendor Lock-In, and the Auditability Gap

The performance numbers attributed to the AWS Technical Field Communities program are striking. AWS ML Blog states that query accuracy improved by over 48 percent and resolution time dropped from 90 minutes to under 5 minutes using Dataset Q&A. These figures, if replicable, would justify serious enterprise attention. But they are vendor-reported metrics from a single internal program — not independently audited results. A cautious CTO would ask: under what query complexity? With what data quality? Across how many users? The AWS ML Blog does not answer those questions, and the absence of a controlled baseline makes the 48 percent accuracy improvement difficult to interpret without additional context.

The deeper structural concern is orchestration opacity. Amazon Quick’s agentic system coordinates multiple foundation models, a semantic layer, specialized sub-agents, and an orchestrator that plans multi-step reasoning sequences. Each of those layers is managed by AWS. When the system produces a wrong answer — and it will — diagnosing the failure requires access to the reasoning chain that Quick exposes through chat explanations. But that chain is a summary, not a full audit trail. Enterprises accustomed to inspecting SQL queries in traditional BI tools will find that the locus of control has shifted: the logic now lives inside a vendor-managed AI stack, not in a query file they can version-control or modify independently. This is a meaningful governance trade-off, not a footnote.

The effectiveness of the semantic enrichment layer also depends entirely on the quality of the annotations that dataset authors provide. If business definitions are incomplete, inconsistent, or outdated, the AI’s accuracy degrades — and the user has no direct signal that the enrichment layer is the source of the error. The system’s confidence in its answers does not automatically reflect the quality of the metadata it was given. Enterprises considering Amazon Quick should treat semantic enrichment as an ongoing data governance discipline, not a one-time setup task.

Editorial note: This article summarizes AWS ML Blog’s own product material, not independent reporting. Time-to-value, speed, and ROI statements reflect the publisher unless outside evidence is cited. Original post.

Analysis based on reporting by AWS ML Blog. Original article here.