User's blog

Migrando agentes de IA multi-modelo para o Amazon Bedrock AgentCore Runtime

Written by

Make.com Service User

in

O problema: infraestrutura demais, lógica de menos

Quem já tentou colocar agentes de IA em produção sabe o quanto a infraestrutura pode virar o maior obstáculo. Orquestração de containers, políticas de escalonamento, gerenciamento de identidade, observabilidade — tudo isso precisa ser configurado e mantido pela equipe. O resultado é que os times acabam gastando mais tempo cuidando de infraestrutura do que desenvolvendo a lógica dos próprios agentes.

Esse é exatamente o cenário que a AWS aborda em um post técnico recente, mostrando como migrar um agente de IA multi-modelo de saúde de uma infraestrutura autogerenciada no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate para o Amazon Bedrock AgentCore Runtime — sem reescrever nenhuma linha da lógica do agente.

O que é o Amazon Bedrock AgentCore Runtime

O Amazon Bedrock AgentCore é uma plataforma para construir, conectar e otimizar agentes em escala, compatível com qualquer framework ou modelo. Seu componente de runtime é a capacidade de implantação gerenciada da plataforma: ele cuida do ciclo de vida dos containers, escalonamento, identidade e observabilidade automaticamente.

A proposta é simples: o time foca no código do agente, e o AgentCore Runtime resolve o resto. Para quem já tem agentes rodando em infraestrutura própria, o caminho de migração é direto — basta envolver o código existente com o padrão decorator do AgentCore, sem adaptar a lógica para nenhum framework específico.

A solução: agente de saúde com três backends de modelo

O exemplo utilizado pela AWS migra um agente de IA para o setor de saúde que processa consultas médicas usando três backends de modelo diferentes, com recuperação de conhecimento vetorial. Toda essa orquestração roda dentro de um único container gerenciado pelo AgentCore.

A distribuição de tarefas entre os modelos funciona assim:

Os três backends implementam compatibilidade com a API de mensagens do Hugging Face, garantindo formatos de requisição e resposta consistentes independentemente do serviço de modelo escolhido. Para recuperação de conhecimento, a solução utiliza o Amazon OpenSearch Service para busca por similaridade vetorial e indexação de conhecimento médico.

Vale destacar um ponto importante: o post anterior da AWS usava o Claude 3.5 Sonnet V2 da Anthropic. Nesta versão, o Claude 3.5 Sonnet V2 da Anthropic foi substituído pelo Llama 3.1 70B da Meta — o que demonstra que o AgentCore Runtime é agnóstico em relação ao modelo utilizado. A escolha do modelo é uma decisão de implementação, não um requisito da plataforma.

O framework utilizado como referência é o Hugging Face smolagents, uma biblioteca Python de código aberto projetada para construir e executar agentes com poucas linhas de código. A implementação completa está disponível no repositório do GitHub.

Como funciona a migração na prática

A migração usa o padrão decorator do AgentCore. Os três componentes centrais são:

  • BedrockAgentCoreApp — inicializa a aplicação AgentCore.
  • @app.entrypoint — decora a função que o AgentCore Runtime chama ao receber uma requisição.
  • app.run() — inicia o servidor do AgentCore Runtime.

O padrão de integração fica assim:

from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
def healthcare_agent_entrypoint(payload):
    user_input = payload.get("prompt", "")
    model_type = payload.get("model_type", "sagemaker")
    # Your existing agent logic here
    agent = TripleHealthcareAgent(vector_store=vector_store)
    response = agent.run(user_input, model_type=model_type)
    return str(response)

if __name__ == "__main__":
    app.run()

O código do agente entre o decorator e o return permanece exatamente igual à versão standalone. O AgentCore Runtime gerencia ciclo de vida do container, escalonamento, identidade e observabilidade de forma automática.

Pré-requisitos para a migração

Antes de iniciar o processo, é necessário ter em mãos:

A implementação usa Python 3.10+, framework smolagents, transformers 4.55.0+ e boto3.

Passo a passo da implantação

1. Criar o projeto AgentCore

Instale o AgentCore CLI e crie o projeto:

npm install -g @aws/agentcore
agentcore create --project-name healthcareagent --no-agent --build Container --language Python --protocol HTTP --model-provider Bedrock --memory none

2. Adicionar o agente existente

Adicione o agente existente como uma implantação do tipo “traga seu próprio agente” (BYO — Bring Your Own):

agentcore add agent --name healthcare_agentcore --type byo --build Container --language Python --protocol HTTP --network-mode PUBLIC --code-location ./agent-code --entrypoint healthcare_agentcore.py --framework Strands --model-provider Bedrock

Observação: o flag --framework especifica o template do CLI. O código real do agente usa o Hugging Face smolagents, que é compatível com o AgentCore Runtime independentemente do template selecionado.

3. Preparar o container

Crie um arquivo pyproject.toml no diretório do agente para definir as dependências:

[project]
name = "healthcare-agentcore"
version = "1.0.0"
requires-python = ">=3.10"
dependencies = [
    "smolagents>=1.24.0",
    "transformers>=4.55.0",
    "boto3>=1.37.0",
    "opensearch-py>=3.1.0",
    "requests-aws4auth>=1.3.1",
    "bedrock-agentcore>=0.1.0",
    "numpy>=1.26.0",
    "requests>=2.32.0",
    "docker>=7.1.0",
]

Crie também o Dockerfile:

FROM public.ecr.aws/docker/library/python:3.12-slim
RUN pip install --no-cache-dir uv
WORKDIR /app
COPY pyproject.toml ./
RUN uv pip install --system -r pyproject.toml
COPY . .
EXPOSE 8080
CMD ["python", "healthcare_agentcore.py"]

Crie um arquivo .dockerignore para manter o tamanho da imagem dentro do limite de 2 GB:

venv/
.venv/
__pycache__/
.git/
*.pyc

4. Fazer o deploy

Com o projeto configurado, basta executar um único comando para implantar o agente:

agentcore deploy -y

O CLI constrói o container, envia para o Registro de Container Elástico da Amazon (Amazon ECR) e cria o agente no AgentCore Runtime. O processo leva aproximadamente 10 a 15 minutos.

5. Testar o agente implantado

É possível testar o agente de duas formas: via AgentCore CLI ou programaticamente com boto3.

Via CLI:

agentcore invoke --prompt '{"prompt": "What are the side effects of metformin?", "model_type": "llama"}'

Via boto3:

import boto3, json

client = boto3.client('bedrock-agentcore', region_name='us-west-2')

payload = json.dumps({
    "prompt": "What are the side effects of metformin?",
    "model_type": "llama"
})

response = client.invoke_agent_runtime(
    agentRuntimeArn='',
    contentType='application/json',
    accept='application/json',
    payload=payload.encode('utf-8')
)

result = response['response'].read().decode('utf-8')
print(result)

ECS com Fargate vs. AgentCore Runtime: qual a diferença real?

Ambas as abordagens executam o mesmo agente, mas de formas distintas. A versão standalone no Amazon ECS com AWS Fargate exige que o time defina as task definitions do ECS, configure políticas de escalonamento, gerencie funções do Gerenciamento de Identidade e Acesso da AWS (IAM) por serviço e configure observabilidade via Amazon CloudWatch. A implantação envolve um build Docker, push para o Amazon ECR e atualização do serviço ECS. Esse caminho oferece controle total sobre configuração de container, rede e comportamento de escalonamento.

Já a versão com AgentCore Runtime executa o mesmo arquivo healthcare_agentcore.py com o padrão decorator do AgentCore. O runtime fornece orquestração de containers, escalonamento baseado em sessão, gerenciamento de identidade via integração com IAM e observabilidade com rastreamento e logs integrados. A implantação é feita com um único comando (agentcore deploy).

Em ambos os casos, os seguintes elementos permanecem idênticos ao migrar da versão standalone para o AgentCore Runtime:

  • Lógica central do agente (decorator BedrockAgentCoreApp + código existente).
  • Orquestração multi-modelo entre Amazon Bedrock, Amazon SageMaker AI e backends containerizados.
  • Recuperação de conhecimento vetorial com Amazon OpenSearch Service.
  • Compatibilidade com a API de mensagens do Hugging Face entre os backends de modelo.

Limpeza dos recursos

Para evitar cobranças futuras, remova os recursos criados quando não forem mais necessários.

Remova o agente do AgentCore Runtime:

agentcore remove all
agentcore deploy

Exclua o endpoint do Amazon SageMaker AI:

aws sagemaker delete-endpoint --endpoint-name healthcare-agentcore-endpoint-1 --region us-west-2

Exclua o domínio do Amazon OpenSearch Service:

aws opensearch delete-domain --domain-name healthcare-vector-store --region us-west-2

Conclusão

A AWS demonstra com esse exemplo que migrar um agente de IA multi-modelo de infraestrutura autogerenciada para o Amazon Bedrock AgentCore Runtime não exige reescrever a lógica do agente. O mesmo arquivo healthcare_agentcore.py orquestra Amazon Bedrock, Amazon SageMaker AI e um servidor de modelo containerizado — agora com o suporte do AgentCore Runtime mediante a adição do padrão decorator (BedrockAgentCoreApp, @app.entrypoint e app.run()).

O design agnóstico em relação a frameworks suporta uma ampla combinação de modelos e frameworks de agentes, tornando esse padrão de migração aplicável em setores como saúde, serviços financeiros e manufatura. Para quem quiser explorar a implementação completa, o repositório está disponível no GitHub. Para entender a implementação standalone que serviu de base, a AWS indica o post Agentic AI with multi-model framework using Hugging Face smolagents on AWS.

Leituras recomendadas

Fonte

Migrating multi-model AI agents to Amazon Bedrock AgentCore runtime (https://aws.amazon.com/blogs/machine-learning/migrating-multi-model-ai-agents-to-amazon-bedrock-agentcore-runtime/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts