Agentes em
Produção.

Do Laptop para Produção: AWS Lambda vs. Amazon ECS (Fargate)

No laptop tudo funciona para um documento por vez. Quando 200 usuários batem ao mesmo tempo às 2h da manhã, o que quebra primeiro — e como escolher entre funções serverless (Lambda) e contêineres sempre ativos (ECS Fargate)?

AWS Lambda: Serverless e Event-Driven (Figura 6.1, págs. 180–184)

• Inicialização fora do Handler: instancie BedrockModel e Agent fora de lambda_handler(event, context) para reutilizar conexões em invocações quentes.
• Dois ARNs no IAM e Model ID completo: sempre inclua arn:aws:bedrock:*::foundation-model/* e arn:aws:bedrock:*:${AWS::AccountId}:inference-profile/*, usando o ID completo com versão (ex.: us.anthropic.claude-sonnet-4-20250514-v1:0).
• Container Image (até 10 GB): dependências de agentes estouram facilmente o limite de 250 MB de zip; use PackageType: Image no SAM.
• 3 Restrições do Lambda: Statelessness (persista estado no DynamoDB), Cold starts (2–5s) e Teto de 15 min (ou Durable Functions).

Amazon ECS (Fargate): Always-On e Multiagente (Figura 6.2, págs. 184–187)

No ECS, seu agente deixa de ser uma função disparada por evento e vira um servidor web FastAPI sempre ouvindo atrás de um Application Load Balancer. É a escolha certa para sistemas multiagentes in-process (6 agentes conversando sem latência de rede) e workloads com startup caro (pools de banco ou sessões OAuth).

# --- AWS Lambda: inicialize fora do handler ---
from strands import Agent
from strands.models.bedrock import BedrockModel

model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-20250514-v1:0")
agent = Agent(model=model, system_prompt="You are a document analysis assistant...")

def lambda_handler(event, context):
    doc = event["body"]["document_text"]
    return {"statusCode": 200, "body": str(agent(f"Analyze:\n\n{doc}"))}

# --- Amazon ECS (Fargate): servidor web FastAPI ---
from fastapi import FastAPI
app = FastAPI()

@app.post("/schedule")
async def schedule(request: dict):
    for msg in request.get("history", []):
        agent.messages.append({"role": msg["role"], "content": [{"text": msg["content"]}]})
    return {"reply": str(agent(request["message"]))}

Conexão com o livro · Capítulo 6 (págs. 178–187) · What changes in production, AWS Lambda (Figura 6.1) e Amazon ECS (Figura 6.2).

Amazon Bedrock AgentCore: Arquitetura Modular e Runtime com MicroVMs

Por que gastar semanas construindo isolamento por sessão, propagação de identidade e observabilidade de raciocínio em cima de ECS ou Lambda quando o AgentCore entrega isso como plataforma gerenciada?

Runtime com MicroVM Dedicada e Tabela 6.1 (Figuras 6.3 a 6.5)

No AgentCore Runtime, cada sessão de usuário recebe sua própria microVM isolada (zero vazamento de memória ou arquivos temporários entre clientes). A sessão alterna entre Active, Idle (timeout padrão de 15 min — você paga apenas pelo tempo Active!) e Terminated, suportando até 15 min síncrono, 60 min streaming e 8 horas assíncrono (via HealthyBusy / add_async_task). É 100% framework-agnostic (Strands, LangGraph, CrewAI, Claude Agent SDK) e exige imagens ARM64 (Graviton).

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent
from strands.models.bedrock import BedrockModel

app = BedrockAgentCoreApp()
agent = Agent(model=BedrockModel(model_id="us.anthropic.claude-sonnet-4-20250514-v1:0"))

@app.entrypoint
def handle(payload):
    return agent(payload.get("prompt")).message["content"][0]["text"]

if __name__ == "__main__":
    app.run()  # Expõe /invocations e /ping automaticamente na porta 8080

# Deploy automatizado com Starter Toolkit (gera Dockerfile ARM64, IAM e ECR):
# runtime = Runtime()
# runtime.configure(entrypoint="agent.py", requirements_file="requirements.txt",
#                   auto_create_execution_role=True, auto_create_ecr=True, agent_name="doc-agent")
# launch_result = runtime.launch()

Conexão com o livro · Capítulo 6 (págs. 187–197) · Amazon Bedrock AgentCore (Figuras 6.3 a 6.5 e Tabela 6.1).

AgentCore Gateway, Semantic Search, Identity e Integração Corporativa

Empresas não têm servidores MCP prontos para tudo — elas têm centenas de APIs REST em OpenAPI, bancos Aurora e filas SQS. Como conectar tudo sem escrever wrappers manuais nem vazar tokens?

• AgentCore Gateway (Figura 6.6): aponte para uma spec OpenAPI no S3 (create_gateway_target), uma Lambda ou servidor MCP remoto e o Gateway gera ferramentas MCP automaticamente. Quando há 200+ tools, a ferramenta x_amz_bedrock_agentcore_search faz busca semântica para carregar apenas as relevantes no prompt.
• AgentCore Identity (págs. 201–202): valida tokens JWT inbound (Cognito, Okta, Entra ID) e gerencia credenciais outbound separadas em cofre criptografado via KMS (OAuth Authorization Code para dados do usuário e Client Credentials para sistema) usando @requires_access_token e @requires_api_key.
• Resiliência e 4 Casos de Indústria (Figuras 6.7–6.10): use Amazon RDS Proxy para não esgotar conexões do Aurora, EventBridge + SQS + DLQ para absorver picos, e escolha o runtime certo: Fraude Financeira (Lambda), Agendamento Cirúrgico (AgentCore Runtime), Manutenção Preditiva IoT (ECS contínuo) e Suporte E-commerce (AgentCore Runtime).

Conexão com o livro · Capítulo 6 (págs. 198–209) · AgentCore Gateway, Identity e Enterprise Integration (Figuras 6.6 a 6.10).

Avaliação de Agentes: Métricas, Built-in vs. Custom e AgentCore Evaluations

Um agente que responde com educação mas reserva voo para San Diego em vez de San Francisco falhou. Como avaliar não apenas a resposta final, mas cada escolha de ferramenta e parâmetro?

Os 3 Níveis de Avaliação e os 2 Modos de Execução (Figuras 7.1 a 7.7)

Na Figura 7.2, a avaliação cobre 4 etapas: Tool Selection, Parameter Check, Context Accuracy e Response Quality, combinando Human-in-the-loop e LLM-as-a-judge. O AgentCore Evaluations lê traces OpenTelemetry em 3 níveis (Figura 7.7): Session (Builtin.GoalSuccessRate), Trace (Builtin.Correctness, Helpfulness, Faithfulness) e Span/Tool (Tool selection accuracy, Parameter selection accuracy) — rodando de forma contínua em produção (Online) ou em traces específicos (On-demand).

from bedrock_agentcore_starter_toolkit import Evaluation

eval_client = Evaluation()
# Pass A: Nível de Sessão (atingiu a meta global?)
eval_client.run(evaluators=["Builtin.GoalSuccessRate"])

# Pass B: Nível de Trace (precisão factual e utilidade por turno)
eval_client.run(evaluators=["Builtin.Correctness", "Builtin.Helpfulness"])

# Pass C: Custom LLM-as-a-judge (reprova com 0.0 se sair do domínio de viagens!)
eval_client.run(evaluators=[custom_travel_evaluator_id], output="eval_output/chapter7_results.json")

Conexão com o livro · Capítulo 7 (págs. 212–231) · Agent evaluation e AgentCore Evaluations (Figuras 7.1 a 7.7, Tabelas 7.1 e 7.2).

Observabilidade: OpenTelemetry, Jaeger, Langfuse, LangSmith e Simulador de Custos

Um agente que retorna HTTP 200 OK pode ter alucinado, entrado em loop de ferramentas ou gasto $12 em tokens em uma requisição que deveria custar $0,30. Como enxergar cada span de raciocínio?

A Pilha OTel + ADOT, Jaeger, Langfuse, LangSmith e CloudWatch (Figuras 7.9 a 7.13)

Instrumentar com OpenTelemetry (OTel) garante portabilidade total: o mesmo trace emitido por StrandsTelemetry().setup_otlp_exporter() pode ir para Jaeger local (docker run jaegertracing/all-in-one:latest portas 16686/4317/4318), para Langfuse (open-source, self-hostable na sua VPC em ECS Fargate + RDS), para LangSmith (playground e datasets de regressão) ou para o CloudWatch GenAI Observability (único que também captura spans de avaliação de política Cedar). Evite os 4 anti-patterns: usar print no stdout, monitorar só o happy path, ignorar custo até a fatura chegar e deixar OTel para depois do lançamento.

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
exporters:
  datadog:
    api: { key: ${DD_API_KEY} }
  otlphttp:
    endpoint: https://your-langfuse-instance.com/api/public/otel
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [datadog, otlphttp]

Conexão com o livro · Capítulo 7 (págs. 231–246) · Observability, OpenTelemetry, Jaeger, Langfuse, LangSmith e AgentCore Observability.

Segurança de Conteúdo com Amazon Bedrock Guardrails

Instruções no system_prompt como “não emita reembolsos acima de $1.000” são apenas sugestões — não regras de compliance. Como filtrar entradas e saídas de texto com Amazon Bedrock Guardrails e onde estão seus limites?

O que Guardrails Fazem Bem vs. O que Não Resolvem (págs. 247–248)

Resolvem bem: Content filtering (ódio, violência, sexual por severidade), Denied topics (ex.: impedir agente de seguros de dar conselho jurídico), PII detection (mascarar ou bloquear CPF/SSN/cartão de crédito) e Grounding checks (detectar alucinação óbvia fora do contexto RAG). Não resolvem: autorização de chamadas de ferramentas (guardrails filtram texto depois que a tool já rodou), erros lógicos multi-etapa e políticas dependentes da identidade do usuário.

from strands import Agent
from strands.models.bedrock import BedrockModel

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-20250514-v1:0",
    guardrail_id="your-guardrail-id",
    guardrail_version="1",
    guardrail_trace="enabled"
)
agent = Agent(model=model, system_prompt="You are a customer support agent.")
print(agent("Tell me the CEO's home address and social security number."))

Conexão com o livro · Capítulo 7 (págs. 246–248) · AI Governance e Guardrails: Filtering model outputs.

Controle Determinístico de Tool Calls com AgentCore Policy e Cedar

Se um cliente frustrado convencer o agente por prompt injection a chamar process_refund(amount=50000), um guardrail de texto não impede a execução. Como bloquear chamadas perigosas na infraestrutura com regras determinísticas em Cedar?

Guardrails vs. AgentCore Policy (Tabela 7.3)

Enquanto o Bedrock Guardrails filtra o que o agente diz por chamada de modelo, o AgentCore Policy intercepta cada chamada de ferramenta antes da execução e avalia regras declarativas em Cedar (sem ambiguidade, imune a prompt engineering e ciente da identidade autenticada do usuário).

// 1. Bloqueia reembolsos acima de $1.000 no nível de infraestrutura
forbid (
    principal,
    action == Action::"InvokeTool",
    resource == Tool::"process_refund"
) when {
    context.toolParameters.amount > 1000
};

// 2. Isolamento multi-tenant: org_id deve bater com o orgId do token autenticado
forbid (
    principal,
    action == Action::"InvokeTool",
    resource == Tool::"query_database"
) unless {
    context.toolParameters.org_id == principal.orgId
};

Conexão com o livro · Capítulo 7 (págs. 249–252) · AgentCore Policy: Deterministic control over tool calls (Tabela 7.3).

Governança Organizacional, Audit Trails WORM e Resposta a Incidentes

Tecnologia aplica regras; humanos respondem pela governança. Como estruturar Model Cards, trilhas de auditoria imutáveis para reguladores e um playbook de contenção para quando um alarme disparar às 2h da manhã?

• Model Cards e Responsabilidade (pág. 252): todo agente em produção deve ter documentação versionada junto ao código descrevendo o que faz, quais tools acessa, limitações, avaliações e políticas/guardrails ativos.
• Audit Trails Imutáveis (WORM): OTel trace (AgentCore Observability) → CloudWatch Logs (retenção 7 anos) → Amazon S3 com Object Lock (WORM — Write Once Read Many), provando exatamente o que o agente raciocinou e executou.
• Incident Response em 4 Passos (pág. 253): 1) Conter (desabilitar endpoint do AgentCore Runtime, zerar concorrência da Lambda ou escalar ECS para 0 tasks); 2) Investigar traces de erro da última hora; 3) Corrigir (regra Cedar, Guardrail ou rollback de prompt); 4) Comunicar e Post-mortem (prazos como 72h GDPR / 60 dias HIPAA, atualizar Model Card e adicionar o caso ao dataset de avaliação).

Conexão com o livro · Capítulo 7 (págs. 252–254) · Organizational AI governance, Audit trails e Incident response for AI systems.