No Cubo, o Agent Speedrun expôs a infraestrutura por trás de um agente utilizável

Na sexta-feira, 17 de abril de 2026, participei do Agent Speedrun: de horas para minutos, no Cubo Itaú, em São Paulo. O encontro foi organizado por Eduardo “Dug” Hilpert e conduzido por Vitor Guimarães e Lucas Nunes, da DNX Brasil. A promessa do título era velocidade. O ponto mais interessante, porém, apareceu em outro lugar: na infraestrutura que torna um agente utilizável fora da demo.

Ao longo do workshop, a stack da Amazon Bedrock foi apresentada menos como vitrine de modelos e mais como um arranjo operacional para agentes: ferramentas, memória, políticas, runtime, guardrails e observabilidade. A intuição geral era simples. O que faz um agente sair do campo da curiosidade e entrar no da utilidade não é apenas a LLM; é o conjunto de restrições e capacidades ao redor dela.

Dois speedruns, uma tese

Na prática, isso apareceu em dois labs do workshop Create an Agent. O ritmo de speedrun não vinha de escrever um agente do zero em poucas horas. Os scripts já estavam preparados. O que fizemos foi percorrer esses blocos, executar etapas e observar os resultados. No Lab 01, isso significou acompanhar um agente de suporte ao cliente com custom tools, busca web, base de conhecimento e um prompt de sistema suficientemente organizado para coordenar essas peças. No Lab 02, ver esse mesmo agente ganhar AgentCore Memory: memória de curto prazo, memória de longo prazo e recuperação semântica de interações anteriores.

Essa sequência foi didática porque deslocou o problema. A pergunta deixou de ser “como fazer a IA responder?” e passou a ser “como fazer esse agente lembrar, agir e operar com alguma confiabilidade?”. O speedrun estava no modo de aprender, não no ato de programar. Ainda assim, a estrutura apresentada ali permite uma inferência importante: quando memória, runtime, identidade, guardrails, observabilidade e integração com tools já aparecem como fundação, a construção de agentes tende de fato a se acelerar.

O que apareceu com mais clareza

O workshop insistiu em alguns pontos que me pareceram mais importantes do que o discurso usual sobre “IA mais poderosa”. Um agente útil precisa de memória para não recomeçar do zero, de tools para sair da superfície do texto, de políticas e identidade para não acessar tudo o que pode, e de guardrails para não se desviar do escopo quando encontra inputs ambíguos ou maliciosos. Em outras palavras: precisa de arcabouço.

Esse ponto ficou ainda mais nítido nos exemplos de atendimento e nos alertas sobre prompt attack, exposição indevida de dados e risco reputacional. A mensagem era quase anti-hype: antes de pensar no brilho da interface, vale pensar em contenção, rastreabilidade e custo. Talvez seja justamente aí que comece uma engenharia de agentes mais séria.

Kiro entrou como sintoma de uma mudança maior

Foi também nesse contexto que achei interessante conhecer o Kiro, a partir do compartilhamento do Vitor. O que chamou atenção não foi apenas a ideia de um fork do VS Code com IA. Foi o fato de ele aparecer como parte de uma mesma família de ferramentas que tentam organizar melhor a relação entre modelo, contexto, ferramentas, memória e fluxo de execução.

Saí do Cubo com uma impressão parecida à que tive em outros encontros recentes sobre IA: o centro de gravidade está mudando. Menos fascínio por um chat “que responde tudo”, mais interesse por ambientes e arquiteturas que disciplinam como essa resposta é produzida. Se essa hipótese estiver correta, o próximo diferencial competitivo não será só o modelo. Será o modo como cada stack monta o seu próprio harness.

Sobre o autor

Bolívar Alencastro

Product Designer em São Paulo, escrevendo sobre produto, interfaces e, cada vez mais, sobre o tipo de estrutura que faz agentes parecerem menos truque de palco e mais software de verdade.

• LinkedIn
• Instagram