O problema de infraestrutura por trás de um agente
Colocar um agente de IA em produção exige muito mais do que escolher um bom modelo de linguagem. É preciso hospedar o agente com isolamento de sessão, manter memória de conversa entre interações, autenticar o agente em sistemas internos, aplicar guardrails de segurança e monitorar cada passo da execução. Historicamente, cada equipe precisava montar essa camada de infraestrutura na mão, geralmente combinando Lambda, DynamoDB, Cognito e CloudWatch de forma manual e repetindo esse trabalho a cada novo agente.
O Amazon Bedrock AgentCore centraliza essa infraestrutura em um conjunto de serviços gerenciados, permitindo focar no comportamento do agente em vez de reconstruir a plataforma que sustenta ele. Desde seu lançamento, o SDK do AgentCore já foi baixado mais de 1 milhão de vezes por clientes de diversos setores, segundo o anúncio oficial de disponibilidade geral da AWS.
O que compõe o AgentCore
AgentCore Runtime
O Runtime é o ambiente de execução serverless do agente. Hospeda o código com isolamento completo de sessão, janelas de execução de até 8 horas e escala automática conforme o volume de conversas. Também suporta o protocolo A2A, sigla para agent-to-agent, permitindo que agentes diferentes troquem mensagens diretamente entre si.
AgentCore Gateway
O Gateway funciona como ponto único de acesso a ferramentas externas. Conecta o agente a servidores MCP, APIs internas e funções Lambda, transformando cada um desses recursos em uma tool que o agente pode chamar, com autorização via IAM e OAuth já embutida.
AgentCore Memory
Mantém o contexto de curto e longo prazo das conversas do agente, com pipelines de extração e consolidação de memória que podem ser customizados conforme a necessidade de cada aplicação.
AgentCore Identity
Gerencia autenticação e autorização do agente, incluindo um cofre seguro para armazenar tokens de acesso e integração nativa com provedores OAuth, permitindo que o agente acesse sistemas de terceiros em nome do usuário com segurança.
AgentCore Observability
Fornece dashboards prontos via Amazon CloudWatch com visibilidade completa da execução do agente, incluindo cada chamada de ferramenta, latência e erro. Também é compatível com provedores externos como Datadog e Dynatrace.
AgentCore Browser Tool
Uma ferramenta de navegador sandboxed que permite ao agente navegar na web, preencher formulários e extrair informações de páginas, sem expor o ambiente de execução principal a esse acesso.
AgentCore Code Interpreter
Um ambiente sandboxed de execução de código, permitindo que o agente rode scripts, análises de dados ou gere relatórios de forma isolada e segura.
AgentCore Guardrails
Integra o Amazon Bedrock Guardrails diretamente na camada de política do Gateway, avaliando em tempo real as entradas e saídas de cada chamada do agente para bloquear ataques de prompt injection, conteúdo nocivo e exposição de dados sensíveis antes que cheguem a sistemas downstream.
Comparativo prático
| Componente | O que você teria que construir sem ele |
|---|---|
| Runtime | Infraestrutura própria de hospedagem, isolamento de sessão e auto scaling, geralmente combinando Lambda ou ECS com lógica customizada |
| Gateway | Integrações manuais entre o agente e cada API, Lambda ou servidor MCP, com autenticação própria para cada uma |
| Memory | Um banco de dados próprio, como DynamoDB, para guardar e recuperar contexto de conversas |
| Identity | Um sistema próprio de autenticação, geralmente com Cognito, e gestão manual de tokens de acesso a terceiros |
| Observability | Instrumentação manual com CloudWatch ou X-Ray espalhada pelo código do agente |
| Browser Tool | Um ambiente isolado próprio, como um container com Playwright ou Selenium, para automação de navegador |
| Code Interpreter | Um sandbox próprio de execução de código, isolado do restante da aplicação |
| Guardrails | Validação manual de prompt injection e conteúdo sensível em cada chamada do agente |
Um exemplo prático, módulo por módulo
Para ver como esses componentes se conectam na prática, vamos construir um exemplo genérico, um agente de suporte técnico interno, capaz de consultar tickets, verificar o status de serviços externos, analisar logs enviados pelo usuário e lembrar o contexto da conversa entre uma mensagem e outra. Cada etapa abaixo usa um componente diferente do AgentCore, e todo o código é baseado na sintaxe real do SDK e do CLI oficiais.
1. Runtime, hospedando o agente
O primeiro passo é envolver a lógica do agente com o SDK do Runtime, que expõe um endpoint padronizado de invocação.
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent
app = BedrockAgentCoreApp()
agent = Agent()
@app.entrypoint
def invoke(payload):
user_message = payload.get("prompt", "")
result = agent(user_message)
return {"result": result.message}
if __name__ == "__main__":
app.run()Com o código pronto, o deploy é feito diretamente pelo CLI do AgentCore, que empacota e publica o agente no Runtime.
CLIagentcore configure --entrypoint agente_suporte.py --non-interactive
agentcore launch
agentcore invoke '{"prompt": "Meu ticket 4521 ainda esta aberto?"}'
2. Gateway, conectando ao sistema de tickets
Antes de anexar qualquer tool, o Gateway em si é um recurso da AWS e pode ser provisionado como infraestrutura, por exemplo com o provider Terraform oficial da AWS, que já suporta os recursos do AgentCore.
resource "aws_iam_role" "gateway" {
name = "AgentCoreGatewayRole"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "bedrock-agentcore.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_bedrockagentcore_gateway" "suporte" {
name = "suporte-gw"
description = "Gateway do agente de suporte tecnico"
role_arn = aws_iam_role.gateway.arn
authorizer_type = "AWS_IAM"
protocol_type = "MCP"
}Com o Gateway no ar, expomos uma função Lambda já existente como uma tool do agente diretamente pelo CLI, sem reescrever nenhuma integração nem lidar com autenticação manualmente no código do agente.
CLIagentcore create_mcp_gateway_target \
--gateway-arn arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/suporte-gw \
--gateway-url https://suporte-gw.gateway.bedrock-agentcore.us-east-1.amazonaws.com \
--role-arn arn:aws:iam::123456789012:role/GatewayExecutionRole \
--target-type lambdaA partir desse momento, o agente passa a enxergar a consulta de tickets como mais uma tool disponível, da mesma forma que enxergaria qualquer outra ferramenta nativa.
3. Memory, lembrando o contexto da conversa
Para que o agente lembre do ticket mencionado anteriormente na mesma sessão, a Memory grava e recupera o histórico automaticamente, sem exigir um banco de dados próprio.
from bedrock_agentcore.memory import MemoryClient
client = MemoryClient(region_name="us-east-1")
memory = client.create_memory(
name="SuporteTecnicoMemory",
description="Memoria das conversas de suporte"
)
client.create_event(
memory_id=memory["memoryId"],
actor_id="usuario-123",
session_id="sessao-4521",
messages=[("Meu ticket 4521 ainda esta aberto?", "USER")]
)
contexto = client.retrieve_memories(
memory_id=memory["memoryId"],
query="ticket 4521"
)
4. Identity, acessando sistemas de terceiros com segurança
Se o agente também precisar consultar um painel de monitoramento externo em nome do usuário, o Identity cuida do fluxo OAuth2 completo, sem que nenhuma credencial precise ser manipulada diretamente no código do agente.
from bedrock_agentcore.identity.auth import requires_access_token
@requires_access_token(
provider_name="monitoramento-provider",
scopes=["monitoring.read"],
auth_flow="USER_FEDERATION",
on_auth_url=lambda url: print(f"Autorize o acesso em: {url}"),
)
async def consultar_status_servico(*, access_token: str):
# usa o access_token para chamar a API de monitoramento
...
5. Browser Tool, verificando o status de um fornecedor
Se o serviço externo relatado no ticket estiver fora do ar, o agente aciona o Browser Tool para navegar até a página pública de status do fornecedor, em um navegador isolado que roda fora do ambiente do agente.
from bedrock_agentcore.tools.browser_client import browser_session
from playwright.async_api import async_playwright
async def verificar_status_fornecedor(url_status):
with browser_session("us-east-1") as client:
ws_url, headers = client.generate_ws_headers()
async with async_playwright() as playwright:
browser = await playwright.chromium.connect_over_cdp(ws_url, headers=headers)
page = await browser.contexts[0].new_page()
await page.goto(url_status)
return await page.content()
6. Code Interpreter, analisando o log enviado pelo usuário
Quando o usuário anexa um arquivo de log, o agente executa um script de análise dentro do Code Interpreter, em um sandbox isolado do restante da aplicação.
from bedrock_agentcore.tools.code_interpreter_client import CodeInterpreter
code_client = CodeInterpreter("us-east-1")
code_client.start()
resposta = code_client.invoke("executeCode", {
"language": "python",
"code": "analisar_log('log_ticket_4521.txt')"
})
for evento in resposta["stream"]:
print(evento["result"])
code_client.stop()
7. Guardrails, bloqueando dados sensíveis
Para impedir que o agente exponha dados sensíveis do cliente na resposta, anexamos uma policy de Guardrails diretamente ao Gateway, avaliada antes de qualquer chamada chegar ao agente.
agentcore add policy \
--name BloqueiaDadosSensiveis \
--engine SuportePolicyEngine \
--gateway suporte-gw \
--target ticket-lambda \
--form-category contentFilter \
--form-filters SENSITIVE_INFORMATION \
--form-effect forbid
8. Observability, acompanhando tudo em produção
Por fim, habilitamos a Observability por variáveis de ambiente, sem precisar instrumentar o código do agente manualmente. A partir daí, cada chamada de tool, latência e erro passa a aparecer no GenAI Observability Dashboard do CloudWatch.
AGENT_OBSERVABILITY_ENABLED=true
OTEL_PYTHON_DISTRO=aws_distro
OTEL_PYTHON_CONFIGURATOR=aws_configurator
OTEL_RESOURCE_ATTRIBUTES=service.name=agente-suporte,aws.log.group.names=/aws/bedrock-agentcore/runtimes/agente-suporteNenhum desses módulos depende dos outros para funcionar, o que permite adotar o AgentCore de forma incremental. É possível começar só pelo Runtime e pela Memory, por exemplo, e adicionar Gateway, Identity, Guardrails ou as demais tools conforme a necessidade do agente crescer.
Adoção real do AgentCore
A Druva construiu o DruAI, um sistema multiagente de resposta a incidentes de segurança, utilizando praticamente todos os componentes do AgentCore, incluindo Runtime, Gateway, Code Interpreter, Identity e Memory. O resultado foi 68% dos chamados de suporte resolvidos sem intervenção humana, com 58% de redução no tempo de resolução quando um humano precisa atuar, mais de 17.500 conversas em 4 meses e zero alucinações reportadas.
Já a Cox Automotive usou o Runtime, Memory, Observability e Identity do AgentCore para colocar 17 soluções em produção a partir de 57 oportunidades identificadas. Um dos casos, o FleetMate, reduziu o tempo de estimativa de reparo de frota de 8 a 48 horas para 30 minutos, com um protótipo construído em apenas 4 dias.
A própria Lascasas Consulting já aplicou o AgentCore em três estudos de caso publicados neste site, sempre com o Runtime e a Memory como base da arquitetura: um tutor de IA para educação, um sistema de recrutamento inteligente com múltiplos agentes especialistas coordenados, e um agente de prospecção comercial.
Resumo
O AgentCore não substitui a engenharia de prompt nem a escolha do modelo certo, mas resolve o que normalmente consome mais tempo de desenvolvimento ao colocar um agente em produção, que é hospedagem, memória, autenticação, observabilidade e guardrails. Ao adotar esses componentes como serviços gerenciados, equipes de engenharia podem dedicar mais tempo ao comportamento do agente e menos tempo reconstruindo uma infraestrutura que já existe pronta na AWS.