AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。
This post is co-written with Zhili Cheng, Principal Product Manager, George Earle, Director, AI Engineering, and Kyler K, Sales Engineer of Strategy. 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 and 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 Strategy Mosaic as the semantic layer. Stardog’s semantic layer is ontology-based: concepts and relationships modeled as RDF, with IRIs as the unit of federation and SPARQL as the query language. Denodo’s is data virtualization: base and derived views composed in VQL. Mosaic’s is dimensional: attributes, hierarchies, facts, and metrics composed through Strategy’s metric expression syntax, with linked models as the unit of federation. That model serves four native protocols from one definition: Model Context Protocol (MCP) for AI agents, JDBC/ODBC over Trino for SQL clients, XMLA for Power BI and Excel, and REST for custom applications. Behind those protocols is a long list of certified data sources. Supported systems include cloud warehouses such as Snowflake and Databricks. Operational databases include Amazon Relational Database Service (Amazon RDS), Oracle, and SQL Server. Analytical engines include Amazon Athena, Trino, and SAP HANA, and software as a service (SaaS) sources include Salesforce. The linked-model pattern extends beyond the Amazon Redshift and Amazon Aurora pair this walkthrough uses. In this walkthrough, a Strands agent hosted on AgentCore runtime, a capability of Amazon Bedrock AgentCore, reaches Mosaic through the MCP endpoint. The joins, metric definitions, and per-caller row and column filters live inside Mosaic, not in the agent prompt. We assume you’re familiar with the semantic-layer architecture from the first post in the series. If any of it is new, the Stardog post covers the ground. By the end of this post, you will know: How to model a C360 domain in Strategy Mosaic across Amazon Redshift and Amazon Aurora using two linked models, with no ETL. How Mosaic’s metric syntax (base, advanced with named filter objects, level qualifiers, and compound) captures the business definitions the agent must reason over. How to expose the model to an AgentCore-hosted Strands agent through the Mosaic MCP server, and how user identity propagates so per-user Row-Level Security (RLS) and Object-Level Security (OLS) hold end-to-end. How to choose between live pushdown and in-memory execution for agent traffic. How to publish the same governed definitions to Power BI, Tableau, notebooks, and custom apps, and how to export them in Apache Ossie format for tools outside Mosaic. The source of truth for the walkthrough is Strategy One (March 2026), the release when Mosaic access through the MCP server became available by default. Strategy Mosaic terms used in this post A short reference before we get to the model. Mosaic Schema and Mosaic Models. Two modeling paths within one universal semantic layer. Mosaic Schema is the centrally governed enterprise model. Mosaic Models is the self-service, AI-assisted modeling path in Mosaic Studio. Models can map to Schema attributes and inherit dimensions, object ACLs, and RLS. This walkthrough uses Mosaic Models. Model. The top-level artifact within either modeling path. Publishes attributes, metrics, hierarchies, and security rules over physical tables. The walkthrough uses two Mosaic Models, one over Amazon Redshift and one over Aurora, linked together. Attribute. A business entity such as Customer. Carries multiple forms: an ID form for joining and a display form for reading. Mosaic uses forms to resolve names like “Carolyn Inworth” to the underlying cid. Hierarchy. A parent-child relationship between attributes. Category rolls up through parent to Department. Address rolls up to City to State. Fact and metric. A fact is a numeric column. A metric aggregates it. Purchase Amount = price * quantity is a base metric. Metrics can also be advanced (an aggregation qualified by a named condition) or compound (a formula over other metrics). Filter object. A named condition referenced from metrics in angle brackets. [Large Orders] is a filter whose qualification is Purchase Amount > 500. A metric references without inlining the predicate. Level qualifier. Metric expression syntax that pins aggregation grain. {~+, !Customer+} sets the grain to Customer regardless of how the query is sliced. Model linking. Composition across models on shared attributes (Customer, Time). Mosaic pushes aggregates to each source and joins intermediate results on the linking attributes. Certified model. Only certified models are reachable through the MCP server. Live or in-memory. Two per-model execution modes: live pushdown to the source, or answers from a Mosaic-resident cube. Details later in this post. The example: Customer 360 across Amazon Redshift and Amazon Aurora The C360 pattern from the first two posts stays in place. The schema is adapted from Stardog’s C360 Knowledge Kit, so a reader following the series sees the same entities, keys, and anchor question answered by a different semantic layer. A retail organization has customer records, addresses, credit cards, and rewards enrollment sitting on the operational side, and orders, products, and product categories sitting in the warehouse. Business users want answers that span both without knowing which system holds which fact. Where this post differs is how Mosaic reaches the two sources. Mosaic does not federate rows across engines at query time. It plans one query per source, pushes native SQL down, and joins the intermediate result sets in the Mosaic engine on the shared attributes declared through model linking. The C360 walkthrough models the analytical side as a Purchase model over Amazon Redshift and the operational side as a Customer model over Amazon Aurora PostgreSQL-compatible edition. The schema across the two databases: Amazon Aurora PostgreSQL-compatible (operational) 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 Amazon Redshift (analytical) Table Key columns purchase id (PK), cid, pid, date, quantity, price, card product id (PK), name, brand, price, dept category id (PK), dept_name, parent vendor id (PK), vendor_name, industry The shared ID is cid, an integer that appears as the primary key in customer on Aurora and as a plain column in purchase on Amazon Redshift. There is no SQL constraint linking them, and there can’t be, because they live in different engines. Every question that joins a customer to their orders must reconcile that integer somewhere. Mosaic absorbs it through model linking rather than a materialized cross-engine join. 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. It needs customer profile from Aurora, aggregated spend from Amazon Redshift, and enrollment status from Aurora, ranked and filtered on definitions that live in the semantic layer. Reference architecture Figure 1 shows the end-to-end runtime. The inbound authentication path runs from the client through AgentCore Gateway, a capability of Amazon Bedrock AgentCore, and the runtime. The outbound query path runs from the Strands agent through the Mosaic MCP endpoint to Amazon Redshift and Amazon Aurora. Figure 1: Reference architecture. Inbound authentication path and outbound query path between the client, Amazon Bedrock AgentCore components, the Strategy Mosaic MCP endpoint, the Mosaic engine, and Amazon Redshift plus Amazon Aurora. The runtime splits into an inbound path and an outbound path. Inbound. A client sends the user’s question through Amazon Bedrock AgentCore Gateway. Gateway validates the JSON Web Token (JWT) that identifies the human user against the enterprise identity provider (IdP). It then routes the request to Amazon Bedrock AgentCore runtime, which hosts the Strands agent. The agent invokes Anthropic Claude Sonnet 4.6 on Amazon Bedrock to interpret the prompt and plan the query. Outbound. When the agent decides to query the semantic model, its MCP tool connects directly to the Mosaic MCP endpoint at https:///collaboration/mcp/mosaic over HTTPS. The agent presents an OAuth 2.0 access token in the Authorization: Bearer header. Mosaic validates the token against its bundled OAuth authorization server and resolves the caller to a Strategy user. It then applies the Use MCP Server privilege and certified-model gate, evaluates row-level and column-level security for that user, and plans the query across the linked Purchase and Customer models. Amazon Redshift and Amazon Aurora respond to source-native SQL that the Mosaic engine emits per source. Two properties matter for the rest of the walkthrough. Cross-source joins happen because a modeler declared a link, not because two sources happen to be reachable. The agent can only traverse links that exist in the model. The token that reaches Mosaic represents the human user, not a service account, so RLS and OLS evaluate against the caller’s identity end-to-end. AWS Secrets Manager holds the caller’s refresh token between calls, and the Governed access section walks the full identity chain. Build the semantic layer The walkthrough uses two Mosaic Models, the self-service AI-assisted modeling path in Mosaic Studio, linked on shared attributes. Mosaic Studio is the authoring suite, and the screenshots in this post come from its Design Center modeling workspace. Three passes: datasets and joins on each side, attributes and hierarchies, then metrics that carry the business logic. A team with an existing centrally governed Mosaic Schema can map the model’s attributes to it and inherit dimensions, object ACLs, and RLS from the enterprise schema without a parallel security review. Do this early if your data architects already maintain a governed schema. Two linked models Each Mosaic model connects to one live source. Model linking composes them. Purchase: Live against Amazon Redshift. Facts on the purchase table (price * quantity), dimensions on product, category, vendor, and the purchase date. Customer: Live against Amazon Aurora PostgreSQL-compatible. Dimensions on customer, address, credit_card, rewards_account. Inside each model, the physical joins are declared once against the source schema. The Purchase model resolves purchase.pid = product.id, product.dept = category.id, and product.brand = vendor.id, plus a self-reference on category.parent = category.id for the department rollup. The Customer model resolves customer.location = address.id, customer.cid = credit_card.cid, and customer.cid = rewards_account.cid. These are the relationships Mosaic uses to plan the source-native SQL it pushes down. Nothing physical crosses between Purchase and Customer. The two models link on Customer and Time. When a question needs both (for example top spenders in Wisconsin pulls state from address and spend from purchase), Mosaic pushes the appropriate aggregation to each source and combines the results on the linking attributes. No ETL, no third copy. Domain ownership follows the model boundary. The CRM team owns Customer, and the data system team owns Purchase. Neither hands over its source. They agree on the linking attributes, and security propagates from the underlying models automatically. There’s no materialized cross-engine join and no shared phy [truncated for AI cost control]