用 EDB Postgres AI 和 Amazon Bedrock 代理 Core 为代理AI 构建语义层

中文版正在随流水线自动整理，稍后刷新即可；可先阅读下方英文原文。

本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Artificial Intelligence

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.

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) and registered as an MCP target on AgentCore Gateway, 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 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 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 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.

Example use case: C360 on EDB Postgres AI

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.

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:

- Who are our top 10 customers by total spend, and what state is each in?

- How many big spenders do we have in each state?

- Can you list 10 customers and the state each lives in?

- Which 10 products have sold the most units?

- 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. 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.

Outbound to the semantic layer: The agent’s tool call is an MCP request. AgentCore Gateway supports MCP server targets directly. AIDB’s edb-endpoints HTTP server speaks streamable HTTP MCP with HTTP Basic authentication, 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) 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 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. AIDB captures OpenTelemetry traces for SQL execution 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).

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 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 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. 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, register the remote model with aidb.create_model. 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 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 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, see the EDB documentation.

Govern access

Governance in this architecture runs through Postgres primitives all the way down. The AIDB MCP endpoint has no permission system of its own: “Postgres grants decide what each agent can run” (MCP endpoint reference). Each MCP request authenticates with a Postgres username and password over its own connection, so current_user inside every tool call is the agent’s role, visible in pg_stat_activity like other connections.

The following diagram traces how identity flows from the end user through AgentCore to the Postgres role that evaluates the SQL, and how the resulting trace is captured for audit. The chain runs in four phases: inbound trust at the Gateway, outbound credential from AgentCore Identity, enforcement in Postgres through GRANT and row-level security, and audit through OpenTelemetry traces in the aidb_otel schema.

Inbound trust at Gateway: 1. The end user authenticates with Amazon Cognito and receives a JWT bearer token. 2. The client calls AgentCore Gateway with the token in the Authorization header. 3. The Gateway JWT authorizer validates the token against the Cognito user pool’s discovery URL. 4. Gateway evaluates its Cedar policy against the token’s claims to decide which tool this agent can call.

Outbound credential to AIDB: 5. Gateway resolves the outbound credential for the MCP target from the AgentCore Identity credential provider. For AIDB, this is a Postgres username and password used as HTTP Basic auth. 6. Gateway forwards the MCP streamable-HTTP request to the ALB, which forwards it to edb-endpoints.

Enforcement in Postgres: 7. edb-endpoints opens a Postgres connection using the username and password from the Basic auth header. Postgres authenticates the login role per pg_hba.conf, and current_user inside the tool call is that role. 8. Column-level GRANT statements and row-level security policies on c360 tables enforce what rows and columns the tool call returns. A denial surfaces as a Postgres permissio

Auto-fetched and translated by AI Atlas. All rights belong to the original author.