O que o DevDay Exchange mostrou sobre colocar agentes para trabalhar
Em São Paulo, mais de 500 participantes, cases de QuintoAndar e iFood e pessoas estratégicas do time global da OpenAI deram escala a uma conversa sobre como criar, coordenar e avaliar trabalho com IA.

Em 6 de novembro, acompanhei o OpenAI DevDay Exchange em São Paulo. Como Codex Ambassador, estive entre os 11 embaixadores da OpenAI no Brasil que participaram do encontro. Foram mais de 500 pessoas, incluindo profissionais de algumas das maiores empresas do país, com uma presença forte do time global da OpenAI.
A programação combinou sessões técnicas, demonstrações, cases de QuintoAndar e iFood e conversas com especialistas da empresa. São Paulo foi uma das oito cidades do circuito internacional, que aproxima desenvolvedores e founders das equipes que constroem os produtos da OpenAI.
Para mim, o fio que conectou as apresentações foi como organizar o trabalho quando os agentes conseguem executar tarefas cada vez mais longas. Que contexto eles precisam receber? Como dividir as responsabilidades? Quem verifica a entrega? E como acompanhar o que aconteceu quando algo sai diferente do esperado?
Essas perguntas já interessam a quem lidera produto, engenharia ou uma área de negócio. Quanto mais a IA consegue fazer, mais importante fica decidir o que vale a pena delegar e como reconhecer uma entrega boa.
O trabalho continua depois da primeira resposta
Uma das sessões tinha o título “O que vem depois dos loops?”. A conversa passou pela estrutura que mantém um agente trabalhando ao longo de uma tarefa.
O modelo precisa receber contexto, escolher ferramentas, examinar os resultados e decidir como continuar. Ao longo desse caminho, produz arquivos, descobre restrições e toma decisões. Esse conjunto de mecanismos costuma ser chamado de harness.
Imagine uma investigação sobre uma falha em um produto. O agente consulta registros, encontra uma hipótese, lê o código e executa um teste. O resultado pode descartar a primeira hipótese e exigir outro caminho. Para continuar, ele precisa preservar o que já aprendeu e lembrar qual problema estava tentando resolver.
Uma apresentação pode mostrar o resultado final desse processo. Na operação, o que importa é conseguir percorrer o caminho, lidar com um bloqueio e verificar se o objetivo foi alcançado.
A sessão “Harness-as-a-Service com a Agents API” também estava na programação. A proposta da API, anunciada pela OpenAI antes do encontro, é oferecer essa camada de execução gerenciada. Para quem constrói, isso permite concentrar mais esforço nos dados, nas ferramentas e nos fluxos específicos do cliente.
Minha leitura é que a diferenciação de uma startup de IA vai depender cada vez mais de conhecer esse trabalho em detalhe. Duas empresas podem usar o mesmo modelo e entregar resultados muito diferentes porque uma delas entende melhor as exceções, as fontes de informação e o critério de conclusão do cliente.
Um prompt também pode organizar uma equipe

Um dos slides que mais me chamou atenção mostrava instruções para dividir trabalho entre subagentes. A orientação era abrir frentes independentes, definir resultados e responsabilidades, comunicar dependências e integrar a entrega ao final.
Esse tipo de instrução revela uma mudança na forma de trabalhar com IA. Quando há várias frentes em paralelo, alguém precisa dizer como elas se encontram.
Pense em uma aplicação com uma pessoa cuidando da interface, outra da integração e outra dos testes. Se a integração muda o formato dos dados e essa decisão não chega a quem está construindo a interface, as partes podem ficar prontas e ainda assim falhar juntas. Com agentes, a dependência continua existindo.
Outro slide tratava de manter um registro da meta, das instruções, dos responsáveis, das pendências e das decisões. Em tarefas longas, esse registro ajuda a retomar o trabalho sem perder as condições que orientaram as primeiras escolhas.
Isso conversa com algo que venho defendendo nas nossas atividades de IA na NewHack. Antes de sair pedindo implementação, vale explicitar o que queremos construir. Quando a execução acelera, uma especificação ambígua pode gerar mais retrabalho em menos tempo.
A consequência prática é dedicar atenção ao início e ao fim da tarefa. No início, definir o resultado e as restrições. No fim, verificar se a solução atende àquilo que foi combinado. Entre esses dois pontos, o agente pode ganhar espaço para investigar e propor caminhos.
A próxima aplicação pode começar em uma planilha
Na sessão sobre Sites e a próxima geração de aplicações web, uma demonstração partiu de uma planilha para criar uma aplicação de acompanhamento de lançamentos. O pedido incluía um sistema visual já existente, marcos, filtros e formas diferentes de visualizar o trabalho.
É um exemplo próximo de muita empresa. Uma planilha reúne as informações, mas o time precisa de uma experiência melhor para consultar, acompanhar e agir sobre elas. A possibilidade de construir essa aplicação com IA reduz o esforço para testar se ela resolve o problema.
A discussão também passou por aplicações preparadas para interagir com agentes. Parte dos usuários poderá chegar a um serviço acompanhada de uma IA que busca informações e executa ações em seu nome.
Para quem empreende, isso amplia as perguntas de produto. Além de pensar em como uma pessoa encontra uma função na tela, passa a importar como essa função é apresentada a um agente, quais ações ela permite e como confirma o resultado. A experiência precisa continuar compreensível e controlável ao longo desse percurso.
Segurança entra na forma de delegar
A programação reservou uma sessão a “Codex Security: da vulnerabilidade à correção verificada”. No painel com especialistas, uma pergunta trouxe o assunto para a rotina das empresas. Quais controles adotar antes de permitir que um agente acesse sistemas internos ou altere código?
Um exemplo discutido foi o acesso a um sistema de chamados. Se a tarefa exige apenas consultar tickets, a credencial pode se limitar à leitura. A discussão incluiu testar o comportamento em um ambiente controlado, acompanhar a execução e definir quando uma pessoa precisa aprovar a ação.
O valor dessa abordagem aparece quando algo dá errado. A equipe precisa conseguir reconstruir quais informações o agente recebeu, que ferramentas usou e onde tomou uma decisão que merece revisão.

No painel também surgiu o modelo hub and spoke. Um núcleo técnico estabelece padrões e orienta a arquitetura, enquanto pessoas de diferentes áreas ajudam a identificar usos e disseminar conhecimento.
Vejo sentido nessa proposta porque os melhores problemas para resolver estão espalhados pela empresa. O time de atendimento conhece as exceções do cliente. O financeiro sabe onde o fechamento trava. A engenharia entende as dependências dos sistemas. Criar uma forma de essas pessoas experimentarem com apoio técnico pode transformar curiosidade em projetos que a organização consegue acompanhar.
Os cases brasileiros colocam a discussão perto de casa
Ter QuintoAndar e iFood no bloco de clientes trouxe uma referência brasileira para o encontro. São empresas que operam jornadas complexas, com decisões, integrações e pessoas distribuídas por várias etapas.
Para quem estava na plateia, isso ajuda a formular perguntas sobre o próprio negócio. Onde a informação se perde entre duas áreas? Qual tarefa ocupa horas de alguém que conhece profundamente o processo? O que pode ser testado sem comprometer a operação?
A presença de pessoas estratégicas do time global da OpenAI também cria uma oportunidade de levar essas dificuldades para quem constrói as ferramentas. A experiência de colocar IA para trabalhar no Brasil tem suas próprias condições, seus sistemas existentes e seus usuários. Esse retorno faz parte da troca que dá nome ao evento.
O que eu levaria para o próximo projeto
No warmup que fizemos com Marcelo Okano na NewHack, a conversa já passava pelo que muda quando implementar fica mais rápido. O DevDay Exchange deu mais material para essa discussão.
Eu começaria escolhendo um trabalho recorrente, com um responsável capaz de dizer o que significa uma boa entrega. Registraria o objetivo, as fontes e as decisões que precisam continuar disponíveis. Depois, daria ao agente as ferramentas e os acessos necessários para testar aquele fluxo.
Mediria o resultado incluindo o esforço de revisão e o tratamento das exceções. É essa evidência que permite decidir se vale ampliar a autonomia, mudar o desenho ou tentar outro caso.
Saí do encontro com mais interesse nesse trabalho de construção. Escolher o problema, especificar, experimentar, verificar e compartilhar o que aprendemos. A capacidade dos agentes está avançando rápido. Saber organizar esse trabalho é uma competência que já podemos desenvolver.
