Cree una capa semántica para IA agéntica en AWS con Strategy Mosaic y Amazon Bedrock AgentCore

Esta publicación está coescrita con Zhili Cheng, Product Manager Principal, George Earle, Director de Ingeniería de IA, y Kyler K, Sales Engineer de Strategy.

En la primera publicación de esta serie, construimos una capa semántica en AWS usando el grafo de conocimiento de Stardog sobre Amazon Aurora y Amazon Redshift y ejecutamos un agente Strands en Amazon Bedrock AgentCore contra esa capa. La segunda publicación mantuvo el mismo patrón de customer 360 (C360) y sustituyó la plataforma de virtualización de datos de Denodo, ampliando la mezcla de fuentes para incluir un clúster de PostgreSQL local. Esta publicación usa nuevamente el mismo patrón C360, con Strategy Mosaic como capa semántica.

La capa semántica de Stardog está basada en ontologías: conceptos y relaciones modelados como RDF, con IRIs como unidad de federación y SPARQL como lenguaje de consulta. La de Denodo es virtualización de datos: vistas base y derivadas compuestas en VQL. La de Mosaic es dimensional: atributos, jerarquías, hechos y métricas compuestos mediante la sintaxis de expresiones de métricas de Strategy, con modelos vinculados como unidad de federación. Ese modelo sirve cuatro protocolos nativos desde una sola definición: Model Context Protocol (MCP) para agentes de IA, JDBC/ODBC sobre Trino para clientes SQL, XMLA para Power BI y Excel, y REST para aplicaciones personalizadas. Detrás de esos protocolos hay una larga lista de fuentes de datos certificadas. Los sistemas compatibles incluyen almacenes de datos en la nube como Snowflake y Databricks. Las bases de datos operacionales incluyen Amazon Relational Database Service (Amazon RDS), Oracle y SQL Server. Los motores analíticos incluyen Amazon Athena, Trino y SAP HANA, y las fuentes de software como servicio (SaaS) incluyen Salesforce. El patrón de modelos vinculados se extiende más allá del par de Amazon Redshift y Amazon Aurora que usa este recorrido. En este recorrido, un agente Strands alojado en el runtime de AgentCore, una capacidad de Amazon Bedrock AgentCore, accede a Mosaic a través del endpoint MCP. Las uniones, las definiciones de métricas y los filtros de filas y columnas por invocador residen dentro de Mosaic, no en el prompt del agente.

Asumimos que está familiarizado con la arquitectura de la capa semántica de la primera publicación de la serie. Si algo de esto es nuevo, la publicación de Stardog cubre ese terreno.

Al final de esta publicación, usted sabrá:

• Cómo modelar un dominio C360 en Strategy Mosaic a través de Amazon Redshift y Amazon Aurora usando dos modelos vinculados, sin ETL.
• Cómo la sintaxis de métricas de Mosaic (base, avanzada con objetos de filtro con nombre, calificadores de nivel y compuesta) captura las definiciones de negocio sobre las que el agente debe razonar.
• Cómo exponer el modelo a un agente Strands alojado en AgentCore a través del servidor MCP de Mosaic, y cómo se propaga la identidad del usuario para que la seguridad a nivel de filas (RLS) y la seguridad a nivel de objetos (OLS) por usuario se mantengan de extremo a extremo.
• Cómo elegir entre ejecución pushdown en vivo y ejecución en memoria para el tráfico de agentes.
• Cómo publicar las mismas definiciones gobernadas en Power BI, Tableau, notebooks y aplicaciones personalizadas, y cómo exportarlas en formato Apache Ossie para herramientas externas a Mosaic.

La fuente de verdad del recorrido es Strategy One (March 2026), la versión en la que el acceso a Mosaic a través del servidor MCP quedó disponible de forma predeterminada.

Términos de Mosaic usados en esta publicación

Una breve referencia antes de llegar al modelo.

• Mosaic Schema y Mosaic Models. Dos rutas de modelado dentro de una única capa semántica universal. Mosaic Schema es el modelo empresarial gobernado de forma centralizada. Mosaic Models es la ruta de modelado autoasistida en Mosaic Studio. Los modelos pueden mapearse a dimensiones, ACL de objetos y RLS. Este recorrido usa Mosaic Models.
• Model. El artefacto de nivel superior dentro de cualquiera de las rutas de modelado. Define atributos, métricas, jerarquías y reglas de seguridad sobre tablas físicas. El recorrido usa dos Mosaic Models, uno sobre Amazon Redshift y otro sobre Aurora, vinculados entre sí.
• Atributo. Una entidad de negocio como Customer. Contiene múltiples formas: una forma de ID para la unión y una forma de visualización para la lectura. Mosaic usa formas para resolver nombres como “Carolyn Inworth” hacia el subyacente cid.
• Jerarquía. Una relación padre-hijo entre atributos. Category se consolida a través de parent hacia Department. Address se consolida a City y luego a State.
• Hecho y métrica. Un hecho es una columna numérica. Una métrica la agrega. Purchase Amount = price * quantity es una métrica base. Las métricas también pueden ser avanzadas (una agregación calificada por una condición con nombre) o compuestas (una fórmula sobre otras métricas).
• Objeto de filtro. Una condición con nombre referenciada desde métricas entre corchetes angulares. [Large Orders] es un filtro cuya calificación es Purchase Amount > 500. Una métrica referencia <[Large Orders]> sin insertar el predicado en línea.
• Cualificador de nivel. Sintaxis de expresión de métrica que fija el grano de agregación. {~+, !Customer+} fija el grano en Customer independientemente de cómo se segmente la consulta.
• Vinculación de modelos. Composición entre modelos sobre atributos compartidos (Customer, Time). Mosaic empuja los agregados a cada fuente y une los resultados intermedios en los atributos de vinculación.
• Modelo certificado. Solo los modelos certificados son accesibles a través del servidor MCP.
• En vivo o en memoria. Dos modos de ejecución por modelo: pushdown en vivo a la fuente, o respuestas desde un cubo residente en Mosaic. Detalles más adelante en esta publicación.

El ejemplo: Customer 360 entre Amazon Redshift y Amazon Aurora

El patrón C360 de las dos primeras publicaciones se mantiene. El esquema está adaptado de Stardog’s C360 Knowledge Kit, de modo que un lector que sigue la serie ve las mismas entidades, claves y pregunta ancla respondidas por una capa semántica diferente. Una organización minorista tiene registros de clientes, direcciones, tarjetas de crédito e inscripción en programas de recompensas en el lado operacional, y pedidos, productos y categorías de productos en el almacén de datos. Los usuarios de negocio quieren respuestas que abarquen ambos sin saber qué sistema contiene qué dato.

Lo que diferencia a esta publicación es cómo Mosaic accede a las dos fuentes. Mosaic no federar filas entre motores en el momento de la consulta. Planifica una consulta por fuente, empuja SQL nativo hacia abajo y une los conjuntos de resultados intermedios en el motor de Mosaic sobre los atributos compartidos declarados mediante la vinculación de modelos. El recorrido C360 modela el lado analítico como un modelo Purchase sobre Amazon Redshift y el lado operacional como un modelo Customer sobre Amazon Aurora PostgreSQL-compatible edition.

El esquema a través de las dos bases de datos:

Amazon Aurora PostgreSQL-compatible (operacional)

Amazon Redshift (analítico)

El ID compartido es cid, un entero que aparece como clave primaria en customer en Aurora y como una columna normal en purchase en Amazon Redshift. No existe ninguna restricción SQL que los vincule, y no puede haberla, porque viven en motores diferentes. Cada pregunta que une un cliente con sus pedidos debe reconciliar ese entero en algún lugar. Mosaic lo absorbe mediante el enlace de modelos en lugar de una unión materializada entre motores.

Una pregunta representativa que ejercita todo el modelo: ¿Cuáles de nuestros 20 principales clientes por gasto de por vida aún no se han inscrito en el programa de recompensas? Esta es la pregunta de inscripción automática de la publicación de Denodo. Necesita el perfil del cliente de Aurora, el gasto agregado de Amazon Redshift y el estado de inscripción de Aurora, clasificados y filtrados según definiciones que residen en la capa semántica.

Arquitectura de referencia

La Figura 1 muestra el flujo de ejecución de extremo a extremo. La ruta de autenticación de entrada va desde el cliente a través de AgentCore Gateway, una capacidad de Amazon Bedrock AgentCore, y el runtime. La ruta de consulta de salida va desde el agente Strands a través del endpoint de Mosaic MCP hacia Amazon Redshift y Amazon Aurora.

Figura 1: Arquitectura de referencia. Ruta de autenticación de entrada y ruta de consulta de salida entre el cliente, los componentes de Amazon Bedrock AgentCore, el endpoint de Strategy Mosaic MCP, el motor de Mosaic y Amazon Redshift más Amazon Aurora.

El runtime se divide en una ruta de entrada y una ruta de salida.

Entrada. Un cliente envía la pregunta del usuario a través de Amazon Bedrock AgentCore Gateway. Gateway valida el JSON Web Token (JWT) que identifica al usuario humano contra el proveedor de identidad (IdP) empresarial. Luego enruta la solicitud al runtime de Amazon Bedrock AgentCore, que aloja al agente Strands. El agente invoca a Anthropic Claude Sonnet 4.6 en Amazon Bedrock para interpretar el prompt y planificar la consulta.

Salida. Cuando el agente decide consultar el modelo semántico, su herramienta MCP se conecta directamente al endpoint de Mosaic MCP en https://<env-domain>/collaboration/mcp/mosaic a través de HTTPS. El agente presenta un token de acceso OAuth 2.0 en el encabezado Authorization: Bearer . Mosaic valida el token contra su servidor de autorización OAuth integrado y resuelve al llamador como un usuario de Strategy. Luego aplica la puerta de privilegio y de modelo certificado Use MCP Server , evalúa la seguridad a nivel de fila y a nivel de columna para ese usuario y planifica la consulta a través de los modelos Purchase y Customer enlazados. Amazon Redshift y Amazon Aurora responden a SQL nativo de la fuente que el motor de Mosaic emite por fuente.

Dos propiedades importan para el resto del recorrido. Las uniones entre fuentes ocurren porque un modelador declaró un enlace, no porque dos fuentes resulten ser accesibles. El agente solo puede recorrer los enlaces que existen en el modelo. El token que llega a Mosaic representa al usuario humano, no a una cuenta de servicio, por lo que RLS y OLS se evalúan contra la identidad del llamador de extremo a extremo. AWS Secrets Manager conserva el token de actualización del llamador entre llamadas, y la sección Governed access recorre toda la cadena de identidad.

Construir la capa semántica

El recorrido utiliza dos Mosaic Models, la ruta de modelado autogestionada con asistencia de IA en Mosaic Studio, enlazados por atributos compartidos. Mosaic Studio es la suite de autoría, y las capturas de pantalla de esta publicación provienen de su espacio de trabajo de modelado Design Center. Tres pasos: conjuntos de datos y uniones en cada lado, atributos y jerarquías, y luego métricas que contienen la lógica de negocio. Un equipo con un Mosaic Schema centralmente gobernado existente puede mapear los atributos del modelo a él y heredar dimensiones, ACL de objetos y RLS del esquema empresarial sin una revisión de seguridad paralela. Hágalo temprano si sus arquitectos de datos ya mantienen un esquema gobernado.

Dos modelos enlazados

Cada modelo de Mosaic se conecta a una fuente activa. El enlace de modelos los compone.

• Purchase: En vivo contra Amazon Redshift. Hechos en la purchase tabla (price * quantity), dimensiones en product, category, vendor, y la fecha de compra.
• Cliente: En vivo contra Amazon Aurora compatible con PostgreSQL. Dimensiones en customer, address, credit_card, rewards_account.

Dentro de cada modelo, las uniones físicas se declaran una sola vez contra el esquema de origen. El modelo Purchase resuelve purchase.pid = product.id, product.dept = category.id, y product.brand = vendor.id, más una autorreferencia en category.parent = category.id para el rollup de departamentos. El modelo Customer resuelve customer.location = address.id, customer.cid = credit_card.cid, y customer.cid = rewards_account.cid. Estas son las relaciones que Mosaic utiliza para planificar el SQL nativo de origen que envía. Nada físico cruza entre Purchase y Customer.

Los dos modelos se vinculan por Customer y Time. Cuando una pregunta necesita ambos (por ejemplo los mayores gastadores en Wisconsin extrae el estado de address y el gasto de purchase), Mosaic envía la agregación apropiada a cada fuente y combina los resultados en los atributos de vinculación. Sin ETL, sin tercera copia.

La propiedad de los dominios sigue el límite del modelo. El equipo de CRM es propietario de Customer, y el equipo del sistema de datos es propietario de Purchase. Ninguno entrega su fuente. Acuerdan los atributos de enlace, y la seguridad se propaga automáticamente desde los modelos subyacentes. No hay una unión materializada entre motores ni un esquema físico compartido entre Amazon Redshift y Amazon Aurora. La unión es el acuerdo sobre los atributos de enlace.

Atributos y jerarquías

Los atributos tienen múltiples formas. Customer usa cid como forma de ID y first_name + last_name como forma de visualización, de modo que un agente puede preguntar por “Carolyn Inworth” y Mosaic la resuelve a la clave correcta en ambos lados del enlace. La Figura 2 muestra el atributo Customer creado en Mosaic Studio, con cid como forma de ID y Full Name, First Name y Last Name como formas de visualización.

Figura 2: Definición del atributo Customer en Design Center. cid es la forma de ID utilizada para unir sobre la clave subyacente. Full Name, First Name y Last Name son formas de visualización.

Dos jerarquías son importantes para C360:

• La jerarquía Category se consolida a través de parent hasta Department. La category.parent autorreferencia significa que una pregunta a nivel de departamento agrega de manera consistente.
• Address se consolida a través de City hasta State con el mismo patrón. Eso convierte State = 'WI' en una calificación de un solo atributo en lugar de una unión que el agente debe construir.

La Figura 3 muestra la jerarquía geográfica creada en Design Center, que encadena State a través de City y ZIP Code hasta Customer.

Figura 3: Jerarquía geográfica en Design Center para el modelo Customer. State se consolida a través de City y ZIP Code hasta Location, y Location se enlaza con Customer.

El agente pregunta por State = 'WI', no por address.state. Los nombres de las columnas físicas no salen del modelo. Cada consumidor de la capa semántica ve la forma del atributo y sus formas de visualización, y la jerarquía lleva la consolidación automáticamente.

Métricas: base, avanzadas, compuestas, de inteligencia de tiempo

Una métrica base aplica una función de grupo a un hecho. Purchase Amount es Sum(price * quantity) sobre la tabla purchase .

La Figura 4 muestra la métrica base Purchase Amount creada en Mosaic Studio: la fórmula Price * Quantity, con un campo de descripción que le indica al agente qué significa la métrica en términos de negocio.

Figura 4: Métrica Purchase Amount creada en Design Center. La fórmula multiplica el precio por la cantidad, y la descripción le indica al agente qué significa la métrica en términos de negocio.

Los conceptos interesantes de C360 son las métricas avanzadas: una agregación calificada por una condición con nombre. En Strategy, las condiciones son referencias a objetos de filtro entre corchetes angulares, no predicados en línea. Los objetos de filtro son objetos del modelo con su propio nombre, descripción y permisos, por lo que son reutilizables y auditables en todas las métricas que comparten una definición.

Defina los filtros una sola vez:

Cada objeto de filtro lleva un nombre, una descripción, una calificación y permisos de acceso. La forma que un modelador crea o exporta para [Large Orders] tiene este aspecto:

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

Luego haga referencia a los filtros en las expresiones de métrica. Cada una de estas es una métrica avanzada: una agregación base calificada por un filtro con nombre.

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

La Figura 5 muestra la vista de Design Center de una métrica avanzada con una condición de filtro aplicada. Utiliza el mismo patrón de autoría que el Large Order Spend.

Figura 5: Autoría de una métrica avanzada en Design Center, mostrando la fórmula base y la condición de filtro referenciada desde el objeto de filtro Large Orders.

Customer Lifetime Spend también necesita un calificador de nivel, porque lifetime significa todo el historial sin importar cómo se segmente la pregunta actual:

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

El ! antes Customer establece la agrupación en none, de modo que la métrica devuelve el total completo de cada cliente en cada fila en lugar de colapsar en una fila por cliente. Vea Strategy Metric Level Symbols para ver la sintaxis completa.

Nótese que [Big Spender] en la tabla de filtros califica sobre una expresión de métrica en lugar de un predicado de atributo. Los objetos de filtro pueden aplicar condiciones sobre cualquiera de los dos. Share of wallet es una métrica compuesta, construida a partir de otras métricas:

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

Los niveles y las condiciones se trasladan de los componentes sin cambios. Share of wallet es una razón, por lo que no se suma ni se promedia. La cuota en una región de AWS no es el promedio de la cuota de cada cliente, y la descripción de la métrica se lo indica al agente. Vea Strategy Conditional Metrics.

Más allá de las métricas base, avanzadas y compuestas, Mosaic incluye métricas de inteligencia temporal gobernadas como expresiones de primera clase. Previous Year, Previous Quarter, Year-to-Date, y Quarter-to-Date se declaran una sola vez en el modelo y se conservan a través de las segmentaciones, de modo que una pregunta como how does Sports spend this year compare with last year se convierte en una selección de atributo y dos referencias a métricas en lugar de un filtro de fechas SQL escrito a mano. Los calendarios personalizados se adjuntan a nivel de modelo, de modo que la misma expresión de año contra año funciona para un año fiscal que termina en septiembre y para un año calendario que termina en diciembre. Vea Governed Time-Intelligence Metrics in Mosaic.

Edite el objeto de filtro una vez y el panel de Power BI, la extracción SQL y el agente se actualizan todos juntos. Eso es lo que le aporta un artefacto de modelo con nombre y gobernado, algo que un predicado SQL en línea no puede ofrecer.

Cómo planifica y ejecuta consultas Mosaic

El motor de Mosaic analiza cada llamada MCP query como SQL en dialecto Trino, resuelve las referencias dimensionales a los modelos subyacentes Purchase y Customer, aplica el RLS o el OLS al que está sujeto quien realiza la llamada, y planifica el SQL físico por fuente. El dialecto coincide con el que Strategy publica para la herramienta de consultas del MCP query tool, de modo que el SQL que emite el agente es portátil entre clientes MCP que se conectan al mismo modelo certificado.

Para la pregunta de inscripción automática, la planificación se desarrolla así:

1. Empuje hacia abajo a Amazon Aurora: una unión de customer y rewards_account sobre cid, proyectando el perfil y rewards_account.create_date, filtrada donde la inscripción es null. Devuelve una fila por cada cliente no inscrito.
2. Empuje hacia abajo a Amazon Redshift: SUM(price * quantity) agrupado por cid. Devuelve una fila por cliente con el gasto total.
3. Combinación dentro de Mosaic: unir los dos conjuntos de resultados intermedios por cid (el atributo de enlace), ordenar por gasto de por vida y devolver los 20 primeros.

Aurora ejecuta un join transaccional de perfiles. Amazon Redshift ejecuta la agregación del hecho. Mosaic gestiona el join entre motores sobre un conjunto intermedio pequeño (una fila por cliente, no una fila por pedido). Un pipeline escrito a mano aproxima la misma forma y luego debe mantenerse sincronizado para siempre.

Un detalle de SQL importa. Las métricas son valores gobernados, pero Trino las trata como columnas seleccionadas, por lo que cuando una consulta usa GROUP BY, las métricas necesitan un envoltorio de agregación como SUM(metric_name). La definición de la métrica, sus condiciones y sus rutas de join siguen resolviéndose en Mosaic. La agregación externa es responsabilidad del llamador. Por lo tanto, una proporción no aditiva como share of wallet necesita indicarlo en su descripción.

Pushdown en vivo o en memoria

Cada modelo de Mosaic se ejecuta en uno de dos modos.

Ambos modos aplican las mismas reglas de seguridad. RLS y OLS se configuran una sola vez en el modelo y se evalúan independientemente de dónde provenga la respuesta. La elección es una cuestión de rendimiento y costo.

El tráfico de agentes es repetitivo y con ráfagas. Un agente que descompone top spenders in Wisconsin en varios seguimientos exploratorios lanza muchas consultas pequeñas sobre la misma porción reciente. Servir eso desde memoria convierte un gasto de warehouse variable por consulta en capacidad fija de Mosaic, y normalmente es más rápido. Para cargas de trabajo interactivas de agentes sobre una ventana acotada, in-memory suele ser a la vez más rápido y más barato. Configure los entitlements del lado de Mosaic antes de cambiar un modelo a in-memory, y valídelos en la misma pasada de pruebas que use para validar los números.

Una definición, cuatro interfaces

Las métricas, atributos, jerarquías y reglas de seguridad construidas en la sección anterior llegan a cada consumidor mediante protocolos nativos. Sin traducción de conectores, sin re-implementación de métricas, sin divergencia.

El mismo modelo Mosaic certificado que consume el agente Strands de este recorrido también atiende a un analista de negocios que trabaja en Amazon Quick, que registra Mosaic MCP como un conector autenticado mediante OAuth. No se requiere una segunda integración.

Acceso gobernado: propagación de identidad y aplicación en tiempo de ejecución

Mosaic aplica el acceso en la capa semántica, antes de que una consulta llegue a Amazon Redshift o Aurora. Los roles de RR. HH. y fraude ven campos de información de identificación personal (PII) como ssn y card_num. Los roles de marketing y análisis no. La aplicación es idéntica ya sea que quien llama sea un agente Strands sobre MCP, un analista en Excel sobre XMLA o un cuaderno sobre JDBC. Un solo conjunto de objetos RLS y OLS, una única puerta del modelo certificado, una sola verificación de privilegios. Los atributos y las métricas marcados como sensibles también alimentan Mosaic Sentinel Risk Management, que alerta sobre las consultas que tocan objetos marcados y detecta anomalías de comportamiento como una capa de defensa en profundidad junto a OLS.

La Figura 6 muestra la cadena de propagación de identidad en dos carriles: el protocolo de enlace OAuth de entrada que se ejecuta una vez por usuario y la ruta por solicitud que se ejecuta en cada llamada de herramienta del agente. Cada carril transporta la identidad del usuario de extremo a extremo para que Mosaic pueda aplicar RLS y OLS sobre quien llama en lugar de una cuenta de servicio.

Figura 6: Cadena de propagación de identidad. El protocolo de enlace OAuth de entrada se ejecuta una vez por usuario, o en la renovación del token de actualización (pasos 1-4). La ruta por solicitud se ejecuta en cada llamada de herramienta del agente (pasos 5-10). Nada en la cadena vuelve a delimitar el alcance a una cuenta de servicio. Mosaic evalúa la gobernanza sobre la identidad de usuario de Strategy de quien llama.

La cadena sigue dos carriles.

Protocolo de enlace OAuth de entrada (una vez por usuario). El usuario humano se autentica contra el IdP empresarial. La aplicación inicia un flujo de OAuth 2.0 Authorization Code contra Strategy Library en /collaboration/authorize con el alcance offline_access. Strategy Library, federado al mismo IdP mediante SAML u OIDC, devuelve un par de tokens de actualización y de acceso en /collaboration/token. La aplicación persiste el token de actualización en AWS Secrets Manager, indexado por la reclamación sub del IdP del usuario.

Ruta por solicitud (cada llamada de herramienta del agente). AgentCore Gateway valida el JWT del IdP y enruta al runtime de AgentCore, que aloja al agente Strands que invoca a Claude Sonnet 4.6 en Amazon Bedrock. La herramienta MCP del agente recupera el token de actualización del usuario de Secrets Manager, lo canjea por un token de acceso nuevo y presenta Authorization: Bearer <access_token> a /collaboration/mcp/mosaic. Mosaic resuelve el token a un usuario de Strategy, aplica la Use MCP Server puerta de privilegio y de modelo certificado, y RLS y OLS, y luego planifica y ejecuta contra Purchase y Customer. Un analista de marketing no ve ssn ni card_num. Un analista de fraude sí.

Nada en la cadena reasigna el alcance a una cuenta de servicio. La gobernanza evalúa con la identidad del llamante desde el IdP hasta el motor de Mosaic.

Exponer la capa a través del servidor MCP de Mosaic

Strategy Library expone dos endpoints MCP:

Ambos funcionan de manera independiente. Este recorrido usa Mosaic MCP. Poner la capa semántica directamente frente al agente de Strands omite un salto de inferencia.

La cadena de herramientas

Cuatro herramientas, encadenadas desde el proyecto hasta el modelo, la semántica y la consulta.

El agente encadena estas llamadas automáticamente. get_projects y get_models reducen al modelo correcto por descripción antes de que el agente lea un nombre de columna. get_semantics devuelve las definiciones gobernadas que el agente luego usa para componer SQL contra nombres de objetos reales: Sports Share of Wallet como una métrica compuesta, Customer Lifetime Spend con ámbito en Customer, la jerarquía Category y la fórmula de cada métrica.

Dos convenciones de SQL específicas de Mosaic son importantes. Los identificadores de columna siguen un patrón <form>__<name> y deben ir entre comillas dobles ("customer__customer name"). Los atributos de tiempo se exponen tanto como columnas base como columnas de intervalo pre-agrupadas ((day interval), (month interval)), y la documentación dice explícitamente que se usen las columnas de intervalo para las agregaciones agrupadas por tiempo en lugar de date_trunc.

Los metadatos son lo que lo hace preciso

get_semantics devuelve definiciones, pero el agente aún debe elegir la métrica correcta. Sin descripciones, Total Spend y Customer Lifetime Spend parecen intercambiables, y no lo son. Cuatro propiedades hacen la mayor parte del trabajo: descripciones de objetos (qué significa la métrica y cuándo no usarla, incluido el comportamiento de agregación para métricas no aditivas), definiciones semánticas (cómo se componen las métricas compuestas), relaciones (qué atributos son segmentaciones válidas) y contexto de gobernanza (para que el agente pueda decir qué no puede ver en lugar de presentar un número filtrado como completo). La descripción del modelo es lo primero que get_models devuelve y es cómo el agente elige el modelo correcto. Mosaic puede importar metadatos de catálogos ascendentes, por lo que las descripciones de columnas ya mantenidas fluyen sin necesidad de volver a escribirlas.

Desplegar el agente

Strands es un pequeño framework para construir agentes. Un breve punto de entrada en Python conecta Claude Sonnet 4.6 en Amazon Bedrock al endpoint MCP de Mosaic como fuente de herramientas. El runtime de AgentCore aloja el proceso. AgentCore Gateway termina las solicitudes entrantes y reenvía el JWT del usuario humano.

El prompt del sistema importa. Déle al agente instrucciones explícitas para seguir el patrón de llamada de tres pasos antes de escribir SQL: get_projects, luego get_models, luego get_semantics sobre el modelo objetivo. Indíquele que haga referencia únicamente a los nombres de atributos y métricas que get_semantics devolvió. Incluya una breve sección sobre la terminología del negocio en el modelo objetivo (Customer Lifetime Spend es el total del cliente a lo largo de su historial independientemente del corte actual. Sports Share of Wallet es una proporción. Y así sucesivamente). Esta es la ingeniería de prompts que más rinde en precisión.

Active el almacenamiento en caché de prompts de Amazon Bedrock para la parte reutilizada del prompt del sistema. El payload de get_semantics alcanza unos pocos miles de tokens y no cambia dentro de una versión del modelo, por lo que el almacenamiento en caché reduce el costo de tokens de entrada por llamada en invocaciones repetidas. El tráfico de agentes contra una capa semántica estable es exactamente el patrón repetitivo y en ráfagas que más se beneficia.

Dos efectos se acumulan en la ruta del MCP. Primero, get_semantics devuelve contexto de negocio comprimido (definiciones de métricas, jerarquías, formas de atributos) en lugar del DDL bruto del esquema, de modo que el modelo razona sobre un payload más pequeño y de mayor señal. El benchmark publicado por Strategy mide el impacto en el costo de tokens de entrada y por consulta de servir contexto semántico frente al esquema bruto. Segundo, el almacenamiento en caché de prompts de Bedrock mantiene ese payload ya comprimido caliente entre llamadas. Para el tráfico repetitivo de agentes, ambos efectos se aplican por llamada: el modelo razona sobre contexto comprimido y las llamadas repetidas acceden a la caché.

Verificación

Para confirmar que la capa semántica, el agente y el flujo de identidad funcionan según lo previsto, ejecutamos tres categorías de consultas a través del agente y luego una reejecución de gobernanza de una de ellas con otro rol.

Consulta 1, solo Aurora. Lista nuestros clientes en Wisconsin, con su ciudad.

El agente genera una consulta contra el modelo Customer que proyecta las formas de visualización de Customer y City y filtra el estado a WI:

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

Mosaic envía una única consulta a Aurora y devuelve las filas. Amazon Redshift no se ve afectado.

Consulta 2, solo Amazon Redshift. ¿Cuáles son nuestros 10 productos principales por unidades vendidas?

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

Toda la consulta se envía a Amazon Redshift. Aurora no se ve afectada.

Consulta 3, entre modelos. ¿Cuáles de nuestros 20 clientes principales por gasto de por vida aún no se han inscrito en el programa de recompensas?

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 planifica a través de ambos modelos. El perfil y el estado de inscripción provienen de Aurora, la agregación de gasto de Amazon Redshift, unidos por el atributo de vinculación Customer dentro del motor de Mosaic, luego se filtra y se obtiene el top-N. El agente no tuvo que definir Customer Lifetime Spend. Hizo referencia a la métrica por su nombre y Mosaic resolvió la fórmula, el calificador de nivel y las rutas de vinculación.

Repetición de gobernanza. Ejecutamos la Consulta 1 con ssn añadido a la proyección como dos llamadores. Como analista de fraude, get_semantics devolvió el atributo SSN y la consulta devolvió los valores. Como analista de marketing, get_semantics devolvió un atributo de Customer sin ssn en absoluto, por lo que el agente no tenía ningún atributo que proyectar. Misma solicitud, mismo texto de consulta, dos respuestas correctas a partir de una sola definición.

Confirmación entre interfaces. Abrimos el mismo modelo certificado de Customer en Excel a través del endpoint XMLA de Mosaic y arrastramos State y Customer Lifetime Spend a una tabla dinámica. Los totales a nivel de estado coincidieron exactamente con las cifras del agente.

Al principio de la ejecución, el agente promedió la cuota de cartera entre los clientes, el clásico error de métrica no aditiva. Añadir una línea a la descripción de la métrica (“métrica de razón. No promediar entre clientes, recalcular a partir de los componentes”) lo detuvo. Ese es el caso de escribir las descripciones de las métricas en el primer sprint en lugar del último.

Extensión a otras fuentes de datos

El mismo mecanismo de vinculación se extiende a una tercera fuente: eventos de clickstream en Amazon Simple Storage Service (Amazon S3) consultados a través de Amazon Athena, tablas en Apache Iceberg en Amazon S3 Tables, una capacidad de Amazon S3, o una fuente SaaS como un CRM. Modele la fuente en Mosaic, vincúlela por Customer y Time, y las preguntas de navegación a compra se componen en la misma vista de cliente sin una tercera canalización. Añadir una fuente no cambia las definiciones de métricas que ya existen. El agente solo puede recorrer las rutas que un modelador declaró. AWS Lake Formation gobierna el acceso a las tablas subyacentes del lago. El RLS y el OLS de Mosaic se aplican encima.

El mismo patrón de fuente en vivo se aplica a todos los sistemas del catálogo de fuentes de datos compatibles de Strategy, que cubre bases de datos locales como PostgreSQL y MySQL junto con los almacenes y motores ya mencionados en esta publicación.

Interoperabilidad con Apache Ossie

Algunas herramientas no querrán depender de una única capa semántica. Apache Ossie (incubating) es la especificación abierta para ese vacío, lanzada como Open Semantic Interchange el 23 de septiembre de 2025 y ahora en el Apache Incubator como Apache Ossie (incubating). Define un formato neutral respecto al proveedor para métricas, dimensiones, relaciones y conceptos de negocio, de modo que las definiciones se muevan entre herramientas sin necesidad de volver a escribirlas. Strategy participa junto a Snowflake, Dremio, dbt Labs, Salesforce y otros.

Mosaic exporta e importa artefactos de Ossie. Las definiciones de métricas y dimensiones modeladas sobre Amazon Redshift se publican como YAML de Ossie consumibles por herramientas compatibles con Ossie sin necesidad de un conector de Mosaic. Las definiciones creadas en otros lugares (una métrica mantenida en dbt, una dimensión estandarizada en un catálogo) fluyen hacia Mosaic en lugar de tener que reimplementarse. Los artefactos son texto plano, por lo que viven en Git y se promueven entre entornos como cualquier otro código.

Apache Ossie es todavía incipiente. Úselo donde la portabilidad importe más y la fidelidad importe menos, por ejemplo fórmulas, dimensiones, descripciones y metadatos de propiedad, mientras mantiene las políticas de gobernanza, la estrategia de ejecución y la configuración de seguridad de forma nativa en Mosaic.

Despliegue: Strategy Cloud

Mosaic se ejecuta como un servicio gestionado en Strategy Cloud. Strategy opera la aplicación. Las conexiones a Amazon Redshift y Amazon Aurora atraviesan la red desde el egreso de Strategy Cloud. Usted incluye en la lista de permitidos los CIDR de Strategy Cloud en los grupos de seguridad de origen.

Observabilidad

Dos planos de observabilidad cubren el camino desde la pregunta hasta la respuesta.

Sentinel y Platform Analytics cubren el lado de las consultas. Sentinel captura la duración de las consultas casi en tiempo real, las consultas lentas y el uso por usuario, herramienta y modelo.

AgentCore Observability, una capacidad de Amazon Bedrock AgentCore, cubre el lado del agente: pasos de planificación, llamadas a herramientas y latencia por turno. Sentinel y Platform Analytics muestran qué sucedió una vez que la solicitud llegó a Mosaic. AgentCore Observability muestra lo que el agente estaba haciendo antes de llegar allí.

Conclusión

La analítica agéntica confiable combina razonamiento sólido, contexto de negocio confiable y ejecución segura. Amazon Bedrock proporciona el modelo, Strategy Mosaic proporciona la capa semántica gobernada sobre datos en vivo, y Amazon Bedrock AgentCore aloja al agente y finaliza la autenticación. El agente habla con la capa semántica, no con Amazon Redshift ni Aurora directamente. Los esquemas evolucionan, el modelo semántico absorbe el cambio, y las mismas definiciones sirven a Power BI, Tableau, notebooks, el agente Strands y Amazon Quick. A través de Apache Ossie, también llegan a herramientas que no se conectan a Mosaic.

Por dónde empezar

• Elija una métrica que actualmente se discuta (NRR, margen de contribución y clientes activos son candidatos comunes). Una métrica con más de una definición en circulación.
• Escriba de tres a cinco preguntas de negocio sobre ella. Estas se convertirán en sus pruebas de aceptación.
• Modele su fuente principal en Mosaic y consiga que la métrica devuelva un número defendible.
• Vincule fuentes adicionales de forma incremental, de una en una, sobre los atributos que ya existen en el modelo.
• Redacte descripciones para cada métrica y atributo que el agente verá. Aquí es donde más se gana en precisión.
• Conecte el agente de Strands a través de Mosaic MCP y ejecute sus preguntas de aceptación.
• Observe los patrones reales de consulta durante un par de semanas y luego mueva lo más usado a memoria.
• Exporte las definiciones estables a Apache Ossie y colóquelas bajo control de versiones.

Lecturas adicionales

• 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)
• Cree una capa semántica para IA agéntica en AWS con Stardog y Amazon Bedrock AgentCore
• Cree una capa semántica para IA agéntica en AWS con Denodo y Amazon Bedrock AgentCore

Sobre los autores