Agentes de IA
na AWS.

De LLMs Isolados e RAG Passivo a Agentes Ativos

Modelos de Linguagem Grandes (LLMs) padrão sofrem com duas travas severas: data de corte do conhecimento (knowledge cutoff) e incapacidade de acessar dados privados ou agir em tempo real. Como o RAG resolve a informação — e por que isso ainda não basta para entregar um sistema que realmente trabalha por você?

O Pipeline Completo de RAG em 7 Etapas (Figuras 1.1 e 1.2)

Sem retreinar ou fazer fine-tuning no modelo inteiro, a técnica de Retrieval Augmented Generation (RAG) combina o LLM com um sistema de recuperação de informação em três verbos: Retrieve (buscar na base), Augment (injetar o contexto no prompt) e Generate (gerar a resposta fundamentada). Na prática de engenharia, a Figura 1.2 do livro detalha um pipeline completo em sete passos:

RAG Tradicional vs. Agentic RAG: De Fluxo Fixo a Decisão Dinâmica

Um sistema de RAG tradicional segue um trilho rígido de uma única passada: User Query → Retrieve → Augment → Generate. Se o usuário perguntar “Qual é a política de férias da empresa?”, funciona perfeitamente. Mas e se o usuário pedir “Verifique a política de férias, consulte meu saldo no sistema de RH e agende minha folga para sexta-feira”? O RAG passivo trava porque não sabe refinar buscas, consultar APIs externas em tempo real ou executar ações.

No Agentic RAG, a busca vetorial deixa de ser o pipeline inteiro e passa a ser apenas uma ferramenta (tool) à disposição do agente: Question → Agent Reasons → (talvez chame RAG tool) → (talvez chame APIs/outras tools) → Answer or Act. O agente decide se precisa consultar a base RAG, quantas vezes refinar a consulta e com quais APIs combinar o resultado.

# Demonstração conceitual da diferença entre fluxo fixo (RAG Tradicional)
# e decisão dinâmica com múltiplas ferramentas (Agentic RAG)
python3 - <<'PY'
def tool_rag_politicas(query: str) -> str:
    base = {
        "clima_ny": "Média histórica de verão em NY: 28°C de dia, 19°C à noite.",
        "ferias": "Política de férias: colaboradores CLT têm direito a 30 dias após 12 meses."
    }
    return base.get("clima_ny" if "ny" in query.lower() else "ferias", "Documento não encontrado.")

def tool_api_clima_tempo_real(cidade: str) -> str:
    return f"Previsão em tempo real para {cidade}: 31°C hoje, frente fria prevista às 21h (17°C)."

def rag_tradicional(pergunta: str) -> str:
    contexto = tool_rag_politicas(pergunta)
    return f"[RAG Fixo] Baseado apenas no histórico: {contexto}"

def agentic_rag(pergunta: str, perfil_usuario: dict) -> str:
    passos = []
    if "levar" in pergunta.lower() or "mala" in pergunta.lower():
        hist = tool_rag_politicas("clima_ny")
        live = tool_api_clima_tempo_real("Nova York")
        passos.extend([hist, live])
    jaqueta = "Traga jaqueta leve para a noite (17°C)" if perfil_usuario.get("odeia_frio") else "Roupas leves bastam"
    return f"[Agentic RAG] Fontes cruzadas ({len(passos)} tools) -> Recomendação: {jaqueta}. Dados: {passos}"

print(rag_tradicional("O que devo levar na mala para Nova York no verão?"))
print(agentic_rag("O que devo levar na mala para Nova York no verão?", {"odeia_frio": True}))
PY

Conexão com o livro · Capítulo 1 (págs. 1–5) · What is RAG and how does it work?, pipeline de 7 etapas (Figura 1.2) e Agentic RAG vs. Traditional RAG.

Anatomia do Agente: Planning, Acting, Reasoning e os 4 Pilares

O que realmente transforma um script que chama um LLM em um agente autônomo? Não é um prompt mais longo — é o ciclo iterativo em que o sistema planeja passos, aciona ferramentas no mundo real, observa o resultado e ajusta a rota até concluir o objetivo.

As 3 Capacidades Centrais e os 4 Componentes Arquiteturais (Figuras 1.3 e 1.4)

No Capítulo 1, Bunny Kaushik e Mona M definem agentes de IA como sistemas de software autônomos que executam tarefas em seu nome, operando por meio de três capacidades contínuas:

• 1. Planning (Planejamento): quebrar um objetivo de alto nível (ex.: “agendar uma reunião com o time”) em subtarefas executáveis (checar calendários, enviar convites, reservar sala, acompanhar recusas e atualizar horários).
• 2. Acting (Ação): utilizar ferramentas externas e bases de conhecimento para executar cada subtarefa no ambiente real.
• 3. Reasoning (Raciocínio iterativo): observar o retorno de cada ação (inclusive erros ou mudanças de contexto) e atualizar o plano até que a meta seja atingida.

# Exemplo didático do caso "Travel Planner" da Figura 1.3:
# O agente combina memória (preferências), RAG (média histórica) e API (previsão real)
python3 - <<'PY'
memoria_usuario = {"preferencia_mala": "mala leve", "sensivel_frio": True}

def executar_plano_viagem(destino: str, estacao: str):
    plano = [
        ("RAG_Historico", f"Temperatura média de {estacao} em {destino}: 27°C."),
        ("API_Clima", f"Previsão para {destino} esta semana: máximas 30°C, noites 16°C."),
        ("Memoria", f"Preferências: {memoria_usuario}")
    ]
    observacoes = []
    for etapa, resultado in plano:
        print(f"[Acting] Executando {etapa} -> {resultado}")
        observacoes.append(resultado)
    print("[Reasoning] Cruzando dados: calor de dia, frio à noite + usuário sensível ao frio.")
    print("[Resultado Final] Leve roupas leves na mala compacta, mas inclua uma jaqueta leve para a noite.")

executar_plano_viagem("Nova York", "verão")
PY

Conexão com o livro · Capítulo 1 (págs. 5–7) · What are agents?, Agent capabilities (Planning, Acting, Reasoning) e Figura 1.4.

O AWS Agentic Stack: Amazon Q, Amazon Bedrock, AgentCore e SageMaker AI

Na AWS, construir um agente não significa reinventar servidores de inferência nem ficar preso a uma única ferramenta pronta. Como escolher entre soluções prontas de negócio, plataformas gerenciadas sem servidor e infraestrutura customizada de Machine Learning?

As 3 Camadas do AWS Agentic Stack (Figura 1.5 e Tabela 1.1)

O livro organiza o ecossistema agêntico da AWS em três níveis de esforço e controle. Nesta trilha de engenharia por código, nosso foco está nas camadas 2 e 3:

Como um Agente Roda na AWS Ponta a Ponta (Figura 1.6)

1. Desenvolvimento (IDE): o engenheiro escreve a lógica no VS Code, Amazon SageMaker Studio ou em uma IDE agêntica como o Kiro.
2. Orquestração (Framework): a aplicação usa o AWS Strands Agents SDK ou LangChain/LangGraph para definir prompts, fluxo e ferramentas.
3. Raciocínio (Model Provider): a aplicação faz chamadas de API (InvokeModel / Converse) ao Amazon Bedrock ou a um endpoint do Amazon SageMaker AI.
4. Ação e Contexto: o agente se comunica com ferramentas, APIs, bancos de memória e outros agentes via HTTP(S) ou STDIO.
5. Entrega: a resposta final chega à aplicação cliente ou interface do usuário final.

# Liste os Foundation Models disponíveis na sua conta AWS Bedrock (ex.: us-east-1)
aws bedrock list-foundation-models --region us-east-1 \
  --query "modelSummaries[?contains(modelId, 'claude') || contains(modelId, 'nova')].[modelId, modelName]" \
  --output table

# Teste rápido em Python com boto3 para validar credenciais e região ativa
python3 - <<'PY'
import boto3
sts = boto3.client("sts")
print("Conta/Identidade AWS:", sts.get_caller_identity()["Arn"])
PY

Conexão com o livro · Capítulo 1 (págs. 7–11) · Exploring the AWS Agentic Stack, Figura 1.5, Tabela 1.1 e Building AI agents on AWS (Figura 1.6).

A Escada Evolutiva: De LLMs Simples a Sistemas Multiagentes

Inteligência agêntica não nasce pronta em um único salto. Como evoluir sua arquitetura em estágios progressivos — e por que Avaliação, Segurança, Guardrails e Observabilidade precisam crescer na mesma proporção?

Os 6 Degraus de Complexidade e Autonomia (Figuras 1.7, 1.8 e 1.9)

Na Seção Progressing from LLMs to multi-agent systems, o livro traça a linha evolutiva completa que guia o restante do curso:

# Avalie qual estágio da Figura 1.7 é suficiente para evitar "over-engineering"
python3 - <<'PY'
def recomendar_estagio(precisa_dados_privados: bool, precisa_agir_apis: bool,
                       fluxo_multi_etapas: bool, dominios_distintos: int) -> str:
    if not precisa_dados_privados and not precisa_agir_apis:
        return "Estágio 1: LLM Direto (não complique com RAG ou Agentes)"
    if precisa_dados_privados and not precisa_agir_apis and not fluxo_multi_etapas:
        return "Estágio 2: LLM + RAG Tradicional"
    if not fluxo_multi_etapas:
        return "Estágio 3: Augmented LLM (Retrieval + Tools + Memory)"
    if dominios_distintos <= 1:
        return "Estágio 4/5: Agentic Workflow ou Autonomous Agent único"
    return "Estágio 6: Multi-Agent Collaboration (especialistas coordenados)"

print(recomendar_estagio(True, False, False, 1))
print(recomendar_estagio(True, True, True, 1))
print(recomendar_estagio(True, True, True, 3))
PY

Conexão com o livro · Capítulo 1 (págs. 12–15) · Progressing from LLMs to multi-agent systems (Figuras 1.7, 1.8 e 1.9).

Protocolos de Interoperabilidade (MCP vs. A2A) e Simulador de Viabilidade

À medida que sistemas agênticos crescem, conectar cada agente a dezenas de APIs e a outros agentes de fornecedores diferentes vira um pesadelo de integrações sob medida. Como os padrões abertos MCP e A2A resolvem camadas diferentes desse problema?

Model Context Protocol (MCP): Agente ↔ Ferramentas e Dados (Figura 1.10)

Desenvolvido pela Anthropic como protocolo aberto, o Model Context Protocol (MCP) padroniza a conexão entre modelos/agentes e fontes de dados ou ferramentas externas — no modelo write-once, run-anywhere. Sua arquitetura cliente-servidor divide-se em 4 peças:

• Host: a aplicação de IA ou IDE (ex.: Claude Desktop, VS Code, Kiro ou seu agente) que precisa acessar dados externos.
• MCP Client: componente de protocolo dentro do host que mantém conexão 1:1 com um servidor MCP.
• MCP Server: programa leve que expõe ferramentas, recursos e prompts de forma padronizada (na AWS, pode rodar em EKS/Lambda ou usar o Amazon Bedrock AgentCore MCP Server).
• Data Sources: bancos de dados locais, sistemas de arquivos ou APIs Web remotas acessadas pelo servidor MCP.

Agent-to-Agent Protocol (A2A): Agente ↔ Agente (Figuras 1.11 e 1.12)

Desenvolvido originalmente pelo Google para descoberta e colaboração entre agentes independentes (construídos em frameworks diferentes como Strands, LangGraph ou CrewAI), o A2A permite que um agente orquestrador delegue tarefas a agentes remotos sem precisar conhecer o código interno deles. Cada agente remoto publica suas habilidades e protocolos em um arquivo JSON chamado Agent Card (em /.well-known/agent-card.json). Na AWS, o protocolo A2A é suportado nativamente no Amazon Bedrock AgentCore Runtime.

{
  "name": "Travel Planner Agent",
  "description": "Orquestra roteiros de viagem combinando clima, voos e hotéis.",
  "url": "https://agents.garlucas.com.br/travel/",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "plan_trip",
      "name": "Planejar Roteiro",
      "description": "Coordena agentes especialistas via A2A para montar o itinerário completo."
    }
  ]
}

Conexão com o livro · Capítulo 1 (págs. 16–20) · Understanding agent protocols, MCP (Figura 1.10), A2A (Figuras 1.11 e 1.12) e MCP vs. A2A (Figura 1.13).

Por Dentro do AWS Strands Agents SDK e do Agentic Loop

Em vez de escrever máquinas de estado gigantescas com dezenas de if/else para rotear ferramentas, o AWS Strands Agents SDK adota uma abordagem model-driven: você define o modelo, as ferramentas e o prompt — e o framework gerencia o loop agêntico.

Os 3 Componentes Centrais e os 11 Passos do Agentic Loop (Figura 1.14)

O AWS Strands Agents SDK é um SDK open-source agnóstico a provedores de LLM (suporta Amazon Bedrock, Anthropic direto e outros modelos) construído sobre três peças centrais: model, tools e prompt. Quando você envia uma instrução ao agente (ex.: “Write a short story about a robot who wants to be a painter”), a Figura 1.14 mostra o fluxo exato de 11 etapas sob o capô:

# Visualização didática da lógica interna do Agentic Loop descrito na Figura 1.14
python3 - <<'PY'
def simular_agentic_loop(prompt_usuario: str, precisa_imagem: bool = False):
    print(f"1. [Invoke Agent] Prompt recebido: '{prompt_usuario}'")
    iteracao = 1
    contexto = [prompt_usuario]
    while True:
        print(f"2-5. [Invoke Model - Ciclo {iteracao}] Raciocinando sobre {len(contexto)} bloco(s) de contexto...")
        if iteracao == 1 and precisa_imagem:
            print("6. [Tool Selection] Modelo solicitou: ImageGenerationAPI")
            resultado_tool = "imagem_robo_pintor_v1.png"
            print(f"7-8. [Execute Tool -> Return Result] Retorno: {resultado_tool}")
            contexto.append(f"Arte gerada: {resultado_tool}")
            iteracao += 1
            continue
        print("9-11. [Return Final Response] Nenhuma nova tool necessária. Entregando resultado final.")
        return f"História concluída com sucesso! Contexto final: {contexto}"

print(simular_agentic_loop("Escreva uma história sobre um robô pintor e gere uma imagem.", precisa_imagem=True))
PY

Conexão com o livro · Capítulo 1 (págs. 20–23) · Introducing AWS Strands SDK e Figura 1.14.

Configurando o Ambiente: Amazon SageMaker Studio, IAM e IDE Local

Antes de rodar o primeiro agente, você precisa alinhar três peças essenciais: Python 3.10+, acesso habilitado aos modelos no Amazon Bedrock e permissões IAM corretas — escolhendo entre o Amazon SageMaker Studio ou sua IDE local.

Pré-requisitos de Conta, Modelos e Permissões IAM

De acordo com a página 23 do Capítulo 1, sua conta AWS (seja na execution role do SageMaker Studio ou no usuário/role usado localmente via aws configure) precisa de acesso aos modelos no console do Bedrock (Bedrock → Model access, habilitando modelos como Nova Lite, Nova Pro ou Claude) e, no mínimo, das seguintes ações IAM:

• bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream (chamadas síncronas e em streaming aos Foundation Models);
• sagemaker:InvokeEndpoint (para modelos hospedados em endpoints do Amazon SageMaker);
• s3:GetObject e s3:PutObject (leitura e gravação de dados e artefatos);
• bedrock-agentcore:* (necessário para os deploys gerenciados no AgentCore na Etapa 4).

Passo a Passo no Amazon SageMaker Studio (Figuras 1.15 e 1.16)

1. No console do Amazon SageMaker AI, acesse Domains no menu lateral e abra seu domínio.
2. Em Applications and IDEs, selecione Studio; na aba User profiles, localize seu perfil e clique em Launch → Studio.
3. Inicie um espaço JupyterLab com instância ml.t3.medium e abra o terminal do JupyterLab.
4. Clone o repositório oficial do livro e instale o Strands SDK conforme os comandos abaixo, lembrando de reiniciar o kernel após a instalação.

# 1. No terminal do JupyterLab (SageMaker Studio) ou no terminal local:
git clone https://github.com/PacktPublishing/Agents-on-AWS
cd Agents-on-AWS

# 2. Crie um ambiente virtual local (se estiver no VS Code / Kiro) e instale o SDK:
python3 -m venv .venv
source .venv/bin/activate
pip install strands-agents -q

# Ou, dentro de uma célula do notebook no SageMaker Studio:
# !pip install strands-agents -q
# (Em seguida, reinicie o kernel antes de importar strands)

Conexão com o livro · Capítulo 1 (págs. 23–25) · Pré-requisitos IAM, Tabela 1.2 e Setting up your environment in Amazon SageMaker Studio (Figuras 1.15 e 1.16).

Seu Primeiro Agente “Hello World” com Strands SDK e Amazon Bedrock

Com o ambiente configurado, quantas linhas de Python são necessárias para colocar um agente funcional conectado ao Amazon Bedrock? Apenas três — e a partir delas você já pode personalizar o modelo fundacional e o comportamento via system_prompt.

Do Código Mínimo do Livro à Especificação Explícita de Modelo

Na página 26 do livro, os autores apresentam o exemplo mínimo com a classe Agent do pacote strands. Por padrão, quando nenhum modelo é passado, o Strands utiliza o provedor Amazon Bedrock com um modelo padrão (que pode variar conforme a região e disponibilidade na sua conta). Por isso, para garantir reprodutibilidade em produção e evitar erros de modelo não habilitado, é boa prática declarar explicitamente o ID do modelo (ou usar um system_prompt direcionado).

# Exemplo 1: Código mínimo do Capítulo 1 (pág. 26)
from strands import Agent

# Define o agente com system prompt padrão
agent = Agent()

# Interage com o agente
response = agent("Explain Amazon Bedrock Agents")
print(response)

# ------------------------------------------------------------------
# Exemplo 2: Especificando explicitamente o modelo e o papel do agente
# (Recomendado para garantir disponibilidade na sua região AWS)
from strands import Agent

agente_arquiteto = Agent(
    model="us.anthropic.claude-sonnet-4-20250514-v1:0",
    system_prompt=(
        "Você é um arquiteto especialista em AWS. "
        "Responda em português brasileiro de forma objetiva e prática."
    )
)

resposta = agente_arquiteto("Explique a diferença entre Amazon Bedrock e SageMaker AI para agentes.")
print(resposta.message["content"][0]["text"])

Conexão com o livro · Capítulo 1 (pág. 26) · Creating a simple agent com AWS Strands SDK.