Antes de contratar um agente de IA, descubra se a sua empresa sabe dizer o que quer
21 de setembro de 2026 · 8 min de leitura

Antes de contratar um agente de IA, descubra se a sua empresa sabe dizer o que quer
Um experimento de Will Larson com agentes que perseguem objetivos, e não tarefas, produziu um achado lateral mais útil que o próprio experimento: o agente só consegue trabalhar depois que alguém escreve o objetivo. A maioria das empresas nunca escreveu.
No dia 20 de setembro, Will Larson, CTO da Imprint e autor de livros sobre liderança de engenharia, publicou o relato de um experimento interno em Trying the software factory pattern. A ideia é fácil de descrever e difícil de executar: em vez de entregar tarefas a um agente de inteligência artificial, ele passou a entregar objetivos de projeto e deixou o agente rodar em loop.
O nome do padrão não é dele. Larson registra no próprio texto que a origem do termo no contexto de IA é confusa de atribuir, e aponta como provável origem um texto de fevereiro de 2026 assinado por Justin McCarthy, Software Factories And The Agentic Moment.
A implementação é uma skill de agente chamada /linear-project-loop. Ela lê um projeto no Linear, o sistema de gestão de tarefas da empresa, e começa auditando a definição de objetivo daquele projeto: existe um documento descrevendo a meta, como ela é medida e quais painéis acompanham a medição? Só depois disso ela revisa o estado das métricas e das tarefas, atualiza o que mudou, adiciona o que falta, executa as tarefas não bloqueadas e segue para a próxima quando uma se completa, reciclando a descrição do projeto quando ela já não está atualizada.
Larson avalia o resultado em uma frase deliberadamente modesta. Segundo ele, o padrão está rodando na máquina dele, mas "funcionando bem o suficiente" para que pretenda mover o comportamento para o mesmo ambiente orquestrado que já executa seus outros agentes sem supervisão contínua.
Não há número. Não há comparação. É a avaliação subjetiva do autor sobre o próprio experimento.
E é exatamente por isso que a parte mais útil do relato está em outro lugar.
O achado está na primeira etapa, não na última
O trecho mais interessante do texto é uma observação de passagem. Larson escreve que já vinha pedindo aos agentes que iterassem sobre projetos específicos do Linear, mas que eles não tinham como avaliar se estavam indo na direção certa, nem como identificar se alguma tarefa necessária estava faltando. Agora têm.
A frase é sobre capacidade do agente. A leitura que me interessa é sobre a empresa.
Para o agente conseguir avaliar direção de progresso, alguém precisou escrever qual era a direção. Para identificar tarefa ausente, alguém precisou definir o que significa "completo". O agente não descobriu isso sozinho. Ele foi obrigado a ler uma definição que, para existir, teve que ser escrita.
A leitura mais plausível é que o agente funcionou como auditor da definição antes de funcionar como executor. Isso é inferência minha, não conclusão do texto original, mas se apoia na própria ordem das etapas descritas: auditar o objetivo é o passo um, executar tarefa é o passo três.
Três pré-requisitos, traduzidos para consequência prática
Larson é explícito sobre as dependências do padrão. Ele cita o acesso do agente ao Datadog, ferramenta de monitoramento, e ao Snowflake, banco de dados analítico, por meio de MCP, o protocolo que permite a um agente consultar um sistema externo diretamente. Cita também o Linear como fonte única de estado do trabalho da empresa, e um ambiente orquestrado capaz de executar trabalho de forma independente do laptop dele.
Traduzido para o que isso significa na prática, sem jargão:
Primeiro, a métrica precisa ser legível por máquina. Não basta existir um indicador. O agente precisa conseguir consultar o número sozinho, na origem, sem depender de alguém exportar uma planilha na sexta-feira.
Segundo, precisa existir uma única fonte de estado. Um lugar, e só um, que responde o que está em andamento, o que está bloqueado e o que já terminou. Se a resposta mora parcialmente no Jira, parcialmente no e-mail e parcialmente na cabeça de três pessoas, não existe estado. Existe opinião distribuída.
Terceiro, precisa existir um ambiente que roda sem supervisão contínua. Um processo que continua trabalhando quando ninguém está olhando a tela.
Larson fecha esse ponto com uma frase que vale mais do que a maior parte do que se escreve sobre adoção de IA: todas as peças só compõem na medida em que você tem as outras peças. Não é uma restrição técnica. É uma restrição de organização.
Objetivo legível por máquina como teste de maturidade
Aqui está a tese, e ela é minha, não do texto original.
Um agente que trabalha por objetivo é um teste de maturidade de gestão disfarçado de ferramenta. Se a empresa não consegue descrever um objetivo de forma que uma máquina consiga executá-lo, é bem provável que nunca o tenha descrito de forma que uma pessoa conseguisse.
O padrão que se vê repetir na maioria das empresas de serviço é sempre o mesmo. Objetivo em slide. Métrica em planilha que alguém atualiza quando lembra. Estado do trabalho espalhado entre sistema de chamado, e-mail, grupo de WhatsApp e reunião de segunda. Nenhuma dessas três coisas é um problema de modelo de IA. Nenhuma se resolve com orçamento de software.
Isso reposiciona o investimento. A barreira de adoção de agentes, para a empresa média, não é o modelo nem o preço do token. É a ausência de objetivo escrito com métrica associada e de uma fonte única que diga onde o trabalho está.
É uma afirmação testável, e barata de testar. Pegue um projeto em andamento na sua empresa e responda três perguntas por escrito, sem consultar ninguém: qual é o objetivo, qual número diz se ele foi atingido, e onde esse número mora. Se a resposta exigir uma reunião, o problema não é o agente.
O que o experimento não prova
Vale ser rigoroso com o que está sendo relatado, porque o risco de leitura apressada aqui é alto.
É um caso único. Não há métrica de desempenho reportada. Não há comparação com o método anterior, nem tempo economizado, nem taxa de erro. "Funcionando bem o suficiente" é avaliação declarada pelo autor, não resultado medido por terceiro.
Além disso, a stack em que o experimento roda está muito acima da média do mercado. O próprio texto descreve uma sequência de mudanças ao longo de 2026: colocar toda a engenharia usando agentes diariamente, depois estender isso ao restante da empresa, reorganizar o ambiente de desenvolvimento em workspaces com checkout independente de todos os repositórios, migrar a empresa inteira de Jira para Linear, e só então implantar o harness orquestrado que chamam internamente de Agent Fleet.
O experimento é o último degrau de uma escada que quase ninguém subiu. Usá-lo como evidência de ganho de produtividade é ler no texto algo que não está escrito. O que ele oferece é uma hipótese bem formulada, com as dependências declaradas de forma honesta.
Há ainda um risco que o relato não trata: agente rodando em loop contínuo sem métrica clara otimiza atividade, não resultado. Ele vai gerar tarefa, fechar tarefa e produzir movimento — e movimento é fácil de confundir com progresso quando ninguém definiu o número que importa. Larson descreve um uso que evita essa armadilha, o de monitoramento pós-lançamento: se a adoção disparar ou a taxa de erro começar a virar, ele poderia não perceber, mas rodar a fábrica em modo pós-release pegaria isso imediatamente. Repare que esse uso só funciona porque a métrica existe e é consultável.
O investimento que vem antes do investimento
A conclusão prática é menos glamourosa que a manchete.
Antes de contratar agente, arrumar a fonte de estado. Escolher um sistema para o trabalho morar, escrever o objetivo de cada projeto em um parágrafo, e apontar onde está o número que diz se ele foi atingido. Isso não depende de fornecedor, não exige contrato novo e pode começar em uma semana com as ferramentas que a empresa já paga.
É o tipo de trabalho que no dia a dia da ASTX aparece disfarçado de projeto de tecnologia e termina sendo projeto de definição. E é o trabalho que, feito ou não, decide se o agente vai ter o que perseguir.
Quatro perguntas para levar à próxima reunião de projeto:
Qual é o objetivo deste projeto, em uma frase, por escrito?
Qual número diz que ele foi atingido, e quem consegue consultar esse número sem pedir para alguém?
Qual sistema é a resposta final sobre o estado do trabalho, quando dois sistemas discordarem?
O que ainda está definido apenas na conversa e nunca foi escrito?
Se as quatro respostas existirem, a conversa sobre agentes pode começar. Se não existirem, o problema nunca foi a inteligência artificial.


