Strands Agents: Framework da AWS para Agentes Autônomos em Python

Introdução

Construir agentes autônomos – sistemas de IA capazes de tomar decisões e realizar ações de forma independente – tornou-se mais fácil com a evolução dos LLMs (Modelos de Linguagem de Grande Porte). No ecossistema Python, surgiu recentemente o Strands Agents, um framework open source desenvolvido pela AWS, projetado para simplificar a criação de agentes de IA. O Strands adota uma abordagem orientada por modelos (model-driven approach), aproveitando ao máximo as capacidades de raciocínio dos LLMs modernos para planejar passos, utilizar ferramentas e refletir sobre objetivos, sem que o desenvolvedor precise codificar fluxos complexos de forma explícita . Em poucas linhas de código, podemos definir um agente especificando apenas três elementos fundamentais – um modelo de linguagem, um conjunto de ferramentas e um prompt –, e o Strands se encarrega de orquestrar todo o resto . Diferentemente de frameworks anteriores que exigiam definir workflows complicados, o Strands foi concebido para reduzir a complexidade de orquestração, confiando nas capacidades nativas dos modelos atuais de seguir instruções estruturadas e chamar ferramentas externas .

Neste post, exploraremos os conceitos centrais e a arquitetura interna do Strands Agents de forma didática e técnica, porém acessível mesmo para quem não é especialista em agentes de IA. Abordaremos os princípios de design por trás do framework, seus componentes internos e como ele se posiciona em relação a outras soluções no ecossistema Python. Também veremos exemplos de fluxos de execução típicos de um agente no Strands e ilustrações da arquitetura para esclarecer seu funcionamento.

Conceitos Básicos: Modelo, Ferramentas e Prompt

No coração do Strands está uma definição simples de agente autônomo: um agente é a combinação de um modelo de linguagem, um conjunto de ferramentas e um prompt . Esses três componentes fundamentais formam a base a partir da qual o agente irá operar:

1. Modelo (LLM) – É o cérebro do agente, responsável por raciocinar e gerar ações. O Strands é agnóstico em relação a provedores de modelo: é possível conectar qualquer LLM moderno que suporte uso de ferramentas e streaming, incluindo modelos do Amazon Bedrock, OpenAI, Anthropic (Claude), modelos locais via Ollama ou Llama API, entre outros . A arquitetura de provedores de modelo é extensível, permitindo adicionar facilmente um provedor customizado se necessário. Em resumo, você pode aproveitar o modelo de IA de sua preferência ou necessidade, já que o Strands abstrai as diferenças entre APIs de modelos diferentes.

2. Ferramentas (Tools) – São as interfaces que permitem ao agente interagir com o mundo externo além do modelo. Quando o LLM identifica que precisa realizar uma ação que vai além de sua base de conhecimento (por exemplo, ler um arquivo, fazer uma requisição HTTP, consultar um banco de dados ou executar um cálculo), ele pode invocar uma ferramenta. O Strands inclui suporte nativo a dezenas de ferramentas prontas (built-in), como leitura/gravação de arquivos, busca em documentos, chamadas de API (inclusive integrações prontas com serviços AWS) . Além disso, qualquer função Python pode se tornar uma ferramenta com um simples decorator @tool . O Strands também suporta o protocolo MCP (Model Context Protocol), um padrão aberto que permite usar milhares de ferramentas disponibilizadas como microsserviços externos . Cada ferramenta possui um schema de entrada/saída bem definido – isso possibilita ao framework validar as chamadas e enviar os resultados de volta ao modelo de forma estruturada e segura .

3. Prompt – É a instrução em linguagem natural que define a tarefa ou o papel do agente. Pode incluir um prompt do usuário (a tarefa específica a realizar, pergunta a responder, etc.) e também um prompt de sistema que configura o comportamento desejado do agente (regras, estilo de resposta, objetivos gerais). Essencialmente, o prompt estabelece o que o agente deve fazer ou qual problema deve resolver. No Strands, define-se o prompt de forma declarativa (uma string para o sistema e/ou usuário) e o restante – como garantir que o modelo siga instruções ou retorne no formato esperado – é gerenciado pelo framework. Em agentes complexos, o prompt pode orientar o modelo a planejar passos, usar ferramentas de forma iterativa e até respeitar políticas de segurança (via guardrails, que abordaremos mais adiante).

Ao criar um agente com o Strands, o desenvolvedor instancia um objeto Agent fornecendo esses três componentes. Por exemplo, podemos definir um agente com uma lista de ferramentas e um prompt, e opcionalmente escolher um modelo (caso contrário, um modelo padrão do Bedrock pode ser usado, se disponível) . Com uma configuração mínima, o agente já está pronto para ser executado localmente ou em produção.

O Agent Loop: Raciocínio e Ação em Ciclo

Um diferencial central do Strands está na implementação do chamado agentic loop, ou loop do agente – o mecanismo cíclico que permite ao agente alternar entre pensar (reasoning) e agir (acting) até chegar a uma solução. Em termos simples, “um modelo de linguagem pode responder a perguntas. Um agente pode fazer coisas” – e é o loop de agente que viabiliza essa diferença .

Como funciona? O loop do agente executa as seguintes etapas repetidamente: o Strands invoca o modelo com o prompt e o contexto atual; o modelo analisa o problema e decide se precisa usar alguma ferramenta; se sim, o framework executa a ferramenta solicitada e retorna o resultado ao modelo, acrescentando essa informação ao contexto; o modelo então reconsidera a situação com o novo dado e pode decidir por outra ação ou por encerrar o ciclo com uma resposta final . Esse ciclo de pensar -> agir -> pensar… se repete quantas vezes forem necessárias até o agente concluir a tarefa ou atingir algum critério de parada.

Fluxo simplificado do loop de um agente Strands: o modelo (LLM) alterna entre fases de raciocínio e execução de ferramentas até produzir uma resposta final. Cada iteração adiciona ao histórico de conversação, enriquecendo o contexto para as próximas decisões.

No diagrama acima (adaptado da documentação oficial), vemos o fluxo típico de execução: o agente recebe uma entrada (o prompt do usuário, possivelmente acompanhado de contexto adicional ou memória pregressa) e inicia o Loop. Dentro desse loop, o modelo LLM gera um pensamento ou intenção com base no contexto; em seguida, há uma etapa de escolha de ferramenta, em que o modelo indica querer usar uma ferramenta específica; a ferramenta é então executada pelo framework, e o resultado retorna para a entrada do modelo, fechando o ciclo. O loop continua até que o modelo decida que já possui informação suficiente para responder e produz a resposta final .

O poder desse padrão está na acumulação de contexto: a cada iteração, o histórico de conversação do agente é enriquecido com novas mensagens – incluindo as ações tomadas e os resultados obtidos – o que permite ao modelo lidar com tarefas de múltiplas etapas de forma coerente . Por exemplo, considere uma tarefa de análise de vulnerabilidades em um repositório de código. O agente pode começar pedindo uma listagem de arquivos (ferramenta de diretório), depois ler certos arquivos fonte (ferramenta de leitura), identificar padrões suspeitos e fazer buscas específicas no código (ferramenta de busca em texto), acumulando achados ao longo do caminho. Em cada passo, o modelo vê não apenas o pedido original, mas também todas as ações e resultados anteriores, permitindo um raciocínio cada vez mais informado até chegar a uma conclusão final .

Alguns detalhes importantes desse loop de agente no Strands:

• Mensagens e Histórico: O Strands estrutura a comunicação em mensagens do usuário e mensagens do assistente (agente). Mensagens de usuário incluem tanto consultas do usuário quanto resultados de ferramentas (que são inseridos como se fossem mensagens de usuário para que o modelo as veja), enquanto mensagens do assistente incluem as respostas do LLM e também instruções de uso de ferramenta quando o modelo opta por agir . Toda iteração adiciona mensagens ao histórico, funcionando como a memória de curto prazo do agente. O framework oferece gerenciadores de conversação (Conversation Managers) para evitar que esse histórico exceda os limites de contexto do modelo – por exemplo, estratégias de janela deslizante ou sumarização automática dos trechos mais antigos, mantendo apenas os pontos relevantes .

• Execução de Ferramentas Segura: Quando o modelo decide usar uma ferramenta, o Strands cuida de todo o processo de validação, execução e tratamento de erros. Ele verifica se os parâmetros fornecidos pelo modelo batem com o esquema esperado da ferramenta, executa a ação (por exemplo, chama a função Python ou serviço correspondente) e encapsula o resultado em uma mensagem de retorno para o modelo . Se ocorrer um erro na ferramenta (ex: exceção, falha de rede), isso não encerra o loop imediatamente; em vez disso, o erro é capturado e devolvido ao modelo como um resultado de ferramenta indicando falha, permitindo que o agente tente se recuperar ou tome outra ação ao invés de simplesmente abortar . Esse mecanismo torna o agente mais robusto, já que o LLM pode aprender com falhas de ferramenta e decidir um plano B (por exemplo, tentar uma ferramenta alternativa ou ajustar a consulta).

• Critérios de Parada: Cada chamada ao modelo retorna junto com um código de parada (stop reason) indicando o porquê daquela iteração ter terminado. Os cenários incluem: turno concluído (o modelo finalizou sua resposta sem solicitar novas ações, indicando término bem-sucedido do loop), uso de ferramenta (o modelo pediu uma ou mais ferramentas – o loop continuará após executá-las), limite de tokens atingido (o modelo bateu no teto de tokens e não pôde continuar – caso de erro irrecuperável dentro daquele ciclo), sequência de parada configurada encontrada (um sinal predefinido para encerrar a resposta, tratado como término normal), ou intervenção de segurança (conteúdo bloqueado por filtros ou guardrails) . O Strands trata gracefully os casos de término por segurança, garantindo que o loop pare e retorne controle à aplicação conforme a política definida.

• Extensibilidade via Hooks: O loop em si é genérico, mas o Strands emite eventos de ciclo de vida em pontos-chave – antes/depois de cada iteração, antes/depois de cada chamada de modelo, antes/depois de cada execução de ferramenta, etc. Através de hooks, podemos observar ou até modificar o comportamento do agente nesses pontos sem precisar alterar o núcleo do loop . Isso é útil para telemetria, logging, métricas e customizações. Por exemplo, poderíamos logar cada ferramenta usada e seu resultado, ou medir o tempo de cada iteração, ou inserir lógica adicional antes de certas ferramentas serem executadas. Esses mecanismos de extensão refletem um princípio de design importante: manter o núcleo simples, mas permitir integrações e ajustes customizados quando necessário (ver seção de Observabilidade).

Em resumo, o agent loop do Strands encapsula o padrão de raciocinar e agir iterativamente (ReAct loop ) de forma confiável e transparente para o desenvolvedor. Graças a melhorias recentes nos LLMs – que hoje já entendem nativamente instruções de uso de ferramentas e podem gerar formatos estruturados como JSON – o Strands evita orquestrações manuais excessivamente complexas. O modelo de IA está no volante do agente, enquanto o framework fornece os pedais e câmbio automáticos para que o trajeto ocorra sem sobressaltos.

Estado, Memória e Gerência de Sessão

Agentes autônomos efetivos precisam gerenciar o contexto ao longo da interação, e o Strands provê componentes para isso através de estado do agente e gerência de sessão. Embora o loop descrito acima seja muitas vezes transiente (processa uma única tarefa até conclusão), em aplicações reais é comum querermos persistir informações de uma execução para outra, ou manter um histórico consolidado de várias conversas.

• Estado do Agente: Em Strands, o estado refere-se aos dados mantidos entre iterações do loop e inclui coisas como o histórico de mensagens, variáveis internas ou qualquer artefato gerado que deva ser carregado adiante . O estado é encapsulado em objetos de classe State ou similares, permitindo salvar e restaurar se necessário. Por exemplo, se um agente é interrompido ou se precisamos mover a execução dele para outro ambiente, podemos serializar seu estado (histórico, memória de ferramenta, etc.) e depois reconstruí-lo, continuando de onde parou.

• Gerenciadores de Conversa (Conversation Managers): Conforme mencionado, o Strands oferece diferentes estratégias para limitar o tamanho do histórico de mensagens dentro da janela de contexto do modelo. Dependendo do modelo escolhido, o contexto completo (instruções + histórico) só pode ter um número limitado de tokens. O Strands implementa gestores como janela deslizante (mantém apenas as N mensagens mais recentes ou até X tokens) , resumo dinâmico (condensa partes antigas em um sumário para liberar espaço) ou até abordagens híbridas. O desenvolvedor pode escolher um gerenciador adequado ou implementar um próprio, conforme a natureza da aplicação (p. ex., para um agente conversacional que deve lembrar de todo o histórico do dia, pode-se usar sumarização, enquanto para um agente de tarefa única talvez não precise mais que uma janela curta).

• Sessões e Memória Persistente: O Strands foi pensado para uso production-ready, e isso implica suportar múltiplas sessões de agentes e armazenamento de memória persistente. Ele fornece abstrações de Session Manager – por exemplo, existem implementações prontas que utilizam arquivos locais, Amazon S3 ou Redis para armazenar o histórico e estado de cada sessão . Assim, um agente implantado em produção pode manter contexto de usuário entre diferentes execuções ou requisições, possibilitando continuidade (um caso de uso comum é um agente em um chatbot que “lembra” conversas anteriores do mesmo usuário). Essa organização interna de sessão também facilita escalabilidade: várias instâncias do agente podem compartilhar um repositório de sessão comum, garantindo consistência do estado mesmo se o agente for executado distribuídamente (ex: em múltiplas Lambdas ou pods Kubernetes).

Em suma, o Strands separa bem a lógica de raciocínio (loop de agente) da lógica de memória e persistência, oferecendo componentes plugáveis para gerenciar o estado conversacional. Isso reflete um princípio de projeto importante: flexibilidade na gerência de dados, permitindo adequar o framework a diferentes requisitos de aplicação (desde protótipos locais até sistemas distribuídos com milhares de usuários).

Ferramentas: Conectando o Agente ao Mundo Externo

Um dos aspectos mais práticos (e poderosos) de agentes de IA é a capacidade de usar ferramentas para realizar ações. No Strands, o design das ferramentas merece destaque pelos seguintes motivos:

Abordagem Declarativa e Orientada a Schema: Cada ferramenta em Strands é definida por:

• um nome e descrição (que serão usados para apresentar a ferramenta ao LLM no prompt),

• uma assinatura de função ou esquema de parâmetros de entrada e saída,

• uma implementação de função (no caso de ferramentas locais em Python) ou um endpoint/protocolo (no caso de ferramentas remotas via MCP).

Essa definição clara permite que o Strands automaticamente documente as ferramentas para o modelo e valide as chamadas. Quando um agente inicia, o framework concatena as descrições das ferramentas disponíveis em um formato que o modelo consiga entender (por exemplo, usando formato function calling do OpenAI ou instruções textuais estruturadas) . Assim, o LLM sabe quais ações estão ao seu dispor e como utilizá-las. Ao receber uma saída do modelo indicando intenção de ferramenta, o Strands analisa (tipicamente em JSON) qual ferramenta foi escolhida e com quais argumentos, confere se bate com o esquema declarado e só então executa a chamada . Essa intermediação é crucial para manter segurança e consistência, evitando que uma resposta malformada do modelo que pareça uma chamada de ferramenta quebre o fluxo.

Decorators e Ferramentas Personalizadas: Transformar funções Python em ferramentas é trivial com o decorador @tool fornecido pelo SDK . Por exemplo, suponha que temos uma função Python def traduzir(texto: str, idioma: str) -> str para traduzir texto usando alguma API; ao marcar com @tool, podemos adicionar essa função à lista de ferramentas do agente. O Strands inspeciona a assinatura (parâmetros texto e idioma e retorno str) e monta automaticamente o esquema e a documentação para o modelo. Isso incentiva um design limpo: a lógica de cada ação fica isolada em funções reutilizáveis, enquanto o agente LLM apenas orquestra quais ações chamar e em que sequência.

MCP e Ferramentas Distribuídas: O Model Context Protocol (MCP) merece menção especial. É um protocolo aberto que padroniza como servers de ferramentas podem registrar quais ações oferecem e como um agente pode consultá-los. O Strands integra-se profundamente a esse padrão, o que significa que seu agente pode facilmente consumir ferramentas servidas externamente (por exemplo, uma API REST que cumpre o protocolo MCP pode ser chamada como ferramenta). A AWS e a comunidade disponibilizam “servidores MCP” para diversas utilidades – um dos exemplos citados é um servidor com mais de 6.000 ferramentas internas na Amazon, que um agente pode consultar semanticamente para descobrir qual ferramenta é relevante para sua tarefa . Evidentemente, um LLM não consegue avaliar diretamente uma lista de 6 mil opções, então a estratégia usada é ter uma ferramenta retrieval que busca no conhecimento base a descrição de ferramentas relevantes e apresenta apenas um subconjunto manejável para o modelo . Este é um padrão habilitado pelo Strands: ferramentas para encontrar ferramentas, demonstrando a flexibilidade do conceito.

Execução Paralela e Sequencial: O Strands permite que um modelo peça uma ou várias ferramentas de uma vez numa mesma iteração . Se o modelo suportar retornar múltiplas chamadas (por exemplo, planejar “faça X e Y” juntas), o framework pode lidar com isso. Existe inclusive uma abstração de Executors para controlar se as ferramentas devem rodar sequencialmente ou em paralelo . Por padrão, as ferramentas requisitadas em um mesmo passo são executadas sequencialmente na ordem retornada pelo modelo (pois às vezes a saída de uma ferramenta pode ser insumo para a próxima). Porém, em casos onde as ações são independentes, um executor concorrente pode acelerar o processo executando múltiplas ferramentas simultaneamente, agregando os resultados ao final para devolver ao modelo. Essa capacidade é valiosa em cenários de agentes que precisam realizar várias consultas externas ao mesmo tempo (por exemplo, coletar dados de diferentes fontes em paralelo).

Falhas e Segurança: Conforme mencionado, se uma ferramenta falha, o Strands captura a exceção e a devolve como resultado de erro para o modelo . Além disso, o Strands permite configurar limites de tempo (timeouts) para ferramentas ou outras salvaguardas, para evitar que uma ação demorada trave o agente indefinidamente. Em ambientes de produção, é possível isolar a execução de ferramentas em sandboxes ou serviços separados (ver próxima seção de Arquiteturas de Produção) para aumentar a segurança – por exemplo, rodar código potencialmente perigoso (como uma ferramenta que executa comandos do sistema) em um ambiente controlado.

Resumindo, o subsistema de ferramentas do Strands é projetado com modularidade e robustez em mente. As ferramentas são cidadãs de primeira classe no design do agente – são fáceis de adicionar, têm contratos claros e o agente consegue decidir de forma autônoma quando e como usá-las. Esse design reflete um princípio fundamental: capacitar o modelo a agir, fornecendo-lhe os meios (ferramentas) e cuidando dos detalhes para que cada ação seja realizada com segurança e retorno adequado de informações .

Padrões Multiagente e Colaboração de Agentes

Embora muitos casos de uso possam ser atendidos com um único agente equipado com ferramentas, o Strands foi concebido desde o início para suportar também sistemas com múltiplos agentes cooperando. A própria AWS e comunidade têm explorado “multi-agent systems” para tarefas complexas, e o Strands oferece primitivas simples para composições como Agents-as-Tools, Swarms e Graphs . Vamos entender o que significam esses padrões e como o framework os implementa:

• Agent-as-Tool (Agentes como Ferramentas): É o padrão análogo ao modelo orquestrador e especialistas. Um agente pode ser encapsulado como uma ferramenta e disponibilizado para outro agente utilizá-lo quando necessário . Por exemplo, podemos ter um agente “pesquisador” configurado com habilidades de buscar dados e outro agente “matemático” capaz de fazer cálculos; então um agente principal “orquestrador” pode chamar o pesquisador ou matemático como se fossem ferramentas, delegando sub-tarefas a eles . Internamente, o Strands torna isso fácil: basta instanciar o agente especializado e decorá-lo como @tool (ou usar a classe utilitária de Agents-as-Tools). Quando o orquestrador invoca essa ferramenta, o framework dispara o loop do agente especializado em background e captura seu resultado . O resultado retorna então ao orquestrador como se fosse a saída de uma ferramenta comum. Esse padrão cria uma hierarquia clara e é útil para dividir responsabilidades por domínio (um agente para cada expertise).

• Swarm (Enxame de Agentes): No padrão swarm, não há um orquestrador central – diversos agentes operam em paralelo e comunicam-se entre si diretamente, formando uma rede cooperativa . Isso é útil para exploração de ideias, brainstorming ou problemas em que múltiplos pontos de vista e colaboração peer-to-peer podem levar a uma solução melhor . Por exemplo, você pode ter três agentes “iguais” discutindo entre si para chegar a um consenso: cada um lê as mensagens dos outros e contribui com sua parcela. O Strands suporta esse esquema através de ferramentas de comunicação e estrutura de graph (grafo) de agentes. Existe uma ferramenta agent_graph que facilita configurar uma topologia de rede entre agentes (por exemplo, todos conectados a todos, ou um determinado padrão de mensagens) . Os agentes em um swarm podem rodar cada um em sua thread ou processo separado, e o Strands cuida de encaminhar as mensagens conforme a topologia definida . Cabe ao desenvolvedor definir a política de interação: pode ser colaborativa (agentes constroem juntos a resposta, compartilhando achados) ou competitiva (agentes tentam soluções independentes e comparam resultados, até mesmo criticando uns aos outros) – o framework é flexível para implementar qualquer lógica de coordenação desejada, já que expõe hooks e a estrutura de comunicação, mas não engessa o conteúdo das mensagens.

• Graph e Workflow (Fluxos Orquestrados): Além dos swarms mais livres, o Strands facilita compor agentes em estruturas de grafo ou fluxo determinístico. No caso de um workflow, imagina-se uma sequência pré-definida de etapas, onde cada etapa é desempenhada por um agente diferente ou pelo mesmo agente com papéis distintos. Por exemplo, um fluxo de atendimento ao cliente poderia ter um agente que primeiro coleta informações, depois passa para outro agente que faz análise, e por fim outro que gera um relatório. Já um graph mais genérico permite ramificações e junções – similar a um fluxo, mas não precisa ser linear. O Strands fornece utilitários para montar esses gráficos: você pode declarar que a saída do Agente A vai para o B e C, depois suas saídas convergem para D, etc. As primitivas internas para isso incluem o uso do agent_graph mencionado e possivelmente uma classe de Workflow ou GraphTool que o SDK disponibiliza . Inclusive, a documentação do Strands traz exemplos de Cyclic Graph e Agents Workflow mostrando como implementar tais padrões (ex.: um grafo cíclico onde agentes podem retroalimentar informações até convergência) .

• Agent2Agent (A2A) Protocol: Para cenários em que agentes rodam não apenas em processos distintos mas potencialmente em máquinas diferentes ou linguagens diferentes, o Strands adotou o protocolo A2A (Agent-to-Agent). O A2A é um padrão aberto que define como agentes de IA podem descobrir uns aos outros, trocar mensagens e colaborar via rede . No Strands, é possível levantar um servidor A2A (baseado em FastAPI/Starlette) que expõe um agente na rede como serviço, e outros agentes podem usar um cliente A2A para se conectar a ele . Em essência, isso generaliza o Agents-as-Tools para o contexto distribuído: em vez de importar um agente Python local como ferramenta, você pode tratar um agente remoto como ferramenta via A2A. O Strands já traz implementações e exemplos de servidor e cliente A2A, tornando relativamente simples criar microserviços de agentes que falam entre si. Esse recurso foi anunciado como novidade em evolução na época do lançamento , reforçando o compromisso do Strands com padrões abertos e interoperabilidade.

Naturalmente, a escolha de usar múltiplos agentes traz complexidade adicional, mas o Strands se esforça para fornecer “primitivas simples para multi-agente” . O desenvolvedor não precisa construir do zero protocolos de comunicação ou gerenciar threads manualmente – o framework provê os blocos básicos, mantendo a filosofia “just-enough orchestration” (orquestração na medida certa) . Isso posiciona o Strands como um dos primeiros frameworks a dar suporte integrado e estruturado para sistemas multiagente no ecossistema Python, indo além do modelo tradicional de agente único isolado.

Arquitetura Interna e Princípios de Design

Tendo passado pelos conceitos e padrões que o Strands habilita, vamos olhar “por baixo do capô” para entender a arquitetura interna e as decisões de projeto que tornam tudo isso possível. Como um framework pensado para produção, vários princípios nortearam seu design:

1. Minimalismo Orquestrador: O Strands foi concebido de forma leve (lightweight) – ele atua principalmente como um orquestrador entre o LLM e as ferramentas, introduzindo o mínimo de camadas necessário . Isso contrasta com frameworks mais antigos que impunham arquiteturas elaboradas e workflows fixos. No Strands, se você inspecionar o código (disponível no GitHub), verá que a classe central Agent engloba um loop genérico e utiliza componentes plugáveis para decisões especializadas (como escolha de ferramenta, gestão de memória, etc.). Ao aproveitar que os LLMs modernos já conseguem “planejar, encadear pensamentos e usar ferramentas” nativamente , o core do Strands permanece enxuto – ele não tenta adivinhar a estratégia do agente, apenas facilita o modelo a executar sua estratégia. Essa filosofia se traduz em menos overhead e mais flexibilidade para o desenvolvedor moldar o agente conforme a necessidade.

2. Componentização e Extensibilidade: A estrutura interna do Strands é altamente modular. Há componentes dedicados para:

• Loop/Event Loop: Gerencia chamadas ao modelo e coordena ferramentas (núcleo da classe Agent e EventLoop) .

• Conversação/Memória: Classes para ConversationManager, que implementam políticas de janela de contexto (SlidingWindow, Summarizing, etc.) , e SessionManagers para persistência (FileSession, S3Session, etc.) .

• Modelo/Providers: Abstrações para diferentes LLMs (classes OpenAI, Bedrock, Anthropic, etc., todas derivando de uma interface comum) .

• Ferramentas/Tools: Mecanismos para registrar e descobrir ferramentas (ToolRegistry), decoradores e schemas (tools.Decorator e Tool base) , executores concorrentes vs sequenciais , além de protocolos como MCP.

• Multiagente: Classes para Swarm, Graph e Workflow, bem como servidor e cliente A2A (por exemplo, AgentGraph, Swarm, A2AServer, etc.) .

• Observabilidade: Integracão com OpenTelemetry (módulo Telemetry com Tracer, Metrics etc.) .

• Segurança: Suporte a guardrails, filtragem de conteúdo e redação de PII (módulos em Safety & Security).

Cada parte acima é projetada para ser substituível ou configurável. Por exemplo, se quisermos usar um método customizado de resumir conversas, podemos criar nossa própria classe herdando de ConversationManager. Ou se quisermos conectar um modelo incomum, implementamos a interface de Model para ele. Essa arquitetura baseada em interfaces e classes de base é típica de frameworks Python bem desenhados, permitindo que o Strands atenda a casos de uso variados sem forçar um one-size-fits-all. Em resumo, a organização interna se parece a uma caixa de ferramentas bem compartimentada, onde o Agent junta as peças, mas cada peça pode ser examinada e trocada.

3. Integração Nativa com AWS (mas não limitada a ela): Por ser criado pela AWS, não surpreende que o Strands tenha integração suave com serviços AWS – por exemplo, Amazon Bedrock (serviço que hospeda modelos como Claude, Titan etc.) pode ser usado como provedor de modelos facilmente , e o AgentCore do Bedrock (um runtime gerenciado para agentes) é suportado nativamente para implantação. Há ferramentas pré-construídas para interagir com serviços AWS (como Amazon S3, DynamoDB, AWS Lambda, etc.) , facilitando criar agentes que automatizam tarefas na nuvem. Além disso, o projeto fornece blueprints de implantação em AWS (ex.: modelos de Lambda, Fargate, EKS, EC2 para rodar agentes) . Entretanto, é importante notar: o Strands é 100% open source (Apache 2.0) e multi-plataforma. Você pode executá-lo localmente ou em qualquer infraestrutura, e usar modelos de outros fornecedores (OpenAI, Cohere, ou modelos open-source locais) sem nenhum impedimento . Essa posição é estratégica: a AWS o propõe como um padrão aberto para agentes de IA, com suporte da comunidade (Meta, Anthropic, Accenture e outros já contribuíram com integrações ). Ou seja, é um projeto de comunidade, não um serviço proprietário – mas claramente é também parte da visão da AWS de promover Agentic AI de forma enterprise.

4. Observabilidade e Produtização: Um dos lemas do Strands é ser “pronto para produção” (production-ready). Isso se reflete em recursos robustos de observabilidade, como integração com OpenTelemetry (OTEL) para métricas, logs e tracing . Cada agente pode emitir métricas personalizadas (quantidade de iterações, ferramentas usadas, tempo de resposta, etc.) e rastrear as chamadas através de componentes distribuídos com traces correlacionados . Por exemplo, se um agente orquestrador aciona dois agentes especialistas em microserviços distintos, o Strands pode propagar um ID de trace para cada requisição, possibilitando visualizar numa ferramenta de monitoring todo o percurso daquela tarefa entre os serviços – algo essencial para depurar e otimizar sistemas complexos. Além disso, o Strands traz um SDK de avaliações (Strands Evals) com utilitários para avaliar desempenho de agentes (métricas como sucesso de objetivo, precisão de seleção de ferramenta, etc., listadas em sua documentação) . Isso demonstra a preocupação em não apenas construir agentes, mas também medir e melhorar eles continuamente em produção. Em termos de design, poucas soluções de agentes até então incorporavam observability de forma tão direta – aqui é um componente de primeira classe.

5. Segurança e Governança: Por fim, mas crucial, estão os recursos de segurança integrados. O Strands suporta plug-ins de conteúdo seguro e compliance, incluindo:

• Filtros de conteúdo indesejado ou sensível: Utilizando possivelmente modelos de detecção ou serviços externos, o agente pode bloquear ou alterar respostas que contenham informações proibidas (ex.: linguagem tóxica, vazamento de dados confidenciais).

• Guardrails (trilhos de segurança): Integra-se com Bedrock Guardrails ou políticas definidas para intervir se o agente estiver saindo do escopo ou violando alguma regra . Por exemplo, se o modelo tentar gerar código malicioso ou revelar segredos, um guardrail pode interromper a geração.

• Mascaramento de PII: Ferramentas automáticas para identificar e remover informações pessoais identificáveis de entradas/saídas, protegendo privacidade (na documentação há referência a PII Redaction).

• Autenticação de Ferramentas: Em cenários empresariais, ferramentas que acessam sistemas sensíveis (como bancos de dados internos) podem exigir credenciais; o Strands incentiva boas práticas de gerenciar chaves de API, tokens (como no exemplo do GitHub token para a ferramenta de verificação de domínio ), e permite integrar com sistemas de segredos da AWS (Secrets Manager, etc.).

Esses aspectos fazem parte do ethos de “enterprise-ready”, mencionado nos materiais do Strands: agentes autônomos porém “seguros por design” . Em outras palavras, não basta que o agente funcione; ele deve funcionar de forma governável, rastreável e segura para atender aos requisitos de aplicações reais nas empresas.

Posicionamento no Ecossistema Python

O surgimento do Strands Agents ocorre num momento de efervescência em torno de agentes de IA e ferramentas como o LangChain, GPT-Engineers, AutoGPT e outros experimentos. Cada uma dessas soluções ataca o problema à sua maneira, e é importante entender onde o Strands se encaixa nesse panorama:

• Comparado ao LangChain e similares: LangChain ganhou popularidade ao oferecer uma forma de encadear prompts e integrar ferramentas em aplicações de LLM, incluindo agentes baseados no padrão ReAct. No entanto, LangChain é bastante genérico e muitas vezes demanda que o desenvolvedor configure explicitamente cadeias de chamadas, parse de saída do modelo, etc. O Strands, por sua vez, assume uma filosofia quase oposta: em vez de o desenvolvedor orquestrar a lógica passo a passo, o modelo de IA é que orquestra, e o framework apenas dá o suporte (memória, ferramentas, execução) para que isso ocorra de modo confiável . Isso simplifica o desenvolvimento – como diz a apresentação, “basta definir um prompt e uma lista de ferramentas” que o Strands cuida do resto – mas ao mesmo tempo exige modelos capazes nessa função. Assim, podemos ver o Strands mais como um nível de abstração acima: ele se apoia em melhorias dos LLMs (ex.: capacidade de function calling) para evitar escrever código de parsing, loops manualmente. Em termos de código Python, Strands tende a ser mais declarativo e menos imperativo que LangChain.

• Integração com o ecossistema AWS e open-source: Um ponto de destaque é que o Strands vem respaldado pela AWS, o que o torna atraente para desenvolvedores já atuando nesse ecossistema. Por exemplo, se você quer levar seu protótipo de agente para produção na AWS, o Strands já provê modelos de implantação (Lambda, contêineres) e compatibilidade com serviços gerenciados (Bedrock, etc.) . Nenhum outro framework de agentes no Python até o momento oferece essa “mão na roda” tão pronta para deploy. Ao mesmo tempo, por ser open-source e ter um GitHub ativo, ele busca envolver a comunidade de forma mais aberta do que soluções puramente proprietárias. Empresas e indivíduos podem contribuir com pull requests, adicionar conectores para novos LLMs ou criar pacotes de ferramentas comunitárias (e isso já está acontecendo, vide contribuições da Anthropic, Meta, etc. para suporte às APIs deles ). Em suma, o Strands tenta unir o melhor dos dois mundos: robustez de empresa grande + abertura da comunidade.

• Casos de Uso Alvo: Pelo posicionamento do projeto, fica claro que o Strands mira tanto assistentes conversacionais complexos (por exemplo, um ajudante de desenvolvedor como o Amazon Q que motivou sua criação ) quanto agentes de automação de tarefas em TI e negócios (como analisar logs, gerenciar infraestrutura – há menções de uso no AWS Glue, VPC Reachability Analyzer ). Ou seja, muito além de responder perguntas, a ideia é habilitar agentes que realmente executem fluxos de trabalho e economizem tempo humano em operações. Isso o distingue de bibliotecas focadas apenas em chatbots simples. Dentro do ecossistema Python, o Strands também dialoga com projetos de Autonomous AI Agents que surgiram pós-GPT-4 (Auto-GPT, BabyAGI etc.), mas esses projetos eram mais demonstrações pontuais. O Strands busca ser uma base consolidada e de longo prazo para desenvolver tais agentes com qualidade de software industrial.

Em resumo, o Strands Agents se posiciona como o framework de referência da AWS para agentes LLM – leve, flexível, integrável e pensado para escalar. Ele não invalida o uso de outras bibliotecas (inclusive pode ser usado em conjunto, por exemplo, utilizando LangChain para gerenciar documentos mas Strands para orquestrar agentes, se alguém quiser), mas certamente traz uma proposta de design mais coesa para agentes autônomos em Python. Para quem já está no ecossistema Python de IA, vale a pena acompanhar e experimentar o Strands, pois ele representa uma evolução das lições aprendidas ao longo de 2023 na construção de agentes – incorporando essas lições em um pacote bem arquitetado.

Conclusão

O Strands Agents exemplifica como projetos de código aberto podem elevar o nível de abstração no desenvolvimento de sistemas de IA. Ao invés de reinvertermos a roda a cada novo agente, ele fornece um framework sólido que cuida da base: um loop de agente confiável, integração transparente com modelos e ferramentas, memória gerenciada, padrões multiagente e toda infraestrutura de observabilidade e segurança necessária para implantar agentes no mundo real. A metáfora no nome “Strands” (fios/fitas) remete às duas peças-chave que ele conecta – modelo e ferramentas – como as duas fitas do DNA . E de fato, o DNA deste framework é permitir que modelos de linguagem façam mais do que conversar: que possam agir.

Para a comunidade Python, especialmente desenvolvedores interessados em Agentic AI, o Strands chega para ocupar um espaço importante. Com ele, pode-se ir do protótipo à produção em questão de dias ou semanas, ao invés de meses , graças às decisões de projeto que simplificam a vida do desenvolvedor (aproveitando o que os modelos já conseguem fazer) e ao mesmo tempo fornecem os ganchos necessários para casos avançados.

Estou criando alguns agentes usando o framework e em breve posto mais sobre a minha experiência e meus aprendizados.