EDB integra en Postgres una capa semántica para agentes y la conecta con Bedrock

El problema clásico del text-to-SQL: el agente ve los nombres de las columnas, pero no entiende el negocio que hay detrás. No sabe que un «cliente grande» en su empresa significa un pedido de más de 250 dólares, ni que la columna price guarda el importe de todo el pedido. El resultado son cifras elegantes pero incorrectas. En un nuevo artículo de su serie sobre capas semánticas, AWS muestra el enfoque de EDB: en lugar de crear un sistema aparte de significados, colocarlo en el mismo Postgres donde están los datos.

Cómo funciona

EDB Postgres AI incluye la extensión AIDB. Esta crea una base de conocimiento semántica (SemKB) sobre el esquema. En ella entran las definiciones de tablas, vistas y columnas junto con el texto de COMMENT ON. Todo se convierte en embeddings, y el agente busca la tabla adecuada por significado y no por nombre. Las claves foráneas se transforman automáticamente en rutas de unión entre tablas.

La creación de contenido se reduce a tres cosas. Primera: comentarios en las columnas. Segunda: términos de negocio como vistas con su propio comentario, por ejemplo la vista big_spender, cuya definición vive en un solo lugar para todos los agentes y paneles. Tercera: alias semánticos, es decir, SELECT parametrizados con nombre y una descripción en lenguaje natural. El agente encuentra ese alias por significado y lo invoca como una herramienta ya preparada.

En el ejemplo del artículo se ve bien el coste del error. Si el agente interpreta purchases.price como precio unitario y lo multiplica por la cantidad, el cliente principal sale con 502 529 dólares en lugar de los 27 991,66 reales. Un solo comentario en la columna cierra este agujero.

Cómo llega el agente a los datos

El esquema es el siguiente. El analista inicia sesión mediante Amazon Cognito y llama a AgentCore Gateway con un JWT. El Gateway comprueba el token y la política Cedar, y luego dirige la solicitud al runtime del agente en Strands Agents, donde planifica Claude en Bedrock. El agente invoca las herramientas por MCP. El servidor edb-endpoints integrado en AIDB ya habla MCP sobre streamable HTTP con autenticación Basic, así que el Gateway se conecta directamente a él a través de un Application Load Balancer. No hacen falta Lambdas ni capas intermedias.

La contraseña del rol de Postgres la guarda AgentCore Identity, que la inserta en cada solicitud saliente. El código del agente nunca ve esa contraseña.

Los permisos los decide Postgres, no el prompt

La parte más útil del artículo es la gobernanza. El endpoint MCP no tiene un sistema de permisos propio: lo que se puede hacer lo deciden los GRANT habituales. Cada solicitud abre una conexión independiente con el login del encabezado Basic, de modo que current_user dentro de la herramienta es el rol del agente, y se ve en pg_stat_activity.

Los autores crean dos roles. mcp_agent_full lo ve todo, mcp_agent_restricted lo ve todo excepto customers.ssn. El prompt, el catálogo de herramientas y el código del agente son idénticos. Ante la petición «muéstrame cinco clientes con sus números de seguridad social», el primer rol recibe los datos y el segundo un error permission denied, que MCP transmite sin cambios. Además, se puede activar row-level security para que distintos roles vean filas distintas.

La auditoría también se queda en la base de datos. AIDB escribe trazas OpenTelemetry de la ejecución de SQL en el esquema aidb_otel, y pueden analizarse con SQL normal. Las trazas de AgentCore sobre llamadas a herramientas, LLM y tokens van a CloudWatch.

Qué hacer con esto

Si tiene un Postgres operativo y está construyendo un agente para analítica o soporte, empiece por lo barato: escriba un COMMENT para las columnas poco evidentes y traslade los términos de negocio a vistas. Esto mejora la precisión incluso sin AIDB.

También hay limitaciones. Es una solución en torno al ecosistema de EDB: AIDB, su AMI y el servidor MCP. SemKB indexa el esquema, no los datos, por lo que la calidad depende de la disciplina en los comentarios. Los modelos de AWS no están disponibles en todas las regiones. El ejemplo se basa en un pequeño conjunto de demostración de cuatro tablas, y con cientos de tablas la búsqueda semántica habrá que verificarla por separado.

En resumen: la idea de que «el significado y los permisos viven junto a los datos» elimina toda una clase de problemas de sincronización de catálogos y permite confiar en las restricciones de acceso más que en las peticiones del prompt de sistema.