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 . We run a Strands Agents agent on Amazon 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 , Denodo’s data virtualization platform , AtScale’s dimensional model , and Strategy Mosaic’s linked models .

EDB Postgres AI puts the semantic layer inside the operational Postgres database as an AIDB extension . 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 that ships with AIDB.

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 in this series introduced this framing. The model layer in this post is Anthropic Claude on Amazon Bedrock , the same as prior posts (model availability varies by AWS Region ). The runtime layer is AgentCore runtime , a capability of Amazon Bedrock AgentCore. AgentCore Gateway handles inbound authorization, and AgentCore Identity , 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 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.

Figure 1: Reference architecture for EDB Postgres AI and Amazon Bedrock AgentCore

Inbound: A client calls AgentCore Gateway with a bearer token issued by an Amazon Cognito user pool . The Gateway inbound JWT authorizer validates the token against the Cognito discovery URL. Gateway then evaluates its Cedar policy 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.

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.

The meaning layer is where this post diverges from the others. Here it is a SemKB 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.

The dataset is the Stardog C360 Knowledge Kit , loaded into a single EDB Postgres AI instance in a dedicated c360 schema. The data model has four tables and one derived view.

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.