Build a semantic layer for agentic AI with EDB Postgres AI and Amazon Bedrock AgentCore

A new AWS Machine Learning blog post demonstrates building a semantic layer for agentic AI by running a Strands Agents agent on Amazon Bedrock AgentCore that queries EDB Postgres AI to answer customer 360 questions. EDB Postgres AI places the semantic layer inside the operational Postgres database as an AIDB extension, storing business meaning in standard Postgres COMMENT statements, deriving the join graph from foreign keys, and enforcing governance through GRANT statements and row-level security via a built-in Model Context Protocol endpoint fronted by an Application Load Balancer and registered as an MCP target on AgentCore Gateway. The post also details how Postgres roles and column-level grants return different results for different callers with unchanged agent code, and how AIDB captures OpenTelemetry traces for every SQL execution as rows in the aidb_otel schema queryable with ordinary SQL.

Artificial Intelligence https://aws.amazon.com/blogs/machine-learning/ Build a semantic layer for agentic AI with EDB Postgres AI and Amazon Bedrock AgentCore In this post, we show how to build a semantic layer for agentic AI using EDB Postgres AI https://www.enterprisedb.com/docs/aidb/latest/ . We run a Strands Agents https://github.com/strands-agents agent on Amazon Bedrock AgentCore https://aws.amazon.com/bedrock/agentcore/ that queries the layer to answer customer 360 C360 questions. Earlier posts in this series built the same C360 pattern with Stardog’s knowledge graph https://aws.amazon.com/blogs/machine-learning/build-a-semantic-layer-for-agentic-ai-on-aws-with-stardog-and-amazon-bedrock-agentcore/ , Denodo’s data virtualization platform https://aws.amazon.com/blogs/machine-learning/build-a-semantic-layer-for-agentic-ai-on-aws-with-denodo-and-amazon-bedrock-agentcore/ , AtScale’s dimensional model https://aws.amazon.com/blogs/machine-learning/build-a-semantic-layer-for-agentic-ai-on-aws-with-atscale-and-amazon-bedrock-agentcore/ , and Strategy Mosaic’s linked models https://aws.amazon.com/blogs/machine-learning/build-a-semantic-layer-for-agentic-ai-on-aws-with-strategy-mosaic-and-amazon-bedrock-agentcore/ . EDB Postgres AI puts the semantic layer inside the operational Postgres database as an AIDB extension https://www.enterprisedb.com/docs/aidb/latest/overview/ . Business meaning lives next to the data in standard Postgres COMMENT statements, the join graph comes from Postgres foreign keys, and governance uses Postgres GRANT and row-level security through the Model Context Protocol MCP endpoint https://www.enterprisedb.com/docs/aidb/latest/mcp-endpoint/ that ships with AIDB. By the end of this post you will know: - How to build an AIDB semantic knowledge base SemKB over a Postgres schema, how COMMENT ON statements and aidb.create semantic alias behave as the authoring surface, and how foreign keys crawl into join paths. - How to expose the AIDB tool catalog to an external agent through the built-in EDB MCP endpoint, fronted by an Application Load Balancer ALB https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html and registered as an MCP target on AgentCore Gateway https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-targets-mcp.html , a capability of Amazon Bedrock AgentCore. - How Postgres roles, column-level GRANT statements, and row-level security produce different results for different callers. The prompt, tool catalog, and agent code stay the same. - How AIDB captures OpenTelemetry traces https://www.enterprisedb.com/docs/aidb/latest/reference/observability/ for every SQL execution as rows in the aidb otel schema, queryable with ordinary SQL. Three layers an agent needs An agent that answers business questions from live data needs three layers: a model that plans and writes queries, a meaning layer that tells the agent what the data represents, and a runtime that hosts the agent and controls identity and access. The Stardog post https://aws.amazon.com/blogs/machine-learning/build-a-semantic-layer-for-agentic-ai-on-aws-with-stardog-and-amazon-bedrock-agentcore/ in this series introduced this framing. The model layer in this post is Anthropic Claude on Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html , the same as prior posts model availability varies by AWS Region https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html . The runtime layer is AgentCore runtime https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html , a capability of Amazon Bedrock AgentCore. AgentCore Gateway https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-core-concepts.html handles inbound authorization, and AgentCore Identity https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html , a capability of Amazon Bedrock AgentCore, holds outbound credentials for the tool targets, same as prior posts. EDB Postgres AI hosts agents and tools inside the database itself and acts as the connection point for external agents through its MCP endpoint. The meaning layer is where this post diverges from the others. Here it is a SemKB https://www.enterprisedb.com/docs/aidb/latest/semantic-knowledge-bases/ that lives inside the operational Postgres database. The schema and the business definitions are indexed together. Postgres GRANT , row-level security, and column-level grants enforce access, not an advisory system prompt. The sections that follow cover how AIDB builds the layer, how AgentCore exposes it, and how two Postgres roles asking the same question get different answers. Example use case: C360 on EDB Postgres AI The dataset is the Stardog C360 Knowledge Kit https://github.com/stardog-union/knowledge-kits/tree/main/examples/c360 , loaded into a single EDB Postgres AI instance in a dedicated c360 schema. The data model has four tables and one derived view. | Object | Key columns | | customers | cid , first name , last name , full name , email , ssn , phone , picture , location FK to locations.id | | locations | id , city , state , zip | | products | id , name , brand , dept , price | | purchases | id , cid FK to customers.cid , pid FK to products.id , date , quantity , price | | big spender view | cid , full name , state , large orders , largest order | The physical schema is a plain Postgres join graph: a customer in the customers table lives at a location , places purchases , and each purchase references a product. The semantic work rests on three business ideas that column names don’t reveal. State isn’t on the customer row. It lives in locations , reached through the customers.location foreign key, and a comment on that column tells SemKB where to find it. purchases.price records the order total. An agent that reads it as a unit price and multiplies by quantity returns $502,529 for the top customer instead of $27,991.66. Big spender is a term the business owns. Captured as a view with a COMMENT ON VIEW statement, its definition stays in one place that every agent, dashboard, and query reads from. The questions we run through the agent end to end: 1. Who are our top 10 customers by total spend, and what state is each in? 2. How many big spenders do we have in each state? 3. Can you list 10 customers and the state each lives in? 4. Which 10 products have sold the most units? 5. Can you list five customers with their Social Security numbers? used in the governance rerun . Reference architecture The following diagram shows the request path from the analyst through Amazon Bedrock AgentCore to the semantic layer inside EDB Postgres AI. The analyst authenticates with Amazon Cognito and calls AgentCore Gateway with the issued JSON Web Token JWT as a Bearer token. Gateway routes to AgentCore runtime, which plans with Claude on Amazon Bedrock. The agent calls MCP tools through Gateway, which forwards to an Application Load Balancer in the EDB Postgres AI virtual private cloud VPC and on to the edb-endpoints MCP server inside AIDB. AIDB serves the SemKB, semantic aliases, and read-only PostgreSQL tables. AgentCore traces go to Amazon CloudWatch, and AIDB captures OpenTelemetry traces as rows in the aidb otel schema inside Postgres. Two flows cross the boundary between AgentCore and EDB Postgres AI. Inbound: A client calls AgentCore Gateway with a bearer token issued by an Amazon Cognito user pool https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-idp-cognito.html . The Gateway inbound JWT authorizer https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/inbound-jwt-authorizer.html validates the token against the Cognito discovery URL. Gateway then evaluates its Cedar policy https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-authorization-flow.html against the token’s claims to decide which tools this agent, acting for this user, can invoke. It then routes the call to AgentCore runtime. The agent invokes Claude on Amazon Bedrock for planning and answer composition. Outbound to the semantic layer: The agent’s tool call is an MCP https://modelcontextprotocol.io/ request. AgentCore Gateway supports MCP server targets https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-targets-mcp.html directly. AIDB’s edb-endpoints HTTP server speaks streamable HTTP MCP with HTTP Basic authentication https://www.enterprisedb.com/docs/aidb/latest/mcp-endpoint/connecting-a-client/ , which lets Gateway treat it as an MCP server target with no translation layer. An Application Load Balancer with an HTTPS listener and an AWS Certificate Manager ACM https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html certificate fronts edb-endpoints on an Amazon Elastic Compute Cloud Amazon EC2 instance. The ALB URL is registered as the Gateway target. The AgentCore Identity credential provider https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-outbound-credential-provider.html holds the Postgres role credential and injects it as Basic auth on every outbound request. The agent code doesn’t see the Postgres credential. Observability: AgentCore emits traces for tool calls, large language model LLM calls, and token usage to CloudWatch Transaction Search https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-configure.html . AIDB captures OpenTelemetry traces for SQL execution https://www.enterprisedb.com/docs/aidb/latest/reference/observability/ as rows in the aidb otel schema inside Postgres, queryable with ordinary SQL after the database is configured to write them see enabling telemetry on the source database https://www.enterprisedb.com/docs/agent-governance/latest/connecting aidb/ . No AWS Lambda is required in this architecture. AIDB already speaks MCP, so Gateway talks to it as an MCP server target directly through the ALB. The Denodo post in this series uses the same ALB pattern in front of its MCP server, and the architecture here is unchanged other than the vendor. Build the semantic layer These steps assume AIDB is installed and enabled https://www.enterprisedb.com/docs/aidb/latest/ on the EDB Postgres AI instance and the Stardog C360 kit’s four CSVs are loaded into a dedicated c360 schema with the primary and foreign keys shown earlier. Because this layer lives in the same database as the data, there is no second system to deploy and no catalog to synchronize. The semantic layer is defined in SQL, inside the same database as the application that writes the rows. An AIDB semantic knowledge base https://www.enterprisedb.com/docs/aidb/latest/semantic-knowledge-bases/ indexes Postgres schema, not data. It embeds the definition of every table, view, and column with the COMMENT ON text alongside into a vector store that an agent can search in natural language. Three authoring tasks help the agent find the right table and column by meaning: writing COMMENT ON statements, defining business terms as views with their own comments, and registering recurring questions as semantic aliases https://www.enterprisedb.com/docs/aidb/latest/semantic-knowledge-bases/semantic-aliases/ . Comments are the simplest of the three authoring tasks and improve text-to-SQL accuracy the most for both users and agents. Add comments where the agent will look The view holds the business definition in one place, so no agent or dashboard has to redefine big spender . The time you spend on comments up front pays off on every query the agent runs afterward. Create the semantic knowledge base Create the SemKB over the c360 schema. The call registers the name, the embedding model, the target schemas, and the auto-processing mode. The embedding model is a local llama.cpp model llamacpp embeddings that ships with the AIDB Amazon Machine Image AMI . SemKB uses one embedding model per KB, so every entry sits in the same vector space. The AIDB AMI ships with a default SemKB named semkb over public , so creating c360 kb leaves two SemKBs on the instance. When more than one SemKB exists, every aidb.semantic kb search call must pass kb name explicitly. To swap the local model for a remote embedding model, such as Amazon Titan Text Embeddings on Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/titan-embedding-models.html , register the remote model with aidb.create model https://www.enterprisedb.com/docs/aidb/latest/integrating-models/remote-models/ . Pass its name as the SemKB’s model parameter. The auto processing parameter accepts Disabled , Live , or Background . Live reacts to schema changes through Postgres event triggers. Background processes them asynchronously from a worker. Disabled waits for an explicit aidb.refresh semantic kb . SemKB also crawls foreign keys into relationships https://www.enterprisedb.com/docs/aidb/latest/semantic-knowledge-bases/ at the same time. The purchases.cid foreign key becomes a join path the agent can discover by meaning, not by column name. Capture recurring questions as semantic aliases A semantic alias https://www.enterprisedb.com/docs/aidb/latest/semantic-knowledge-bases/semantic-aliases/ is a named, parameterized read-only SELECT with a natural-language description that SemKB indexes alongside the schema metadata. The agent finds it by meaning, calls it with parameters, and returns a governed answer. Aliases are AIDB’s reusable text-to-SQL building block. They sit next to tables and views in the SemKB index and show up to an agent as a tool. For a full text-to-SQL walkthrough https://www.enterprisedb.com/docs/aidb/latest/semantic-knowledge-bases/text-to-sql/ , see the EDB documentation https://www.enterprisedb.com/docs/aidb/latest/semantic-knowledge-bases/ . Govern access Governance in this architec