EDB incorpora ao Postgres uma camada semântica para agentes e a conecta ao Bedrock

O problema clássico do text-to-SQL: o agente vê os nomes das colunas, mas não entende o negócio por trás delas. Ele não sabe que um «grande cliente» na sua empresa significa um pedido acima de 250 dólares, nem que a coluna price guarda o valor de todo o pedido. O resultado são números bonitos, porém errados. Em mais um artigo da série sobre camadas semânticas, a AWS mostra a abordagem da EDB: em vez de criar um sistema separado de significados, colocá-lo no mesmo Postgres em que estão os dados.

Como funciona

O EDB Postgres AI tem a extensão AIDB. Ela cria uma base de conhecimento semântica (SemKB) sobre o esquema. Nela entram as definições de tabelas, views e colunas junto com o texto de COMMENT ON. Tudo isso vira embeddings, e o agente procura a tabela certa pelo significado, e não pelo nome. As chaves estrangeiras se transformam automaticamente em caminhos de junção entre tabelas.

A criação de conteúdo se resume a três coisas. Primeira: comentários nas colunas. Segunda: termos de negócio como views com comentário próprio, por exemplo a view big_spender, cuja definição fica em um só lugar para todos os agentes e dashboards. Terceira: aliases semânticos, ou seja, SELECTs parametrizados e nomeados com descrição em linguagem natural. O agente encontra esse alias pelo significado e o chama como uma ferramenta pronta.

No exemplo do artigo, o custo do erro fica evidente. Se o agente ler purchases.price como preço unitário e multiplicar pela quantidade, o principal cliente aparece com 502.529 dólares em vez dos reais 27.991,66. Um único comentário na coluna fecha essa brecha.

Como o agente chega aos dados

O esquema é este. O analista faz login pelo Amazon Cognito e chama o AgentCore Gateway com um JWT. O Gateway verifica o token e a política Cedar e depois encaminha a requisição ao runtime do agente no Strands Agents, onde o Claude no Bedrock faz o planejamento. O agente chama as ferramentas por MCP. O servidor edb-endpoints embutido no AIDB já fala MCP sobre streamable HTTP com autenticação Basic, então o Gateway se conecta a ele diretamente por meio de um Application Load Balancer. Não são necessárias Lambdas nem camadas intermediárias.

A senha do papel do Postgres fica guardada no AgentCore Identity, que a insere em cada requisição de saída. O código do agente nunca vê essa senha.

Quem decide as permissões é o Postgres, não o prompt

O trecho mais útil do artigo é a governança. O endpoint MCP não tem um sistema próprio de permissões: o que é permitido é decidido pelos GRANTs comuns. Cada requisição abre uma conexão separada com o login do cabeçalho Basic, de modo que current_user dentro da ferramenta é o papel do agente, visível em pg_stat_activity.

Os autores criam dois papéis. mcp_agent_full vê tudo, mcp_agent_restricted vê tudo, exceto customers.ssn. O prompt, o catálogo de ferramentas e o código do agente são idênticos. Diante do pedido «mostre cinco clientes com os números do seguro social», o primeiro papel recebe os dados e o segundo recebe o erro permission denied, que o MCP repassa sem alterações. Além disso, é possível ativar row-level security para que papéis diferentes vejam linhas diferentes.

A auditoria também permanece no banco. O AIDB grava traces OpenTelemetry da execução de SQL no esquema aidb_otel, e eles podem ser analisados com SQL comum. Os traces do AgentCore sobre chamadas de ferramentas, LLM e tokens vão para o CloudWatch.

O que fazer com isso

Se você tem um Postgres operacional e está construindo um agente para análise ou suporte, comece pelo barato: escreva um COMMENT para as colunas pouco óbvias e mova os termos de negócio para views. Isso melhora a precisão mesmo sem o AIDB.

Há também limitações. A solução gira em torno do ecossistema da EDB: AIDB, sua AMI e o servidor MCP. O SemKB indexa o esquema, não os dados, então a qualidade depende da disciplina nos comentários. Os modelos na AWS não estão disponíveis em todas as regiões. O exemplo foi construído sobre um pequeno conjunto de demonstração de quatro tabelas, e com centenas de tabelas a busca semântica terá de ser verificada separadamente.

Em resumo: a ideia de que «significado e permissões vivem junto dos dados» elimina toda uma classe de problemas de sincronização de catálogos e permite confiar mais nas restrições de acesso do que em pedidos no prompt de sistema.