A maioria dos desenvolvedores que trabalham com inteligência artificial hoje consegue fazer um modelo responder a uma solicitação. No entanto, poucos conseguiram lançar um agente que funcione de forma estável em um ambiente de produção. O problema que atrasa a maioria dos projetos de agentes reside em frameworks que restringem abstrações, sistemas que funcionam como caixas pretas ao ocorrerem erros e requisitos de prontidão empresarial em constante crescimento.
Ashita Prasad, desenvolvedora advogada na AWS, resolveu esse problema durante um workshop prático de duas horas no DevSparks Bengaluru 2026. Durante este evento, 170 desenvolvedores trabalharam com ela usando o Strands Agents — um SDK aberto desenvolvido pela AWS. A sessão permitiu aos participantes criar um agente básico e, em seguida, aprimorá-lo para uma versão com mecanismos de proteção (guardrails) integrados, memória persistente e capacidades de observabilidade.
Antes de começar a codificar, Ashita destacou três aspectos do problema. Primeiro, existe uma curva de aprendizado acentuada entre a compreensão dos conceitos de agentes e sua implementação real. Segundo, a maioria dos frameworks sacrifica a flexibilidade em prol da conveniência, o que se torna problemático na escalabilidade. Terceiro, e este é o mais crítico, os sistemas permanecem opacos. Ela observou que o usuário não sabe o que exatamente o agente está fazendo nos bastidores, quais chamadas de ferramentas ele executa ou quais mensagens envia, o que o transforma em uma caixa preta e dificulta o desenvolvimento e a manutenção.
O Strands Agents utiliza uma abordagem baseada em modelo, permitindo que o modelo de linguagem básico decida dinamicamente se deve chamar uma ferramenta, retornar uma resposta ou continuar raciocinando, enquanto revela completamente o ciclo de trabalho do agente ao desenvolvedor. Este ciclo é simples: uma solicitação do usuário chega, o modelo determina o próximo passo, as ferramentas são chamadas se necessário, os resultados são retornados ao modelo e, finalmente, a resposta final é formada. O Strands assume toda a infraestrutura necessária entre essas etapas.
O workshop foi realizado através de uma série de laboratórios, cada um adicionando nova funcionalidade ao agente em desenvolvimento. Tudo começou com um agente mínimo: modelo, prompt do sistema e solicitação do usuário. Em seguida, os participantes adicionaram ferramentas, começando com uma função de clima própria e depois ferramentas comunitárias prontas, como uma calculadora, incluídas no Strands.
O laboratório com provedor de modelos apresentou o Ollama, permitindo que os desenvolvedores executassem grandes modelos de linguagem localmente, o que é importante para aqueles que não têm acesso a uma assinatura de modelo em nuvem. Os participantes construíram um agente para trabalhar com arquivos usando o modelo local Llama 3.2, que podia ler, listar e gravar arquivos em diretórios, demonstrando que a arquitetura Strands é universal independentemente da localização do modelo.
O laboratório com serviços AWS aumentou significativamente a complexidade. Os participantes criaram um agente para reserva de restaurantes que sabia criar, obter e excluir registros de reserva armazenados no DynamoDB, além de extrair informações sobre restaurantes do Knowledge Base do Amazon Bedrock, indexado no OpenSearch Serverless.
Ashita enfatizou um ponto arquitetônico importante: operações padrão, como gravação em banco de dados, não exigem um processo de raciocínio por parte do agente. Ela explicou que criar uma reserva é semelhante a gravar em um banco de dados, sem ambiguidade. Saber quando não usar um LLM é tão importante quanto saber quando usá-lo.
O laboratório com ferramentas MCP cobriu ambos os mecanismos de transmissão de dados: entrada/saída padrão para servidores locais e HTTP streaming para remotos, além de mostrar a possibilidade de conectar vários servidores MCP simultaneamente. Isso foi seguido por um laboratório de streaming, que abordou iteradores assíncronos e manipuladores de callback como duas formas complementares de informar os usuários durante o longo funcionamento do agente.
Os dois últimos laboratórios trataram do que diferencia uma demonstração em um workshop de um produto pronto para implantação. No laboratório de guardrails, foi usado o Amazon Bedrock Guardrails para configurar bloqueios em nível de tópico, filtros de conteúdo para categorias como violência, detecção de ataques de prompt e acionamento por palavras específicas. Mensagens de resposta personalizáveis foram previstas para entradas e saídas bloqueadas. Um exemplo específico de uso era que um agente com acesso ao banco de dados de clientes nunca deveria divulgar informações de identificação pessoal (PII), como números Aadhaar ou PAN, independentemente da formulação da solicitação.
O laboratório de memória resolveu outro problema de produção. Embora os agentes Strands salvem o histórico de conversas por padrão dentro de uma sessão, essa memória desaparece após o término da sessão. Usando Mem0 e OpenSearch Serverless, os participantes aprenderam a salvar preferências e contexto do usuário entre sessões, para que o agente se lembrasse do interlocutor no próximo contato.
Em conjunto, esses dois laboratórios refletiram um princípio de design unificado que permeou todo o workshop: a prontidão para produção não é uma função que se adiciona no final. Observabilidade, segurança e memória são decisões arquitetônicas que devem ser tomadas desde o início.
O código-fonte completo está disponível no GitHub no repositório Strands Agents Samples, e cada laboratório pode ser executado localmente usando o Ollama para desenvolvedores que não possuem um provedor de modelos em nuvem. O mesmo repositório apresenta laboratórios multiagentes, abrangendo enxames e grafos de agentes, para aqueles que desejam se aprofundar no assunto.
O workshop terminou com um lembrete sobre a necessidade de limpar recursos para aqueles que realizaram os laboratórios em suas próprias contas AWS, o que foi um conselho útil para o público-alvo.
