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.
Source link







