Factory Droid 1.0: por que o harness pode definir a eficiência dos agentes de código

O Factory Droid 1.0 é um “harness” de agentes de programação: uma camada que organiza contexto, ferramentas, execução e validação ao redor de modelos de linguagem. Em 29 de outubro de 2026, a empresa Factory apresentou a primeira versão estável do produto e defendeu uma tese relevante para equipes de software: ganhar desempenho em tarefas de engenharia não depende apenas de trocar de modelo; depende também de reduzir chamadas desnecessárias ao modelo e de controlar como ferramentas são usadas.

A principal novidade é o Script mode, uma implementação de programmatic tool calling (PTC). Em vez de o modelo alternar repetidamente entre “pensar”, chamar uma ferramenta e receber cada resultado no próprio contexto, o Droid permite que o modelo escreva um programa JavaScript em sandbox para orquestrar várias chamadas. A promessa é diminuir latência, custo e perda de informação em tarefas longas, como manutenção de código, triagem de CI e mudanças repetitivas em sistemas de gestão.

Resumo: o que a Factory anunciou

• O Droid 1.0 é apresentado como uma versão estável de um ambiente de execução para agentes de código, não como um modelo de IA próprio.
• O produto usa Script mode para agrupar chamadas de ferramentas e manter resultados brutos fora da janela de contexto do modelo.
• A Factory divulgou medições próprias no Terminal-Bench 4 e comparações com ferramentas como Codex, Claude Code, Cursor, Devin e OpenCode.
• A empresa também afirma ter reduzido em 37% os tokens de entrada da primeira requisição entre versões recentes do Droid, sobretudo ao carregar ferramentas sob demanda.
• Os números comparativos são da própria Factory; eles ajudam a entender o desenho técnico, mas não substituem uma avaliação independente no ambiente de cada equipe.

O que é um harness de agentes de programação

Um modelo de linguagem pode gerar código, mas um agente de programação útil precisa de muito mais: ler arquivos, pesquisar no repositório, executar testes, editar trechos, consultar serviços externos e verificar o resultado. O harness é a camada de software que decide quais ferramentas ficam disponíveis, como o histórico é entregue ao modelo, quando uma tarefa deve ser dividida e como os resultados retornam para a próxima etapa.

Isso importa porque o custo e a confiabilidade de um agente não são definidos só pelo modelo escolhido. Cada ida e volta para o modelo repete instruções, parte do histórico e definições de ferramentas. Em uma tarefa com muitas ações independentes — por exemplo, checar dezenas de execuções de CI ou atualizar uma lista grande de tickets — essa repetição pode ocupar mais contexto do que a informação realmente necessária para decidir o próximo passo.

Como funciona o Script mode do Droid

Segundo a documentação de lançamento da Factory, o modelo escreve JavaScript para um ambiente isolado. Esse programa não recebe acesso direto à rede, ao sistema ou aos arquivos; ele usa as ferramentas expostas pelo próprio Droid. O programa pode chamar ferramentas, armazenar resultados em variáveis, aplicar filtros, repetir operações e imprimir apenas um resumo para o modelo.

Na prática, o padrão tenta trocar uma sequência longa de ciclos “modelo → ferramenta → modelo” por menos ciclos de modelo e mais trabalho determinístico dentro do script. Resultados volumosos — logs, arquivos e buscas — permanecem registrados para consulta posterior, em vez de serem todos anexados à conversa. A Factory também informa que chamadas sem dependência entre si podem rodar em paralelo.

Há uma distinção importante: PTC não torna o modelo automaticamente mais inteligente. Ele muda a arquitetura da execução. Os ganhos esperados aparecem quando a tarefa tem repetição, lotes de ações, resultados extensos ou verificações que podem ser expressas de forma determinística. Em uma alteração pequena e altamente criativa, o custo de escrever e revisar um script pode não compensar.

Os números divulgados e o que eles significam

A Factory publicou comparações no Terminal-Bench 4. Em sua configuração com GPT-6.1 Sol, o Droid teria alcançado 57,6% de taxa de sucesso a US$ 0,79 por tarefa aprovada; com Claude Opus 5.5, a empresa reporta 65,2% a US$ 4,73 por tarefa aprovada. O texto compara esses resultados com outros harnesses, mas a metodologia, os prompts, a infraestrutura, as versões de cada produto e os limites de ferramenta afetam diretamente esse tipo de tabela.

O dado mais transferível para outras equipes não é a posição no ranking, e sim a economia de contexto. A Factory afirma que reduziu a primeira requisição do Droid de 20.887 para 13.055 tokens entre as versões 0.170.0 e 0.250.0 — queda de 37%. A empresa atribui boa parte da diferença a enviar duas definições de ferramentas no início, em vez de 11, carregando recursos menos usados sob demanda. Como as versões comparadas usaram modelos diferentes, a própria Factory também apresenta uma comparação em caracteres e registra redução de 35%.

Em outro exemplo interno, a empresa descreve uma tarefa de mover 151 itens no Linear e confirmar que apenas o status foi alterado. A operação exigiu 312 chamadas de ferramenta. A estimativa da Factory é que uma execução direta precisaria de 36 chamadas ao modelo, mesmo agrupando dez ferramentas por requisição, enquanto um script usou duas chamadas ao modelo e cerca de 61 mil tokens de entrada. É um bom exemplo de onde a programação da orquestração pode ser mais eficiente do que pedir ao modelo para supervisionar cada microetapa.

Onde esse desenho pode ajudar equipes brasileiras

Para empresas brasileiras, o efeito mais concreto está em fluxos em que custo por token e tempo de espera impedem a adoção de agentes em escala. Revisar centenas de falhas de pipeline, aplicar uma alteração padronizada em múltiplos serviços, auditar permissões ou consolidar resultados de testes são tarefas candidatas. Se as ferramentas usadas pela equipe já oferecem APIs e saídas estruturadas, um programa intermediário pode reduzir o material que chega ao modelo e deixar a etapa repetitiva mais auditável.

Também há um benefício operacional: verificações, contagens e loops podem ficar no código do script, onde o comportamento é reproduzível. O modelo continua definindo a estratégia, mas não precisa improvisar a repetição de cada passo. Esse desenho tende a ser especialmente útil quando uma falha parcial precisa ser registrada e retomada sem que o agente confunda resultados antigos com novos.

Limitações e riscos que permanecem

• Benchmark não é implantação: resultados divulgados por um fornecedor são evidência inicial, não garantia de desempenho em repositórios privados, linguagens específicas ou políticas corporativas.
• Scripts aumentam a superfície de revisão: um programa que chama ferramentas em lote pode propagar um erro com rapidez. Sandbox, permissões mínimas, limites de gasto e confirmação humana continuam necessários.
• Menos contexto não pode significar menos controle: resumir demais logs ou resultados pode esconder uma exceção relevante. A possibilidade de recuperar o registro completo é parte crítica da arquitetura.
• Compatibilidade depende do modelo: a Factory afirma ajustar prompts e descrições de ferramentas por modelo. Assim, trocar o provedor pode alterar custo, formato de chamadas e qualidade final.

Análise do NoticIA: o diferencial está migrando para a camada de execução

Na análise do NoticIA, o lançamento é relevante menos por anunciar um novo agente de código e mais por explicitar uma mudança de foco. Conforme modelos de ponta ficam próximos em capacidades gerais, a diferença prática entre produtos passa a depender da engenharia que controla contexto, ferramentas, permissões e validação. O harness vira um componente de produto e de infraestrutura, não um detalhe invisível.

O Script mode ilustra essa mudança: ele tenta reservar o modelo para decisões de alto nível e delegar repetição, filtragem e paralelismo ao código. Isso pode reduzir custo e tempo, mas também exige disciplina de engenharia tradicional — observabilidade, testes, trilhas de auditoria e limites de execução. Para uma organização, o critério não deve ser apenas “qual agente vence o benchmark”, e sim “qual arquitetura deixa o trabalho automatizado verificável, reversível e compatível com os dados da empresa”.

O que observar a partir de agora

O próximo teste para ferramentas desse tipo será mostrar resultados reproduzíveis fora de benchmarks controlados e em pilhas heterogêneas. Equipes que avaliam agentes de programação podem começar por um piloto estreito: escolha uma tarefa repetitiva, defina uma métrica de qualidade, meça tokens, tempo e taxa de reversão e compare a execução direta com uma execução programática. O valor do harness aparecerá quando o ganho de eficiência vier acompanhado de rastreabilidade — não apenas de uma demonstração mais rápida.