# Design Doc: Suíte de Avaliação Contínua para Agentes com Bedrock AgentCore

Agentes LLM em produção degradam silenciosamente à medida que modelos, ferramentas e prompts evoluem — sem uma disciplina de avaliação contínua, regressões chegam ao usuário antes de serem detectadas. Este documento propõe uma arquitetura completa de avaliação offline e online usando Amazon Bedrock AgentCore, com datasets versionados, quality gates em CI/CD, sinais de runtime e testes adversariais sistemáticos.

- URL: https://fernando.moretes.com/studies/design-doc-bedrock-agentcore-evaluation-datasets

- Markdown: https://fernando.moretes.com/studies/design-doc-bedrock-agentcore-evaluation-datasets/study.md?lang=pt

- Type: Design Doc / RFC

- Company: Agent quality platform (cenário)

- Domain: IA / Qualidade

- Date: 2026-06-07

- Tags: bedrock-agentcore, llm-evaluation, agent-quality, ci-cd, adversarial-testing, tool-use-metrics, mlops, aws

- Reading time: 12 min

---

Um agente que funciona bem no lançamento pode falhar silenciosamente seis semanas depois — quando o modelo base é atualizado, uma ferramenta muda seu schema ou um novo fluxo de prompts é introduzido. Sem uma suíte de avaliação contínua com quality gates reais, você está voando cego. Este RFC descreve como construir essa disciplina sobre Bedrock AgentCore.

## O Problema: Agentes São Sistemas Compostos que Degradam de Formas Não-Óbvias

Agentes LLM não são funções determinísticas. Eles combinam um modelo de linguagem (que pode ser atualizado pelo provedor sem aviso explícito), um conjunto de ferramentas com suas próprias APIs e schemas, memória de curto e longo prazo, e uma camada de orquestração que interpreta intenção e encadeia chamadas. Cada um desses componentes pode mudar independentemente — e a interação entre mudanças é onde as regressões mais perigosas se escondem.

Considere um cenário concreto: o agente de suporte ao cliente de uma fintech usa uma ferramenta `get_account_balance` que retorna valores em centavos. O time de backend migra a API para retornar valores em reais sem atualizar a documentação da ferramenta. O agente continua funcionando — ele chama a ferramenta, recebe um número, e responde ao usuário. Mas agora informa saldos 100x maiores do que o real. Nenhum erro de runtime. Nenhum alarme de latência. A degradação é semântica, não técnica.

Esse é o problema central que uma suíte de avaliação contínua precisa resolver: **detectar degradação semântica e comportamental antes que chegue ao usuário**, em um sistema onde as peças mudam de forma assíncrona e os erros raramente são exceções — são respostas plausíveis mas incorretas.

O estado da arte em avaliação de agentes ainda está se consolidando. A maioria das equipes que conheço opera com uma combinação de: testes manuais ad hoc antes de releases, algumas métricas de satisfação do usuário coletadas de forma reativa, e alarmes de latência/erro que capturam apenas falhas técnicas. Isso é insuficiente para sistemas que tomam decisões com consequências reais. O que precisamos é de uma disciplina análoga ao que temos em sistemas de software tradicionais — testes unitários, integração, regressão, cobertura — mas adaptada para a natureza probabilística e composicional dos agentes.

## Objetivos e Não-Objetivos

- ✅ OBJETIVO: Definir uma arquitetura de avaliação offline (pré-deploy) com datasets versionados e quality gates que bloqueiam promoção de versões regressivas
- ✅ OBJETIVO: Instrumentar sinais de avaliação online (pós-deploy) que detectam degradação em produção sem depender exclusivamente de feedback humano
- ✅ OBJETIVO: Criar métricas específicas para tool-use: taxa de chamada correta, argumento accuracy, sequência de chamadas, e recuperação de erros de ferramenta
- ✅ OBJETIVO: Definir um processo de curadoria e versionamento de datasets de avaliação que evolui junto com o agente
- ✅ OBJETIVO: Incluir cenários adversariais sistemáticos: prompt injection, boundary testing, e casos de edge que expõem falhas de raciocínio
- ❌ NÃO-OBJETIVO: Definir a arquitetura interna do agente em si (roteamento, memória, RAG) — esse é um documento separado

## Contexto do Cenário

- **Sistema:** Plataforma de qualidade para agentes LLM em produção (cenário composto)
- **Infraestrutura base:** Amazon Bedrock AgentCore + AWS
- **Escala alvo:** 10-50 agentes distintos, cada um com 5-20 ferramentas, múltiplas versões em paralelo
- **Frequência de avaliação offline:** A cada PR / commit em agent config, prompt, ou tool schema
- **Frequência de avaliação online:** Contínua via sampling (estimativa: 5-15% das conversas)
- **Stack principal:** Bedrock AgentCore, S3, DynamoDB, Step Functions, Lambda, EventBridge, CloudWatch, Bedrock Evaluations
- **Tipo de documento:** RFC / Design Doc — proposta para implementação
- **Risco principal:** Degradação semântica silenciosa em produção sem detecção automatizada

## Design Proposto: Três Camadas de Avaliação

A arquitetura que proponho organiza a avaliação em três camadas complementares, cada uma com propósito, frequência e custo distintos. A metáfora útil aqui é a de defesa em profundidade — nenhuma camada sozinha é suficiente, mas juntas formam uma rede de detecção robusta.

**Camada 1 — Avaliação Offline (Pre-Deploy Gate)**

Antes de qualquer versão do agente ser promovida para produção, ela passa por uma bateria de testes offline contra um dataset versionado armazenado no S3. O dataset é estruturado como um conjunto de casos de teste, cada um contendo: a entrada do usuário (ou sequência de turnos para conversas multi-turn), o conjunto esperado de chamadas de ferramenta (com argumentos esperados e tolerâncias), a resposta esperada (ou critérios de avaliação quando não há resposta determinística), e metadados de categoria (tipo de tarefa, nível de dificuldade, se é adversarial).

O Bedrock AgentCore executa o agente em modo de avaliação — com as mesmas ferramentas configuradas, mas em ambiente isolado com ferramentas mockadas que retornam respostas controladas. Isso é crítico: você não quer que testes offline façam chamadas reais a APIs de produção, mas também não quer mocks tão simplificados que não testam o raciocínio do agente sobre as respostas das ferramentas.

As métricas coletadas nessa camada incluem: **tool-call accuracy** (o agente chamou a ferramenta certa?), **argument fidelity** (os argumentos estavam corretos dentro de tolerância?), **call sequence correctness** (para tarefas que requerem sequência específica de chamadas), **unnecessary tool calls** (o agente chamou ferramentas desnecessárias, indicando raciocínio confuso?), e **final response quality** avaliada por um LLM-as-judge configurado via Bedrock Evaluations.

O quality gate é definido como um conjunto de thresholds por categoria de métrica. A proposta inicial: tool-call accuracy ≥ 0.90 no conjunto completo, ≥ 0.95 no subconjunto de casos críticos (marcados no dataset), e nenhuma regressão > 5 pontos percentuais em relação à baseline da versão anterior. Esse último critério — regressão relativa — é tão importante quanto o threshold absoluto: um agente que já era ruim em algo não deve piorar ainda mais.

**Camada 2 — Testes Adversariais**

Separados do dataset de avaliação padrão, mantemos um dataset adversarial com categorias específicas: prompt injection attempts (tentativas de fazer o agente ignorar suas instruções de sistema), boundary probing (inputs que testam os limites de políticas — o que o agente faz quando recebe um pedido ambíguo que poderia ser legítimo ou malicioso?), e casos de edge de tool-use (o que acontece quando uma ferramenta retorna um erro inesperado? O agente recupera graciosamente ou entra em loop?).

Esses testes não têm o mesmo regime de pass/fail dos testes funcionais — eles têm critérios de comportamento esperado. Para prompt injection, o critério é que o agente mantenha suas instruções de sistema. Para boundary cases, o critério é que o agente escalona ou recusa de forma apropriada em vez de aluciná-la resposta. Para erros de ferramenta, o critério é recuperação em no máximo N tentativas com fallback gracioso.

**Camada 3 — Sinais Online (Production Monitoring)**

Em produção, instrumentamos um pipeline de avaliação assíncrono que processa uma amostra das conversas reais. O sampling é estratificado — garantimos representação de diferentes tipos de tarefa e não apenas volume. Conversas selecionadas são enviadas para um Step Functions workflow que: extrai os traces de tool-use do AgentCore, executa avaliação LLM-as-judge nos turnos finais, e persiste métricas no CloudWatch com dimensões por versão de agente, tipo de tarefa e ferramenta.

Além do sampling, monitoramos sinais proxy que não requerem avaliação LLM: taxa de conversas que atingem o limite máximo de turnos (indica agente preso em loop), taxa de tool errors não recuperados, taxa de escalação para humano (se aplicável), e distribuição de latência por ferramenta (mudanças de latência podem indicar mudanças de comportamento de chamada).

## Arquitetura da Suíte de Avaliação Contínua

Fluxo completo desde o commit de uma nova versão do agente até os sinais de qualidade em produção, mostrando as três camadas de avaliação e o feedback loop de curadoria de datasets.

### 🔧 CI/CD Pipeline

- Git Repo Agent Config / Prompts (ci)
- CI/CD (CodePipeline) (ci)
- Quality Gate Lambda (compute)

### 📦 Dataset Management

- S3 Versioned Datasets (storage)
- DynamoDB Dataset Registry (data)
- Curator UI (Internal Tool) (frontend)

### 🧪 Offline Evaluation

- Step Functions Eval Orchestrator (compute)
- Bedrock AgentCore (Eval Mode) (ai)
- Mock Tool Layer Lambda (compute)
- Bedrock Evaluations LLM-as-Judge (ai)
- S3 Eval Results (storage)

### ⚔️ Adversarial Layer

- S3 Adversarial Dataset (storage)
- Adversarial Runner Lambda (compute)

### 🚀 Production

- Bedrock AgentCore (Production) (ai)
- Real Tools (APIs) (external)
- AgentCore Traces S3 / CloudWatch (storage)

### 📊 Online Monitoring

- Sampling Lambda Stratified 5-15% (compute)
- Step Functions Online Eval (compute)
- Bedrock Evaluations Online Judge (ai)
- CloudWatch Metrics + Alarms (data)
- EventBridge Anomaly Events (messaging)

### Fluxos

- git -> cicd: commit/PR
- cicd -> eval_sfn: trigger eval
- cicd -> adv_runner: trigger adversarial
- ds_s3 -> eval_sfn: load dataset
- ds_ddb -> eval_sfn: dataset version
- eval_sfn -> agentcore_eval: run cases
- agentcore_eval -> mock_tools: tool calls
- agentcore_eval -> judge: responses
- judge -> eval_results: scores
- eval_results -> gate: metrics
- adv_ds -> adv_runner: adversarial cases
- adv_runner -> agentcore_eval: adversarial run
- gate -> cicd: pass/block
- cicd -> agentcore_prod: deploy (if gate passes)
- agentcore_prod -> real_tools: tool calls
- agentcore_prod -> trace_store: traces
- trace_store -> sampler: stream
- sampler -> online_sfn: sampled traces
- online_sfn -> online_judge: eval request
- online_judge -> cw: metrics
- cw -> eb: anomaly alarm
- eb -> curator: alert / review queue
- curator -> ds_s3: new eval cases

## Dataset Management: Versionamento, Curadoria e o Problema do Dataset Drift

Um dos aspectos mais negligenciados em sistemas de avaliação de agentes é o gerenciamento do próprio dataset de avaliação. Times constroem um conjunto inicial de casos de teste, executam por meses, e nunca revisam — enquanto o agente evolui para lidar com casos de uso completamente novos que não estão representados. O dataset envelhece e perde poder discriminativo.

A proposta aqui é tratar o dataset de avaliação com a mesma disciplina que tratamos o código: versionamento explícito, changelog, e um processo de curadoria contínua.

**Estrutura de versionamento**: Cada versão do dataset é um artefato imutável no S3, identificado por um hash de conteúdo e um número de versão semântico (major.minor.patch). O DynamoDB mantém o registry com metadados: data de criação, autor, changelog, cobertura por categoria de tarefa, e a versão do agente contra a qual foi validado. O quality gate sempre executa contra a versão do dataset especificada no manifesto do agente — não contra "latest". Isso é deliberado: garante reprodutibilidade e evita que um dataset novo quebre um agente que estava funcionando bem.

**Processo de curadoria**: Novos casos de teste entram no dataset por três caminhos. O primeiro é curadoria manual — engenheiros ou especialistas de domínio escrevem casos baseados em requisitos. O segundo é mineração de produção — conversas reais que foram marcadas como problemáticas (via feedback do usuário, escalação, ou detecção automática) são revisadas e convertidas em casos de teste. Esse é o caminho mais valioso: são falhas reais, não hipotéticas. O terceiro é geração sintética — usando um LLM para gerar variações de casos existentes, especialmente para aumentar cobertura de edge cases e cenários adversariais.

**O problema do dataset drift**: À medida que o agente melhora, casos que antes eram difíceis se tornam triviais. Um dataset que não é atualizado perde poder discriminativo — o agente passa em tudo, mas isso não significa que está funcionando bem em casos novos. A solução é monitorar a distribuição de scores do dataset ao longo do tempo: se a maioria dos casos está com score próximo de 1.0, é hora de adicionar casos mais difíceis. Isso é análogo ao problema de benchmark saturation em ML — quando um modelo atinge performance humana em um benchmark, o benchmark precisa ser substituído, não o modelo declarado perfeito.

**Cobertura de tool-use**: Para agentes com múltiplas ferramentas, o dataset precisa garantir cobertura adequada de cada ferramenta e de combinações de ferramentas. Mantemos um mapa de cobertura que mostra, para cada ferramenta, quantos casos de teste a exercitam, em quais contextos, e com quais padrões de argumento. Ferramentas novas adicionadas ao agente devem ter cobertura mínima antes de o agente poder ser promovido — essa é uma regra de quality gate adicional.

## Alternativas de Design: Abordagens de Avaliação

### LLM-as-Judge exclusivo (sem casos de teste estruturados)

**Pros**
- Fácil de escalar — não requer curadoria manual de casos de teste
- Flexível para avaliar respostas abertas sem resposta de referência

**Cons**
- Não detecta regressões de tool-use específicas — o judge avalia o resultado final, não o processo
- Custo elevado para avaliar cada caso; inconsistência entre runs do mesmo judge
- Sem baseline determinística — difícil saber se uma mudança de score é real ou ruído do judge

**Verdict:** Útil como camada complementar, insuficiente como única abordagem

### Testes determinísticos apenas (mock tools + expected outputs exatos)

**Pros**
- Reprodutível e barato — sem chamadas LLM para avaliação
- Detecta regressões de tool-use com precisão alta

**Cons**
- Frágil para respostas de linguagem natural — qualquer variação legítima quebra o teste
- Não captura qualidade semântica da resposta final
- Alta manutenção — cada mudança de prompt pode invalidar centenas de expected outputs

**Verdict:** Excelente para tool-use assertions; inadequado para avaliação de resposta

### Abordagem híbrida (proposta neste RFC)

**Pros**
- Determinístico onde possível (tool-use), probabilístico onde necessário (resposta final)
- Camadas offline + online cobrem diferentes pontos de falha
- Dataset versionado permite rastrear regressões ao longo do tempo com reprodutibilidade

**Cons**
- Maior complexidade operacional — múltiplos sistemas para manter
- Custo de LLM-as-judge para avaliação online pode ser significativo em escala

**Verdict:** Abordagem recomendada — complexidade justificada pelo poder discriminativo

### Plataforma de avaliação de terceiros (Braintrust, LangSmith, etc.)

**Pros**
- Time-to-value mais rápido — UI pronta, integrações existentes
- Comunidade e templates de métricas

**Cons**
- Dados de avaliação (incluindo conversas de produção) saem do ambiente AWS — problema para dados sensíveis
- Integração com Bedrock AgentCore traces requer trabalho customizado de qualquer forma
- Vendor lock-in adicional; custo por volume pode ser proibitivo

**Verdict:** Válido para prototipagem; não recomendado para produção em contextos com dados sensíveis

## Decisão: Estratégia de Sampling para Avaliação Online

**Status:** proposed

**Contexto**

Avaliar 100% das conversas em produção com LLM-as-judge é proibitivamente caro e lento. Precisamos de uma estratégia de sampling que maximize o poder de detecção com custo controlado.

**Decisão**

Sampling estratificado com taxa base de 10%, aumentando para 50% quando métricas proxy (taxa de erro, latência anômala) excedem thresholds. Conversas com feedback negativo explícito do usuário são sempre avaliadas (100%). Distribuição garantida por tipo de tarefa e por ferramenta mais crítica.

**Consequências**
- Custo de avaliação online controlado — estimativa de 10-15% do custo de avaliação 100%
- Detecção de anomalias pode ter latência de minutos a horas dependendo do volume de tráfego
- Requer implementação de lógica de sampling estratificado — não trivial para garantir representatividade

## Plano de Rollout

1. **Fase 1 — Fundação (Semanas 1-3)** — Criar a estrutura de dataset no S3 e DynamoDB. Definir o schema de casos de teste. Construir o primeiro dataset com 50-100 casos manuais cobrindo os fluxos mais críticos do agente. Configurar o AgentCore em modo de avaliação com mock tools para os fluxos principais. Sem quality gate ainda — apenas coletar dados de baseline.

2. **Fase 2 — Avaliação Offline (Semanas 4-6)** — Implementar o Step Functions workflow de avaliação offline. Integrar Bedrock Evaluations como LLM-as-judge para respostas finais. Definir métricas de tool-use e implementar o cálculo determinístico. Executar contra as últimas 3 versões do agente para calibrar thresholds de quality gate. Integrar ao CI/CD como check não-bloqueante inicialmente.

3. **Fase 3 — Quality Gate Ativo (Semanas 7-8)** — Ativar o quality gate como bloqueante no CI/CD. Definir thresholds baseados nos dados de baseline coletados. Criar o dataset adversarial inicial com 20-30 casos de prompt injection e boundary testing. Treinar o time em como interpretar resultados e como adicionar novos casos ao dataset.

4. **Fase 4 — Monitoramento Online (Semanas 9-12)** — Implementar o pipeline de sampling e avaliação online. Configurar CloudWatch dashboards com métricas por versão e por ferramenta. Criar alarms para anomalias. Implementar o fluxo de mineração de produção: conversas problemáticas detectadas online são enfileiradas para revisão e potencial adição ao dataset offline.

5. **Fase 5 — Maturidade e Automação (Semanas 13-16)** — Implementar geração sintética de casos de teste para aumentar cobertura. Criar o mapa de cobertura de tool-use e adicionar regras de cobertura mínima ao quality gate. Revisar e refinar thresholds com 2+ meses de dados. Documentar o processo de curadoria e criar runbooks para o time.

> **Riscos Críticos e Mitigações:** **Risco 1 — Goodhart's Law no quality gate**: Quando um threshold se torna um alvo, ele deixa de ser uma boa medida. Times podem começar a escrever casos de teste que o agente já passa bem, em vez de casos que testam fraquezas reais. Mitigação: separar quem escreve os casos de teste de quem desenvolve o agente; incluir casos de teste de adversários externos periodicamente.

**Risco 2 — Judge inconsistency**: LLM-as-judge tem variância não-trivial entre runs. Um agente pode passar o quality gate em uma run e falhar em outra sem nenhuma mudança real. Mitigação: usar múltiplas runs (3-5) e agregar scores; definir thresholds com margem de segurança acima da variância observada do judge.

**Risco 3 — Mock tool drift**: Os mocks das ferramentas podem divergir do comportamento real das APIs ao longo do tempo, tornando os testes offline cada vez menos representativos. Mitigação: versionar os mocks junto com os schemas das ferramentas reais; incluir testes de contrato (contract tests) que verificam que os mocks ainda correspondem às APIs reais.

**Risco 4 — Custo de avaliação online em escala**: Em volumes altos, mesmo 10% de sampling com LLM-as-judge pode ser caro. Mitigação: usar modelos menores para o judge online (Claude Haiku vs. Sonnet), reservando modelos mais capazes para avaliação offline onde a precisão é mais crítica.

**Risco 5 — False confidence**: Uma suíte de avaliação que passa pode dar falsa confiança. O dataset nunca cobre todos os casos possíveis. Mitigação: comunicar explicitamente o que o dataset cobre e o que não cobre; manter humanos no loop para revisão de casos de alto risco.

## Métricas de Sucesso e Targets

- **Tool-call accuracy (offline):** ≥ 0.90 geral, ≥ 0.95 em casos críticos
- **Regressão máxima permitida (offline):** < 5 pontos percentuais vs. baseline da versão anterior
- **Cobertura de ferramentas no dataset:** 100% das ferramentas com ≥ 10 casos de teste cada
- **Latência do pipeline de avaliação offline:** < 15 minutos para dataset de até 200 casos (estimativa)
- **Cobertura de avaliação online:** ≥ 10% de todas as conversas, 100% das com feedback negativo
- **MTTD (Mean Time to Detect) regressão em produção:** < 4 horas em volume normal (estimativa)
- **Taxa de falsos positivos no quality gate:** < 5% — gates que bloqueiam deploys sem regressão real
- **Cadência de atualização do dataset:** Revisão mensal obrigatória; adição contínua via mineração de produção

> **Minha Perspectiva: O que Eu Faria Diferente e o que Não Abriria Mão:** Depois de trabalhar com sistemas de alta criticidade em finanças, tenho uma convicção forte: **a qualidade de um sistema de avaliação é determinada pela qualidade do seu dataset, não pela sofisticação da sua infraestrutura**. Você pode ter o pipeline mais elegante do mundo rodando no Bedrock AgentCore com Step Functions e LLM-as-judge, mas se o dataset tiver 30 casos todos do mesmo tipo, você está medindo nada.

O que eu não abriria mão: o processo de mineração de produção. Casos de teste derivados de falhas reais são ordens de magnitude mais valiosos do que casos sintéticos. Em todo projeto que trabalhei com avaliação de sistemas, os bugs mais importantes foram encontrados por casos que vieram de incidentes reais, não de brainstorming preventivo. Eu investiria desproporcionalmente no fluxo que vai de "conversa problemática detectada em produção" → "revisão humana" → "caso de teste no dataset offline".

O que eu faria diferente do que está descrito aqui: começaria menor. Esse documento descreve um sistema completo e maduro. Na prática, eu começaria com um script Python simples que roda 50 casos de teste contra o agente antes de cada deploy, sem Step Functions, sem LLM-as-judge, apenas tool-use assertions determinísticas. Isso já captura 70% do valor com 10% da complexidade. A sofisticação adicional se justifica à medida que você tem evidência de que precisa dela.

Sobre o Bedrock AgentCore especificamente: a capacidade de rodar o agente em modo de avaliação com ferramentas mockadas é genuinamente útil — resolve um problema real de isolamento de ambiente que times costumam resolver com gambiarras. O gerenciamento de datasets via AgentCore é uma adição recente que ainda está amadurecendo; eu manteria uma camada de abstração fina sobre ele para não ficar refém de mudanças de API.

A lição mais importante que aprendi sobre avaliação de sistemas de IA: **trate a avaliação como um produto, não como infraestrutura**. Ela precisa de ownership claro, de alguém que acorde de manhã pensando em como melhorar o dataset e os thresholds. Sem isso, o sistema mais sofisticado do mundo vira um check de CI que ninguém lê.

## Veredicto

A suíte de avaliação contínua descrita neste RFC é necessária para qualquer agente LLM que opera em produção com consequências reais. A arquitetura de três camadas — avaliação offline com quality gate, testes adversariais sistemáticos, e monitoramento online com sampling estratificado — cobre os vetores de degradação mais importantes: mudanças de modelo, drift de tool schemas, e regressões introduzidas por atualizações de prompt.

O Bedrock AgentCore fornece as primitivas necessárias — execução em modo de avaliação, rastreamento de tool-use, e integração com Bedrock Evaluations para LLM-as-judge — sem exigir que você construa essa infraestrutura do zero. O valor real, porém, não está na infraestrutura: está no processo de curadoria de datasets e na disciplina de tratar avaliação como um produto com ownership claro.

Minha recomendação: implemente em fases, começando pelo que gera mais valor com menos complexidade (dataset versionado + quality gate de tool-use determinístico), e adicione sofisticação apenas quando você tiver evidência de que o sistema simples está deixando regressões passarem. O risco de over-engineering um sistema de avaliação é real — um sistema complexo que ninguém entende ou mantém é pior do que um script simples que o time realmente usa.

## Referências

- [Amazon Bedrock AgentCore — Official Product Page](https://aws.amazon.com/bedrock/agentcore/)
- [AWS Machine Learning Blog — AgentCore and Agent Evaluation](https://aws.amazon.com/blogs/machine-learning/)
- [Amazon Bedrock Evaluations — Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html)
- [AWS Step Functions — Developer Guide](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
- [Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023)](https://arxiv.org/abs/2306.05685)
- [AgentBench: Evaluating LLMs as Agents (Liu et al., 2023)](https://arxiv.org/abs/2308.03688)
- [Tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains](https://arxiv.org/abs/2406.12045)
- [Amazon Bedrock AgentCore — Getting Started Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore.html)

## Fontes do caso

- [AWS AI Blog — AgentCore dataset management](https://aws.amazon.com/blogs/machine-learning/)
- [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)