A published architecture describes a semantic layer embedded in an operational Postgres database and exposed to an external agent. Its significance for operators is not merely that an agent can query data, but that the query path can remain subject to established database access controls.
What the evidence says
AWS Machine Learning describes EDB Postgres AI placing the semantic layer inside the operational Postgres database through an AIDB extension. The account shows the built-in EDB MCP endpoint exposing the AIDB tool catalog, with an Application Load Balancer in front of it and the endpoint registered as an MCP target on AgentCore Gateway, which is identified as an Amazon Bedrock AgentCore capability.
In the documented example, a Strands Agents agent runs on Amazon Bedrock AgentCore and queries the semantic layer to answer customer 360 questions. The model layer uses Anthropic Claude on Amazon Bedrock, with an explicit qualification that model availability varies by AWS Region.
The account also describes authorization behavior. Postgres roles, column-level GRANT statements, and row-level security produce different results for different callers. This is the clearest evidence that access control is part of the demonstrated data path rather than an unrelated policy layer.
Operator implications
The operator takeaway is architectural: a semantic interface for agents can be located where operational data and database permissions already meet. That could let teams define agent-facing tools while retaining caller-specific controls at the database layer.
The external-agent path nevertheless spans several components: the agent runtime, AgentCore Gateway, the load balancer, the MCP endpoint, the AIDB tool catalog, and Postgres authorization. Operators evaluating the pattern should therefore treat identity propagation, role mapping, tool exposure, and database policy as one connected control surface. A correct policy in one component does not, by itself, establish that the complete path behaves as intended.
The example also suggests a practical evaluation method: test the same business question through callers with different roles and confirm that each receives only the results permitted by column grants and row-level security. That is operator analysis derived from the described authorization behavior, not a reported outcome beyond the example.
Limits and open questions
This is a single primary account and is not independently confirmed. The evidence establishes what the published example describes, but it does not establish broader operational results.
The account leaves unknown the pattern’s performance under load, latency, scaling characteristics, failure behavior, deployment complexity, and security outcomes outside the demonstrated configuration. It also does not establish how identity is mapped across every component, how policies are audited over time, or whether the approach fits other database environments, agent frameworks, models, regions, or customer 360 implementations. Those questions require separate validation before drawing broader conclusions.