Créez une couche sémantique pour l'IA agentique sur AWS avec Strategy Mosaic et Amazon Bedrock AgentCore

Cet article est co-rédigé avec Zhili Cheng, Principal Product Manager, George Earle, Director, AI Engineering, et Kyler K, Sales Engineer de Strategy.

Dans le premier article de cette série, nous avons construit une couche sémantique sur AWS en utilisant le graphe de connaissances de Stardog sur Amazon Aurora et Amazon Redshift et exécuté un agent Strands sur Amazon Bedrock AgentCore cette couche. Le deuxième article a conservé le même modèle de vue client 360 (C360) et a remplacé la plateforme de virtualisation de données par celle de Denodo, élargissant le mélange de sources pour inclure un cluster PostgreSQL sur site. Cet article utilise à nouveau le même modèle C360, avec Strategy Mosaic comme couche sémantique.

La couche sémantique de Stardog est basée sur une ontologie : des concepts et des relations modélisés en RDF, avec des IRI comme unité de fédération et SPARQL comme langage de requête. Celle de Denodo est une virtualisation de données : des vues de base et dérivées composées en VQL. Celle de Mosaic est dimensionnelle : des attributs, hiérarchies, faits et métriques composés par la syntaxe d'expression de métriques de Strategy, avec des modèles liés comme unité de fédération. Ce modèle sert quatre protocoles natifs à partir d'une seule définition : le Model Context Protocol (MCP) pour les agents d'IA, JDBC/ODBC via Trino pour les clients SQL, XMLA pour Power BI et Excel, et REST pour les applications personnalisées. Derrière ces protocoles se trouve une longue liste de sources de données certifiées. Les systèmes pris en charge incluent des entrepôts de données cloud tels que Snowflake et Databricks. Les bases de données opérationnelles incluent Amazon Relational Database Service (Amazon RDS), Oracle et SQL Server. Les moteurs analytiques incluent Amazon Athena, Trino et SAP HANA, et les sources logiciel en tant que service (SaaS) incluent Salesforce. Le modèle de modèles liés s'étend au-delà de la paire Amazon Redshift et Amazon Aurora utilisée dans cette démonstration. Dans cette démonstration, un agent Strands hébergé sur le runtime AgentCore, une capacité d' Amazon Bedrock AgentCore, atteint Mosaic via le point de terminaison MCP. Les jointures, les définitions de métriques et les filtres de lignes et de colonnes par appelant résident dans Mosaic, et non dans l'invite de l'agent.

Nous supposons que vous êtes familiarisé avec l'architecture de couche sémantique présentée dans le premier article de la série. Si certains éléments vous sont inconnus, l'article sur Stardog couvre le sujet.

À la fin de cet article, vous saurez :

• Comment modéliser un domaine C360 dans Strategy Mosaic sur Amazon Redshift et Amazon Aurora en utilisant deux modèles liés, sans ETL.
• Comment la syntaxe de métriques de Mosaic (base, avancée avec des objets de filtre nommés, qualificateurs de niveau et composée) capture les définitions métier sur lesquelles l'agent doit raisonner.
• Comment exposer le modèle à un agent Strands hébergé sur AgentCore via le serveur MCP de Mosaic, et comment l'identité de l'utilisateur se propage afin que la sécurité au niveau des lignes (RLS) et au niveau des objets (OLS) par utilisateur soit garantie de bout en bout.
• Comment choisir entre l'exécution par pushdown en direct et l'exécution en mémoire pour le trafic des agents.
• Comment publier les mêmes définitions gouvernées vers Power BI, Tableau, des notebooks et des applications personnalisées, et comment les exporter au format Apache Ossie pour les outils en dehors de Mosaic.

La source de vérité de cette procédure est Strategy One (March 2026), la version à partir de laquelle l'accès à Mosaic via le serveur MCP est devenu disponible par défaut.

Termes Mosaic de Strategy utilisés dans cet article

Une brève référence avant d'aborder le modèle.

• Mosaic Schema et Mosaic Models. Deux voies de modélisation au sein d'une même couche sémantique universelle. Mosaic Schema est le modèle d'entreprise gouverné de manière centralisée. Mosaic Models est la voie de modélisation en libre-service assistée par l'IA dans Mosaic Studio. Les modèles peuvent être mappés aux attributs du Schema et hériter des dimensions, des ACL d'objets et du RLS. Cette procédure utilise Mosaic Models.
• Model. L'artefact de premier niveau dans l'une ou l'autre voie de modélisation. Il publie des attributs, des métriques, des hiérarchies et des règles de sécurité sur des tables physiques. La procédure utilise deux Mosaic Models, l'un sur Amazon Redshift et l'autre sur Aurora, liés entre eux.
• Attribut. Une entité métier telle que Customer. Porte plusieurs formes : une forme ID pour les jointures et une forme d'affichage pour la lecture. Mosaic utilise les formes pour résoudre des noms comme « Carolyn Inworth » vers l'élément sous-jacent cid.
• Hiérarchie. Une relation parent-enfant entre attributs. Category se cumule via parent vers Department. Address se cumule vers City puis vers State.
• Fait et métrique. Un fait est une colonne numérique. Une métrique l'agrège. Purchase Amount = price * quantity est une métrique de base. Les métriques peuvent aussi être avancées (une agrégation qualifiée par une condition nommée) ou composées (une formule sur d'autres métriques).
• Objet filtre. Une condition nommée référencée depuis les métriques entre crochets angulaires. [Large Orders] est un filtre dont la qualification est Purchase Amount > 500. Une métrique référence <[Large Orders]> sans intégrer le prédicat en ligne.
• Qualificateur de niveau. Syntaxe d'expression de métrique qui fige la granularité d'agrégation. {~+, !Customer+} fixe la granularité à Customer quelle que soit la manière dont la requête est découpée.
• Liaison de modèles. Composition entre modèles sur des attributs partagés (Customer, Time). Mosaic pousse les agrégats vers chaque source et joint les résultats intermédiaires sur les attributs de liaison.
• Modèle certifié. Seuls les modèles certifiés sont accessibles via le serveur MCP.
• Live ou en mémoire. Deux modes d'exécution par modèle : pushdown en direct vers la source, ou réponses depuis un cube résident dans Mosaic. Détails plus loin dans cet article.

L'exemple : Customer 360 à travers Amazon Redshift et Amazon Aurora

Le modèle C360 des deux premiers articles reste en place. Le schéma est adapté de Stardog’s C360 Knowledge Kit, de sorte qu'un lecteur suivant la série retrouve les mêmes entités, clés et question d'ancrage, traitées par une couche sémantique différente. Une organisation de vente au détail dispose des enregistrements clients, adresses, cartes de crédit et inscriptions au programme de récompenses côté opérationnel, et des commandes, produits et catégories de produits dans l'entrepôt de données. Les utilisateurs métier veulent des réponses couvrant les deux sans savoir quel système détient quel fait.

Là où cet article diffère, c'est dans la manière dont Mosaic atteint les deux sources. Mosaic ne fédère pas les lignes entre moteurs au moment de la requête. Il planifie une requête par source, pousse du SQL natif vers le bas, et joint les ensembles de résultats intermédiaires dans le moteur Mosaic sur les attributs partagés déclarés via la liaison de modèles. Le parcours C360 modélise le côté analytique comme un modèle Purchase sur Amazon Redshift et le côté opérationnel comme un modèle Customer sur Amazon Aurora PostgreSQL-compatible edition.

Le schéma à travers les deux bases de données :

Amazon Aurora PostgreSQL-compatible (opérationnel)

Amazon Redshift (analytique)

L’ID partagé est cid, un entier qui apparaît comme clé primaire dans customer sur Aurora et comme simple colonne dans purchase sur Amazon Redshift. Il n’existe aucune contrainte SQL reliant ces deux éléments, et il ne peut pas y en avoir, car ils résident dans des moteurs différents. Chaque question qui joint un client à ses commandes doit réconcilier cet entier quelque part. Mosaic l’absorbe par le biais du model linking plutôt que par une jointure matérialisée entre moteurs.

Une question représentative qui sollicite l’ensemble du modèle : Parmi nos 20 principaux clients par dépense cumulée, lesquels ne se sont pas encore inscrits au programme de récompenses ? C’est la question d’auto-inscription issue de l’article Denodo. Elle nécessite le profil client provenant d’Aurora, la dépense agrégée provenant d’Amazon Redshift, et le statut d’inscription provenant d’Aurora, avec un classement et un filtrage appliqués à des définitions qui résident dans la couche sémantique.

Architecture de référence

La Figure 1 montre le flux d’exécution de bout en bout. Le chemin d’authentification entrant va du client en passant par AgentCore Gateway, une capacité d’Amazon Bedrock AgentCore, jusqu’au runtime. Le chemin de requête sortant va de l’agent Strands via le point de terminaison Mosaic MCP vers Amazon Redshift et Amazon Aurora.

Figure 1 : Architecture de référence. Chemin d’authentification entrant et chemin de requête sortant entre le client, les composants Amazon Bedrock AgentCore, le point de terminaison MCP de Strategy Mosaic, le moteur Mosaic, et Amazon Redshift ainsi qu’Amazon Aurora.

Le runtime se divise en un chemin entrant et un chemin sortant.

Entrant. Un client envoie la question de l’utilisateur via Amazon Bedrock AgentCore Gateway. La passerelle valide le JSON Web Token (JWT) qui identifie l’utilisateur humain auprès du fournisseur d’identité (IdP) d’entreprise. Elle achemine ensuite la requête vers Amazon Bedrock AgentCore runtime, qui héberge l’agent Strands. L’agent invoque Anthropic Claude Sonnet 4.6 sur Amazon Bedrock pour interpréter la requête et planifier l’interrogation.

Sortant. Lorsque l’agent décide d’interroger le modèle sémantique, son outil MCP se connecte directement au point de terminaison Mosaic MCP à https://<env-domain>/collaboration/mcp/mosaic via HTTPS. L’agent présente un jeton d’accès OAuth 2.0 dans l’en-tête Authorization: Bearer . Mosaic valide le jeton auprès de son serveur d’autorisation OAuth intégré et résout l’appelant en tant qu’utilisateur Strategy. Il applique ensuite le verrou Use MCP Server de privilèges et de modèles certifiés, évalue la sécurité au niveau des lignes et des colonnes pour cet utilisateur, et planifie la requête sur les modèles Purchase et Customer liés. Amazon Redshift et Amazon Aurora répondent au SQL natif de chaque source que le moteur Mosaic émet par source.

Deux propriétés importent pour la suite de la démonstration. Les jointures inter-sources se produisent parce qu’un modélisateur a déclaré un lien, et non parce que deux sources se trouvent être accessibles. L’agent ne peut parcourir que les liens qui existent dans le modèle. Le jeton qui parvient à Mosaic représente l’utilisateur humain, et non un compte de service, de sorte que la RLS et l’OLS sont évaluées par rapport à l’identité de l’appelant de bout en bout. AWS Secrets Manager conserve le jeton de rafraîchissement de l’appelant entre les appels, et la section Governed access décrit l’ensemble de la chaîne d’identité.

Construire la couche sémantique

La démonstration utilise deux Mosaic Models, le chemin de modélisation autogéré assisté par IA dans Mosaic Studio, liés sur des attributs partagés. Mosaic Studio est la suite de création, et les captures d’écran de cet article proviennent de son espace de modélisation Design Center. Trois étapes : les jeux de données et les jointures de chaque côté, les attributs et les hiérarchies, puis les métriques qui portent la logique métier. Une équipe disposant déjà d’un Mosaic Schema centralisé et gouverné peut faire correspondre les attributs du modèle à celui-ci et hériter des dimensions, des ACL d’objets et de la RLS du schéma d’entreprise sans revue de sécurité parallèle. Faites-le tôt si vos architectes de données gèrent déjà un schéma gouverné.

Deux modèles liés

Chaque modèle Mosaic se connecte à une seule source en direct. Le model linking les compose.

• Purchase: en direct contre Amazon Redshift. Les faits sur le purchase table (price * quantity), les dimensions sur product, category, vendor, et la date d'achat.
• Customer: en production contre Amazon Aurora PostgreSQL-compatible. Dimensions sur customer, address, credit_card, rewards_account.

Dans chaque modèle, les jointures physiques sont déclarées une seule fois contre le schéma source. Le modèle Purchase résout purchase.pid = product.id, product.dept = category.id, et product.brand = vendor.id, plus une auto-référence sur category.parent = category.id pour le rollup des départements. Le modèle Customer résout customer.location = address.id, customer.cid = credit_card.cid, et customer.cid = rewards_account.cid. Ce sont les relations que Mosaic utilise pour planifier le SQL natif à la source qu'il pousse vers le bas. Rien de physique ne transite entre Purchase et Customer.

Les deux modèles sont liés sur Customer et Time. Quand une question a besoin des deux (par exemple les plus gros dépensiers dans le Wisconsin récupère l'état depuis address et les dépenses depuis purchase), Mosaic pousse l'agrégation appropriée vers chaque source et combine les résultats sur les attributs de liaison. Pas d'ETL, pas de troisième copie.

La propriété des domaines suit la limite du modèle. L'équipe CRM est propriétaire de Customer, et l'équipe du système de données est propriétaire de Purchase. Aucune des deux ne cède sa source. Elles s'accordent sur les attributs de liaison, et la sécurité se propage automatiquement depuis les modèles sous-jacents. Il n'y a pas de jointure matérialisée entre moteurs ni de schéma physique partagé entre Amazon Redshift et Amazon Aurora. La jointure est l'accord sur les attributs de liaison.

Attributs et hiérarchies

Les attributs portent plusieurs formes. Customer utilise cid comme forme d'ID et first_name + last_name comme forme d'affichage, de sorte qu'un agent peut poser une question sur « Carolyn Inworth » et Mosaic la résout vers la bonne clé des deux côtés de la liaison. La figure 2 montre l'attribut Customer créé dans Mosaic Studio, avec cid comme forme d'ID et Full Name, First Name et Last Name comme formes d'affichage.

Figure 2 : définition de l'attribut Customer dans Design Center. cid est la forme d'ID utilisée pour la jointure sur la clé sous-jacente. Full Name, First Name et Last Name sont des formes d'affichage.

Deux hiérarchies comptent pour le C360 :

• La hiérarchie Category se consolide via parent jusqu'à Department. L'auto-référence category.parent signifie qu'une question au niveau du département s'agrège de manière cohérente.
• Address se consolide via City jusqu'à State selon le même schéma. Cela fait de State = 'WI' une simple qualification d'attribut plutôt qu'une jointure que l'agent doit construire.

La figure 3 montre la hiérarchie géographique créée dans Design Center, enchaînant State via City et ZIP Code jusqu'à Customer.

Figure 3 : hiérarchie Geography dans Design Center pour le modèle Customer. State se consolide via City et ZIP Code jusqu'à Location, et Location est lié à Customer.

L'agent demande State = 'WI', et non address.state. Les noms de colonnes physiques ne quittent pas le modèle. Tout consommateur de la couche sémantique voit la forme de l'attribut et ses formes d'affichage, et la hiérarchie assure automatiquement la consolidation.

Métriques : de base, avancées, composées, d'intelligence temporelle

Une métrique de base applique une fonction de groupe à un fait. Purchase Amount est Sum(price * quantity) sur la table purchase .

La figure 4 montre la métrique de base Purchase Amount créée dans Mosaic Studio : la formule Price * Quantity, avec un champ de description qui indique à l'agent ce que signifie la métrique en termes métier.

Figure 4 : métrique Purchase Amount créée dans Design Center. La formule multiplie le prix par la quantité, et la description indique à l'agent ce que signifie la métrique en termes métier.

Les concepts intéressants du C360 sont les métriques avancées : une agrégation qualifiée par une condition nommée. Dans Strategy, les conditions sont des références à des objets de filtre entre crochets angulaires, et non des prédicats en ligne. Les objets de filtre sont des objets du modèle dotés de leur propre nom, description et permissions, de sorte qu'ils sont réutilisables et auditables à travers les métriques qui partagent une définition.

Définir les filtres une seule fois :

Chaque objet de filtre comporte un nom, une description, une qualification et des permissions d'accès. La forme qu'un modeleur crée ou exporte pour [Large Orders] ressemble à ceci :

name:          [Large Orders]
description:   Purchases whose net line amount exceeds $500.
               Referenced by Large Order Spend and any metric that
               scopes to high-value transactions.
qualification: Purchase Amount > 500
permissions:   read:   Everyone
               modify: Data Modelers

Puis référencer les filtres dans les expressions de métriques. Chacune de celles-ci est une métrique avancée : une agrégation de base qualifiée par un filtre nommé.

Large Order Spend    Sum([Purchase Amount]) {~+} <[Large Orders]>
Sports Spend         Sum([Purchase Amount]) {~+} <[Sports Category]>
Rewards Spend        Sum([Purchase Amount]) {~+} <[Rewards Members]>

La figure 5 montre la vue du Design Center d'une métrique avancée avec une condition de filtre appliquée. Elle utilise le même modèle de création que le Large Order Spend.

Figure 5 : création d'une métrique avancée dans le Design Center, montrant la formule de base et la condition de filtre référencée à partir de l'objet de filtre Large Orders.

Customer Lifetime Spend a également besoin d’un qualificateur de niveau, car « lifetime » (durée de vie) signifie tout l’historique, indépendamment de la façon dont la question actuelle est découpée :

Customer Lifetime Spend    Sum([Purchase Amount]) {~+, !Customer+}

Le ! avant Customer définit le regroupement sur aucun, de sorte que la métrique renvoie le total complet de chaque client sur chaque ligne plutôt que de se réduire à une ligne par client. Voir Strategy Metric Level Symbols pour la syntaxe complète.

Remarquez que [Big Spender] dans la table de filtre qualifie sur une expression de métrique plutôt que sur un prédicat d’attribut. Les objets de filtre peuvent restreindre sur l’un ou l’autre. La part de portefeuille (share of wallet) est une métrique composée, construite à partir d’autres métriques :

Sports Share of Wallet    [Sports Spend] / [Customer Lifetime Spend]

Les niveaux et les conditions se propagent inchangés depuis les composants. La part de portefeuille est un ratio, donc elle ne s’ajoute ni ne se moyenne. La part sur une Région AWS n’est pas la moyenne des parts de chaque client, et la description de la métrique l’indique à l’agent. Voir Strategy Conditional Metrics.

Au-delà des métriques de base, avancées et composées, Mosaic fournit des métriques d’intelligence temporelle gouvernées en tant qu’expressions de première classe. Previous Year, Previous Quarter, Year-to-Date, et Quarter-to-Date sont déclarées une seule fois sur le modèle et préservées à travers les découpages, de sorte qu’une question telle que comment les dépenses Sports de cette année se comparent-elles à celles de l’année dernière devient une sélection d’attribut et deux références de métrique plutôt qu’un filtre de date SQL écrit à la main. Les calendriers personnalisés se rattachent au niveau du modèle, de sorte que la même expression d’année sur année fonctionne pour une année fiscale se terminant en septembre et pour une année civile se terminant en décembre. Voir Governed Time-Intelligence Metrics in Mosaic.

Modifiez une fois l’objet de filtre et le tableau de bord Power BI, l’extraction SQL et l’agent évoluent tous ensemble. C’est ce qu’un artefact de modèle nommé et gouverné vous apporte et qu’un prédicat SQL en ligne ne peut pas offrir.

Comment Mosaic planifie et exécute les requêtes

Le moteur Mosaic analyse chaque appel MCP query comme du SQL de dialecte Trino, résout les références dimensionnelles vers les modèles Purchase et Customer sous-jacents, applique la RLS ou l’OLS auxquelles l’appelant est soumis, et planifie le SQL physique par source. Le dialecte correspond à ce que Strategy publie pour l’outil de requête MCP, de sorte que le SQL émis par l’agent est portable entre les clients MCP se connectant au même modèle certifié.

Pour la question d’auto-inscription, la planification se déroule ainsi :

1. Pousser vers Amazon Aurora : une jointure de customer et rewards_account sur cid, projetant le profil et rewards_account.create_date, filtrée là où l’inscription est nulle. Renvoie une ligne par client non inscrit.
2. Pousser vers Amazon Redshift : SUM(price * quantity) groupé par cid. Renvoie une ligne par client avec le dépense totale.
3. Combiner à l’intérieur de Mosaic : joindre les deux ensembles de résultats intermédiaires sur cid (l'attribut de liaison), classer par dépense cumulée et renvoyer le top 20.

Aurora exécute une jointure transactionnelle de profils. Amazon Redshift exécute l'agrégation des faits. Mosaic gère la jointure inter-moteurs sur un petit ensemble intermédiaire (une ligne par client, et non une ligne par commande). Un pipeline écrit à la main approxime la même forme, puis doit être maintenu en synchronisation pour toujours.

Un détail SQL compte. Les métriques sont des valeurs gouvernées, mais Trino les traite comme des colonnes sélectionnées, donc lorsqu'une requête utilise GROUP BY, les métriques nécessitent un wrapper d'agrégation tel que SUM(metric_name). La définition, les conditions et les chemins de jointure de la métrique restent résolus par Mosaic. L'agrégation externe appartient à l'appelant. Un ratio non additif comme la part du portefeuille doit donc l'indiquer dans sa description.

Pushdown en direct ou en mémoire

Chaque modèle Mosaic fonctionne dans l'un des deux modes suivants.

Les deux modes appliquent les mêmes règles de sécurité. RLS et OLS sont définis une seule fois sur le modèle et évalués quel que soit l'origine de la réponse. Le choix est une question de performance et de coût.

Le trafic des agents est répétitif et en rafales. Un agent qui décompose les plus gros dépensiers du Wisconsin en plusieurs questions de suivi exploratoires émet de nombreuses petites requêtes sur la même tranche récente. Servir cela depuis la mémoire transforme une dépense d'entrepôt variable par requête en une capacité Mosaic fixe, et c'est généralement plus rapide. Pour des charges de travail d'agents interactives sur une fenêtre délimitée, le mode en mémoire est souvent à la fois plus rapide et moins coûteux. Configurez les droits côté Mosaic avant de passer un modèle en mémoire, et validez-les dans la même passe de tests que celle utilisée pour valider les chiffres.

Une définition, quatre interfaces

Les métriques, attributs, hiérarchies et règles de sécurité construits dans la section précédente atteignent chaque consommateur via des protocoles natifs. Pas de traduction par connecteur, pas de réimplémentation de métrique, pas de dérive.

Le même modèle Mosaic certifié que consomme l'agent Strands dans cette démonstration sert également un analyste travaillant dans Amazon Quick, qui enregistre Mosaic MCP comme connecteur authentifié par OAuth. Aucune seconde intégration n'est nécessaire.

Accès gouverné : propagation de l'identité et application au moment de l'exécution

Mosaic applique les contrôles d'accès dans la couche sémantique, avant qu'une requête n'atteigne Amazon Redshift ou Aurora. Les rôles RH et fraude voient les champs d'informations personnellement identifiables (PII) comme ssn et card_num. Les rôles marketing et analytique ne les voient pas. L'application des règles est identique que l'appelant soit un agent Strands via MCP, un analyste dans Excel via XMLA ou un notebook via JDBC. Un seul ensemble d'objets RLS et OLS, une seule passerelle de modèle certifié, une seule vérification des privilèges. Les attributs et métriques marqués comme sensibles alimentent également Mosaic Sentinel Risk Management, qui alerte sur les requêtes touchant des objets signalés et détecte les anomalies comportementales comme couche de défense en profondeur à côté d'OLS.

La figure 6 montre la chaîne de propagation de l'identité sur deux voies : la poignée de main OAuth frontale exécutée une fois par utilisateur, et le chemin par requête exécuté à chaque appel d'outil de l'agent. Chaque voie transporte l'identité de l'utilisateur de bout en bout afin que Mosaic puisse appliquer RLS et OLS sur l'appelant plutôt que sur un compte de service.

Figure 6 : Chaîne de propagation de l'identité. La poignée de main OAuth frontale s'exécute une fois par utilisateur, ou au renouvellement du refresh token (étapes 1-4). Le chemin par requête s'exécute à chaque appel d'outil de l'agent (étapes 5-10). Rien dans la chaîne ne se repositionne sur un compte de service. Mosaic évalue la gouvernance sur l'identité utilisateur Strategy de l'appelant.

La chaîne suit deux voies.

Poignée de main OAuth frontale (une fois par utilisateur). L'utilisateur humain s'authentifie auprès de l'IdP d'entreprise. L'application démarre un flux OAuth 2.0 Authorization Code auprès de Strategy Library à /collaboration/authorize avec le scope offline_access. Strategy Library, fédéré au même IdP via SAML ou OIDC, renvoie une paire de refresh token et access token à /collaboration/token. L'application conserve le refresh token dans AWS Secrets Manager, indexé par la revendication sub IdP de l'utilisateur.

Chemin par requête (à chaque appel d'outil de l'agent). AgentCore Gateway valide le JWT de l'IdP et achemine vers le runtime AgentCore, qui héberge l'agent Strands invoquant Claude Sonnet 4.6 sur Amazon Bedrock. L'outil MCP de l'agent récupère le refresh token de l'utilisateur depuis Secrets Manager, l'échange contre un access token frais, et présente Authorization: Bearer <access_token> à /collaboration/mcp/mosaic. Mosaic résout le jeton vers un utilisateur Strategy, applique le Use MCP Server contrôle de privilège, la passerelle de modèles certifiés, ainsi que RLS et OLS, puis planifie et exécute sur Purchase et Customer. Un analyste marketing ne voit pas ssn ou card_num. Un analyste fraude, si.

Rien dans la chaîne ne redéfinit le périmètre vers un compte de service. La gouvernance évalue sur l'identité de l'appelant, de l'IdP au moteur Mosaic.

Exposer la couche via le serveur MCP Mosaic

La Strategy Library expose deux points de terminaison MCP :

Les deux fonctionnent indépendamment. Ce guide utilise Mosaic MCP. Placer la couche sémantique directement devant l’agent Strands évite un saut d’inférence.

La chaîne d’outils

Quatre outils, enchaînés du projet au modèle, puis à la sémantique et à la requête.

L’agent enchaîne ces appels automatiquement. get_projects et get_models permettent de restreindre le choix au bon modèle par description avant que l’agent ne lise un nom de colonne. get_semantics renvoie les définitions gouvernées que l’agent utilise ensuite pour composer du SQL sur de vrais noms d’objets : Sports Share of Wallet en tant que métrique composée, Customer Lifetime Spend délimité à Customer, la hiérarchie Category, et la formule de chaque métrique.

Deux conventions SQL propres à Mosaic comptent. Les identifiants de colonnes suivent un motif <form>__<name> et doivent être entourés de guillemets doubles ("customer__customer name"). Les attributs temporels sont exposés à la fois comme colonnes de base et comme colonnes d’intervalles pré-découpées ((day interval), (month interval)), et la documentation indique explicitement d’utiliser les colonnes d’intervalles pour les agrégations groupées par temps plutôt que date_trunc.

Les métadonnées sont ce qui rend le tout exact

get_semantics renvoie des définitions, mais l’agent doit quand même choisir la bonne métrique. Sans descriptions, Total Spend et Customer Lifetime Spend paraissent interchangeables, alors qu’elles ne le sont pas. Quatre propriétés font l’essentiel du travail : les descriptions d’objets (ce que signifie la métrique et quand ne pas l’utiliser, y compris le comportement d’agrégation pour les métriques non additives), les définitions sémantiques (comment les métriques composées se composent), les relations (quels attributs sont des tranches valides) et le contexte de gouvernance (afin que l’agent puisse dire ce qu’il ne voit pas plutôt que présenter un nombre filtré comme complet). La description du modèle est la première chose que get_models renvoie et c’est ainsi que l’agent choisit le bon modèle. Mosaic peut importer des métadonnées depuis des catalogues en amont, de sorte que les descriptions de colonnes déjà maintenues sont reprises plutôt que ressaisies.

Déployer l’agent

Strands est un petit framework pour construire des agents. Un court point d'entrée Python relie Claude Sonnet 4.6 sur Amazon Bedrock au point de terminaison MCP de Mosaic comme source d'outils. Le runtime AgentCore héberge le processus. La passerelle AgentCore Gateway termine les requêtes entrantes et transmet le JWT de l'utilisateur humain.

Le prompt système compte. Donnez à l'agent des instructions explicites de suivre le modèle d'appel en trois étapes avant d'écrire du SQL : get_projects, puis get_models, puis get_semantics sur le modèle cible. Dites-lui de ne référencer que les noms d'attributs et de métriques que get_semantics a renvoyés. Incluez une courte section sur la terminologie métier dans le modèle cible (Customer Lifetime Spend est le total du client sur l'ensemble de son historique, quelle que soit la tranche actuelle. Sports Share of Wallet est un ratio. Et ainsi de suite). C'est le travail d'ingénierie de prompt qui rapporte le plus en précision.

Activez la mise en cache des prompts d'Amazon Bedrock pour la partie réutilisée du prompt système. Le payload get_semantics représente quelques milliers de tokens et ne change pas au sein d'une version de modèle, de sorte que la mise en cache réduit le coût en tokens d'entrée par appel lors des invocations répétées. Le trafic d'agents dirigé vers une couche sémantique stable correspond exactement au motif répétitif et en rafales qui en profite le plus.

Deux effets se cumulent sur le chemin MCP. Premièrement, get_semantics renvoie un contexte métier compressé (définitions de métriques, hiérarchies, formes d'attributs) au lieu du DDL brut du schéma, de sorte que le modèle raisonne sur un payload plus petit et à plus forte valeur d'information. Le benchmark publié par Strategy mesure l'impact sur les tokens d'entrée et le coût par requête de la fourniture d'un contexte sémantique par rapport au schéma brut. Deuxièmement, la mise en cache des prompts de Bedrock maintient ce payload déjà compressé actif entre les appels. Pour un trafic d'agents répétitif, les deux effets s'appliquent à chaque appel : le modèle raisonne sur un contexte compressé et les appels répétés touchent le cache.

Vérification

Pour confirmer que la couche sémantique, l'agent et le flux d'identité fonctionnent comme prévu, nous avons exécuté trois catégories de requêtes via l'agent, puis une réexécution de gouvernance de l'une d'elles sous un rôle différent.

Requête 1, Aurora uniquement. Listez nos clients dans le Wisconsin, avec leur ville.

L'agent génère une requête sur le modèle Customer qui projette les formes d'affichage de Customer et City et filtre l'état sur WI :

SELECT "customer__customer name", "city__city name"
FROM   "Customer"
WHERE  "state__state name" = 'WI'
ORDER BY "customer__customer name"

Mosaic pousse une seule requête vers Aurora et renvoie les lignes. Amazon Redshift n'est pas sollicité.

Requête 2, Amazon Redshift uniquement. Quels sont nos 10 meilleurs produits en unités vendues ?

SELECT "product__product name", SUM("Units Sold") AS "total_units"
FROM   "Purchase"
GROUP BY "product__product name"
ORDER BY "total_units" DESC
LIMIT 10

Toute la requête est poussée vers Amazon Redshift. Aurora n'est pas sollicité.

Requête 3, inter-modèles. Parmi nos 20 meilleurs clients par dépense cumulée, lesquels ne se sont pas encore inscrits au programme de récompenses ?

SELECT "customer__customer name",
       "state__state name",
       SUM("Customer Lifetime Spend") AS "lifetime_spend"
FROM   "Customer"
WHERE  "rewards_account__account_id" IS NULL
GROUP BY "customer__customer name", "state__state name"
ORDER BY "lifetime_spend" DESC
LIMIT 20

Mosaic planifie sur les deux modèles. Le profil et le statut d'inscription proviennent d'Aurora, l'agrégation des dépenses d'Amazon Redshift, jointurés sur l'attribut de liaison Customer au sein du moteur Mosaic, puis filtrés et triés pour le top-N. L'agent n'a pas eu besoin de définir Customer Lifetime Spend. Il a référencé la métrique par son nom et Mosaic a résolu la formule, le qualificateur de niveau et les chemins de liaison.

Reprise de test de gouvernance. Nous avons exécuté la Requête 1 avec ssn ajouté à la projection, avec deux appelants. En tant qu'analyste fraude, get_semantics renvoyait l'attribut SSN et la requête renvoyait les valeurs. En tant qu'analyste marketing, get_semantics renvoyait un attribut Customer sans ssn du tout, si bien que l'agent n'avait aucun attribut à projeter. Même requête, même texte de requête, deux réponses correctes à partir d'une seule définition.

Confirmation multi-interfaces. Nous avons ouvert le même modèle Customer certifié dans Excel via le point de terminaison XMLA de Mosaic et fait glisser State et Customer Lifetime Spend sur un tableau croisé dynamique. Les totaux au niveau des États correspondaient exactement aux chiffres de l'agent.

Au début de l'exécution, l'agent calculait en moyenne la part de portefeuille entre les clients, l'erreur classique de non-additivité. L'ajout d'une ligne à la description de la métrique (« métrique de ratio. Ne pas faire la moyenne entre les clients, recalculer à partir des composantes ») l'a stoppée. C'est précisément pour cela qu'il faut rédiger les descriptions des métriques dès le premier sprint plutôt qu'au dernier.

Étendre à travers les sources de données

Le même mécanisme de liaison s'étend à une troisième source : les événements de clic dans Amazon Simple Storage Service (Amazon S3) interrogés via Amazon Athena, les tables Apache Iceberg sur Amazon S3 Tables, une capacité d'Amazon S3, ou une source SaaS telle qu'un CRM. Modélisez la source dans Mosaic, liez-la sur Customer et Time, et les questions de navigation-à-achat se composent dans la même vue client sans un troisième pipeline. L'ajout d'une source ne modifie pas les définitions de métriques déjà existantes. L'agent ne peut parcourir que les chemins déclarés par un modélisateur. AWS Lake Formation gouverne l'accès aux tables du lac sous-jacentes. La RLS et l'OLS de Mosaic s'appliquent par-dessus.

Le même modèle de source en direct s'applique à chaque système du catalogue des sources de données prises en charge par Strategy, couvrant les bases de données sur site telles que PostgreSQL et MySQL en plus des entrepôts et moteurs déjà cités dans cet article.

Interopérabilité avec Apache Ossie

Certains outils refuseront de dépendre d'une seule couche sémantique. Apache Ossie (incubating) est la spécification ouverte comblant ce manque, lancée sous le nom d'Open Semantic Interchange le 23 septembre 2025 et désormais dans l'Apache Incubator en tant qu'Apache Ossie (incubating). Elle définit un format neutre vis-à-vis des fournisseurs pour les métriques, les dimensions, les relations et les concepts métier, afin que les définitions circulent entre les outils sans avoir à être ressaisies. Strategy participe aux côtés de Snowflake, Dremio, dbt Labs, Salesforce et d'autres.

Mosaic exporte et importe les artefacts Ossie. Les définitions de métriques et de dimensions modélisées sur Amazon Redshift se publient en YAML Ossie consommable par les outils compatibles Ossie sans connecteur Mosaic. Les définitions rédigées ailleurs (une métrique maintenue dans dbt, une dimension normalisée dans un catalogue) arrivent dans Mosaic au lieu d'être réimplémentées. Les artefacts sont du texte brut, donc ils vivent dans Git et sont promus entre les environnements comme tout autre code.

Apache Ossie est encore jeune. Utilisez-le là où la portabilité compte le plus et la fidélité le moins, par exemple pour les formules, les dimensions, les descriptions et les métadonnées de propriété, tout en gardant la politique de gouvernance, la stratégie d'exécution et la configuration de sécurité natives de Mosaic.

Déploiement : Strategy Cloud

Mosaic s'exécute en tant que service géré sur Strategy Cloud. Strategy exploite l'application. Les connexions à Amazon Redshift et Amazon Aurora passent par le réseau depuis l'egress de Strategy Cloud. Vous ajoutez les CIDR de Strategy Cloud en liste blanche sur les groupes de sécurité des sources.

Observabilité

Deux plans d'observabilité couvrent le chemin allant de la question à la réponse.

Sentinel et Platform Analytics couvrent le côté requêtes. Sentinel capture la durée des requêtes en quasi temps réel, les requêtes lentes et l'utilisation par utilisateur, outil et modèle.

AgentCore Observability, une capacité d'Amazon Bedrock AgentCore, couvre le côté agent : étapes de planification, appels d'outils, latence par tour. Sentinel et Platform Analytics montrent ce qui s'est passé une fois la requête parvenue à Mosaic. AgentCore Observability montre ce que l'agent faisait avant d'y arriver.

Conclusion

L'analytique agentique fiable combine un raisonnement solide, un contexte métier fiable et une exécution sécurisée. Amazon Bedrock fournit le modèle, Strategy Mosaic fournit la couche sémantique gouvernée sur des données en direct, et Amazon Bedrock AgentCore héberge l'agent et termine l'authentification. L'agent dialogue avec la couche sémantique, et non directement avec Amazon Redshift ou Aurora. Les schémas évoluent, le modèle sémantique absorbe le changement, et les mêmes définitions servent Power BI, Tableau, les notebooks, l'agent Strands et Amazon Quick. Via Apache Ossie, elles atteignent également les outils qui ne se connectent pas à Mosaic.

Par où commencer

• Choisissez une métrique actuellement débattue (le NRR, la marge de contribution et les clients actifs sont des candidates courantes). Une métrique ayant plus d'une définition en circulation.
• Rédigez trois à cinq questions d'affaires à son sujet. Elles deviendront vos tests d'acceptation.
• Modélisez votre source principale dans Mosaic et faites en sorte que la métrique renvoie un nombre défendable.
• Reliez progressivement des sources supplémentaires, une à la fois, sur les attributs qui existent déjà dans le modèle.
• Rédigez des descriptions pour chaque métrique et attribut que l'agent verra. C'est là que la précision progresse le plus.
• Connectez l'agent Strands via Mosaic MCP et exécutez vos questions d'acceptation.
• Observez les modèles de requêtes réels pendant quelques semaines, puis déplacez ce qui est fréquemment utilisé en mémoire.
• Exportez les définitions stables vers Apache Ossie et placez-les sous gestion de versions.

Pour aller plus loin

• Strategy Mosaic – Universal Semantic Layer
• Interact with Agents, Mosaic Models, and Cubes Using an MCP Server
• Strategy Advanced Metrics: Report Data and Calculations
• Strategy Conditional Metrics
• Strategy Metric Level Symbols
• Strategy Compound Metrics
• Amazon Bedrock AgentCore Developer Guide
• Amazon Bedrock prompt caching
• Apache Ossie (incubating)
• Créez une couche sémantique pour l'IA agentique sur AWS avec Stardog et Amazon Bedrock AgentCore
• Créez une couche sémantique pour l'IA agentique sur AWS avec Denodo et Amazon Bedrock AgentCore

À propos des auteurs