# Build a semantic layer for agentic AI with EDB Postgres AI and Amazon Bedrock AgentCore > Source: > Published: 2026-11-03 16:41:13+00:00 ## [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