Build a semantic layer for agentic AI on AWS with AtScale and Amazon Bedrock AgentCore

In the first post in this series , we built a semantic layer on AWS using Stardog’s knowledge graph over Amazon Aurora and Amazon Redshift . We ran a Strands agent on Amazon Bedrock AgentCore against that layer. The second post kept the same customer 360 (C360) pattern and swapped in Denodo’s data virtualization platform, extending the source mix to include an on-premises PostgreSQL cluster. This post uses the same C360 pattern again, with AtScale as the semantic layer. AtScale takes a different shape from the first two. The semantic model is dimensional (dimensions, hierarchies, and measures) rather than a graph of triples or a set of views. AtScale authors the model in the Semantic Modeling Language , an open, YAML-based specification versioned in Git, and exposes it simultaneously, from a single deployed model, over three protocols: SQL, XML for Analysis (XMLA), and the Model Context Protocol (MCP). The Strands agent and the business intelligence (BI) tools the enterprise already uses get the same computed answer from the same definitions. The rest of the pattern carries over from the earlier posts. A foundation model on Amazon Bedrock (Anthropic Claude Sonnet 4.6 for the walkthrough) plans and writes queries. Amazon Bedrock AgentCore hosts the Strands agent and manages the outbound credential the agent presents to AtScale. The joins, metric definitions, and row and column filters that apply to the caller live inside the semantic layer rather than the prompt. We assume you’re familiar with the semantic-layer architecture from the first post in the series: what a semantic layer is, what it’s for, and why the model plans queries without owning the joins. If any of that is new, the first post covers the ground. By the end of this post, you will know: How to model a C360 domain in the Semantic Modeling Language (SML): datasets, dimensions and hierarchies, facts, measures, calculated measures, and perspectives, versioned in Git. How AtScale plans a dimensional query against Amazon Redshift, and how AtScale’s autonomous aggregate management accelerates the query patterns an agent generates. How to expose the model to an AgentCore-hosted Strands agent through the AtScale MCP server, and how to register that MCP server with AgentCore Gateway , a capability of Amazon Bedrock AgentCore. How the human user’s identity propagates from the enterprise identity provider through AgentCore Identity, a capability of Amazon Bedrock AgentCore, to AtScale, and how AtScale enforces role-based access control (RBAC), row security, and perspectives at query time. How to deploy AtScale on Amazon Elastic Kubernetes Service (Amazon EKS) using the AtScale Helm chart and the AtScale K8S Blueprints repository. The source of truth for the walkthrough is the AtScale C2026.7 release . Where a specific tool name or endpoint applies, we cite the AtScale documentation . The example: Customer 360 on Amazon Redshift The customer 360 pattern from the first two posts stays in place. A retail enterprise has customer records, orders, products, and rewards enrollments spread across systems, and business users want to ask cross-cutting questions without knowing which system holds which fact. The Stardog C360 Knowledge Kit we adapted for the first post in the series models this scenario with Customer, Order, Product, and Address entities joined on an integer cid that appears as a primary key in the customer table and as a plain column in the purchase table. Where this post differs from the first two is where the data physically sits. Stardog and Denodo federate at query time across two engines. AtScale plans a dimensional query as native warehouse SQL and pushes it to one engine per query, so cross-engine data is consolidated upstream. For this walkthrough, all analytical C360 data lives in Amazon Redshift Serverless . Amazon Aurora PostgreSQL remains the operational system of record, and a replication path ( AWS Database Migration Service or Amazon Aurora zero-ETL to Amazon Redshift ) keeps the analytical copy current. The agent queries a single AtScale model that maps to the Amazon Redshift tables. The schema in Amazon Redshift: Table Key columns customer cid (PK), first_name, last_name, email, ssn, phone, location address id (PK), city, state, zip, street_name credit_card id (PK), cid, card_num, card_type rewards_account id (PK), cid, account_id, create_date purchase id (PK), pid, purchase_date, quantity, price, cid, card product id (PK), name, brand, price, dept category id (PK), dept_name, parent vendor id (PK), vendor_name, industry Nine columns of interest across eight tables. cid links customer records to purchases. pid links purchases to products. dept links products to categories. Everything analytical is in Amazon Redshift, so joins push down to native SQL rather than being resolved in the semantic layer or in an extract, transform, and load (ETL) pipeline. A representative question that exercises the whole model: Which of our top 20 customers by lifetime spend haven’t enrolled in the rewards program yet? This is the auto-enrollment question from the Denodo post, carried over so a reader following the series can see the same request answered by a different semantic layer. It touches customer profile, address, purchase history, and enrollment status: one row per customer across four logical entities. AtScale terms used in this post AtScale implements the semantic layer as a dimensional model over a warehouse. The AtScale documentation and the SML specification use a specific set of primitives that come up throughout this post. A short reference is useful before we get to the walkthrough. Semantic Modeling Language (SML) – An open, YAML-based specification for describing semantic models. Every SML object (model, dataset, dimension, hierarchy, metric, calculation, perspective, row security) is a YAML file. The specification lives at github.com/semanticdatalayer/SML . Model – The top-level artifact. A model references datasets, dimensions, facts, and metrics, and exposes them through the AtScale query engine. Dimension and hierarchy – A dimension groups related attributes (customer, product, date). A hierarchy inside a dimension organizes those attributes into levels (product → category → department, or year → quarter → month → day). Fact and measure – A fact is a dataset that holds measurable events joined to dimensions on key columns. A measure is a quantity aggregated from a fact column, for example SUM(price * quantity) for revenue. Calculation – A derived measure expressed as a formula against other measures. Perspective – A publishable subset of the model exposed to a specific role or group. Perspectives are how AtScale controls which dimensions and measures a caller can see. Row security – A model object that filters rows returned to the caller based on the caller’s identity or attributes. Autonomous aggregate management – AtScale watches query patterns across consumers and materializes summary tables in the warehouse when a pattern is expensive enough to justify one. Subsequent queries that match the pattern route to the aggregate transparently. Design Center – The AtScale authoring surface. A modeler edits SML through a visual canvas or a text editor. Either way the artifact on disk is SML YAML in Git. AtScale MCP server – The in-product MCP endpoint at /mcp that exposes the semantic model to any MCP client. Where more detail is useful, the AtScale documentation and the SML specification are the authoritative references. Reference architecture The runtime splits into an inbound path and an outbound path, following the same shape as the Stardog and Denodo posts. Inbound. A client sends the user’s question to the Strands agent through AgentCore Gateway. Gateway validates the JSON Web Token (JWT) that identifies the human user against the enterprise identity provider (IdP), then routes the request to AgentCore runtime (a capability of Amazon Bedrock AgentCore), whi