Agentes com fronteira de domínio e avaliação

A regra que organiza tudo: uma ferramenta, uma Service Operation. O agente não recebe uma ferramenta chamada banco com dez parâmetros. Ele recebe Retrieve no Current Account para consultar saldo e Initiate no Payment Order Initiation para criar uma ordem de pagamento. O nome da ferramenta já diz qual domínio ela toca e qual action term ela executa, exatamente o vocabulário da aula 03.

Isso resolve três problemas de uma vez.

Fronteira: o agente só alcança os domínios que você expôs. Se não existe ferramenta em Customer Consent, ele não altera consentimento, por mais criativo que seja o prompt.

Auditoria: cada chamada de ferramenta vira uma linha de log com Service Domain, action term e Control Record afetado. Quem audita lê o mesmo mapa que o arquiteto desenhou.

Contrato: a ferramenta nasce do OpenAPI da Semantic API (aula 04). O schema que valida a requisição do canal valida também a requisição do agente. Não existe um segundo contrato, mais frouxo, só para a IA.

Na prática, a tentação é agrupar: 'uma ferramenta de pagamentos' que decide sozinha se consulta, inicia ou confirma. Resista. Ferramenta larga é fronteira larga, e fronteira larga é o que você passou o módulo 2 aprendendo a não desenhar. Lembre também que Payment Execution e Payment Instruction são obsoletos na versão 14: ferramenta com esses nomes é dívida de nascença.

O desenho acima tem três camadas entre o agente e o banco, e nenhuma é opcional.

Gateway: o Amazon Bedrock AgentCore Gateway recebe a especificação OpenAPI da Semantic API e a expõe como ferramentas MCP. O agente enxerga Retrieve e Initiate como ferramentas; o banco continua enxergando a mesma API de sempre. Nenhum código de integração novo, nenhum contrato paralelo.

Política: o Policy in AgentCore avalia regras Cedar antes de cada chamada de ferramenta. A regra é declarativa: este agente, para este cliente, pode chamar Retrieve no Current Account; pode chamar Initiate no Payment Order Initiation só se houver aprovação registrada. A política vive fora do prompt. Prompt é sugestão; política é bloqueio.

Aprovação humana: toda movimentação de dinheiro passa por uma pessoa. Não é desconfiança do modelo, é desenho: o agente prepara a ordem com todos os campos preenchidos, o humano aprova em uma fila, e só então o Initiate acontece. Consulta de saldo não precisa disso; transferência precisa, sempre.

Há uma quarta camada que o diagrama marca e muita gente esquece: o art. 20 da LGPD dá ao titular o direito de pedir revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses. Se o agente nega um limite ou recusa uma operação, a pessoa pode pedir que um humano reveja. Então o laço precisa de um caminho de volta, com a decisão, o motivo e quem revisou.

Na aula 08 a IA rascunhou mapeamentos e um humano decidiu. A pergunta que fecha o curso é outra: como você sabe que ela continua acertando?

Golden set: um conjunto de casos com a resposta certa, revisado por dois arquitetos, com a versão do BIAN fixada no próprio arquivo (14.0, e não 'a atual'). Dois revisores porque mapeamento é interpretação: onde os dois discordam, o caso vira discussão e, resolvido, vira o exemplo mais valioso do conjunto. Versão fixada porque um rename como Payment Rail Operations para Payment Rail muda a resposta certa sem mudar o sistema.

Precisão e recall por domínio: a média geral esconde o problema. Um agente pode acertar tudo em Current Account e errar sistematicamente em Payment Orchestration, que é novo na versão 14. Meça por Service Domain e olhe para os piores, não para a média.

Limiar de confiança: abaixo de um valor que você define, o caso não é decidido pelo agente; vai para a fila humana. O valor certo depende do seu conjunto e do custo de errar em cada domínio. O que não pode é não existir.

Regressão: a cada troca de modelo e a cada versão nova do BIAN, rode o golden set inteiro antes de promover. Modelo novo não é melhor por definição; é diferente, e diferente precisa de prova.

Antes do exame, o caminho que você percorreu.

Módulo 1, o mapa: o BIAN é um mapa de capacidades, não um sistema (aula 01). As camadas organizam Service Domains, cada um com um Control Record que diz o que ele administra (aula 02). Padrões funcionais e action terms dão o verbo: Retrieve, Initiate, Update, Execute (aula 03). E o caminho segue do Service Domain até o OpenAPI da Semantic API (aula 04).

Módulo 2, o Brasil no mapa: Pix distribuído entre Payment Order Initiation, Payment Rail, Payment Settlement e Payment Confirmation, com os domínios novos da versão 14 no lugar dos obsoletos (aula 05). Open Finance, SCR, LGPD e Banco Central como obrigações que atravessam domínios, com Customer Consent como domínio próprio (aula 06).

Módulo 3, o trabalho: heatmap para ver onde os sistemas se sobrepõem e as fronteiras erradas que todo mundo desenha uma vez (aula 07). IA com grounding nas definições oficiais para rascunhar mapeamentos e contratos, humano decidindo e tudo medido (aula 08). E esta aula: agente com ferramentas por Service Operation, política, aprovação humana e avaliação contínua.

O exame final está na página do curso. Ele cobre os três módulos e, aprovado, libera o certificado. Faça sem consultar as aulas na primeira tentativa: a nota mostra o que ficou e o que pede releitura.