O modelo é a parte mais barata do agent

Um modelo melhor saiu hoje de manhã. Na hora do almoço, alguém em cada time de engenharia já tinha trocado, rodado os benchmarks e postado os novos números num canal. Nada mais no produto mudou. O agent que agenda a reunião, lembra do cliente, entrega o relatório, continuou fazendo exatamente o que fazia ontem, só um pouco mais rápido.

Agora rode o experimento oposto. Mantenha o modelo congelado e arranque a coisa enrolada ao redor dele: a memória que ele lê, as tools que pode chamar, os evals que pegam seus erros, o gate que decide o que pode ir para produção. O modelo está tão inteligente quanto estava de manhã. O produto está morto.

Essa assimetria é o post inteiro. O modelo é a parte mais barata do agent, o moat é o harness ao redor dele.

O que as pessoas comparam, e o que de fato quebra

Entre em quase qualquer conversa sobre agents e a pergunta é a mesma: qual modelo. Os leaderboards os rankeiam. Os posts de lançamento os comparam. A decisão de compra gira em torno de uma coluna de scores.

É a coluna errada.

O modelo é o único componente que você consegue substituir numa tarde. Ele chega atrás de uma interface estável, texto entra, texto sai, alguns parâmetros. Três provedores entregam algo intercambiável. O preço do bom cai sem parar, e o gap entre o melhor e o segundo melhor encolhe sem parar. Uma peça com três fornecedores intercambiáveis e um preço caindo a cada trimestre é, por definição, uma commodity. Você não constrói um moat sobre uma commodity. Você constrói sobre aquilo que ninguém consegue te entregar de prateleira.

Aqui está o modelo mental ingênuo, o que os leaderboards encorajam: um agent é um modelo com um prompt bonito. Deixe o modelo mais inteligente, o agent fica melhor. Então você corre atrás do modelo mais inteligente, e quando ele te decepciona, espera pelo próximo.

Aí você assiste a um agent real falhar em produção, e o diagnóstico nunca é “o modelo não era inteligente o suficiente”. O modelo respondeu a pergunta que lhe foi feita, corretamente, isoladamente. O que quebrou foi tudo ao redor da resposta. Ele não sabia que o cliente já tinha reclamado duas vezes, porque não conseguia ler o histórico. Tentou agir e não tinha mãos, porque nenhuma tool estava conectada. Produziu uma resposta confiante e errada e nada a pegou, porque não havia teste para aquele caso. Subiu uma regressão porque a única coisa que o avaliava era a mesma mente que o escreveu.

Nenhum desses é problema de modelo. O modelo é a parte mais barata do agent, o moat é o harness ao redor dele. O harness são as quatro coisas que o leaderboard nunca mede: o que o agent lembra, o que pode tocar, o que o pega quando está errado e o que pode ir para produção. Deixe-me pegar uma de cada vez.

Memória: a parte que não reseta à meia-noite

Comece pela falha que todo mundo já sentiu. Você conta algo a um assistente na segunda. Na terça ele não tem ideia de que vocês conversaram. Cada conversa começa do zero, então cada conversa re-litiga o básico, quem você é, no que está trabalhando, o que já decidiu. O modelo é brilhante e amnésico, o que é uma combinação estranha e inútil, como contratar um gênio que sofre uma pancada na cabeça toda noite.

A correção ingênua é enfiar tudo no prompt. Cole o histórico, os documentos, as últimas dez conversas, e deixe o modelo resolver. Isso funciona para um brinquedo e desmorona para uma empresa. Há mais contexto do que qualquer window comporta. A maior parte dele é irrelevante para esta pergunta. E despejar tudo não faz o agent lembrar, faz ele dar uma passada de olho, caro, e perder a única linha que importava.

A correção real é um sistema que decide o que guardar e como buscar: um store durável no qual o agent escreve, um índice que encontra os três fatos relevantes em dez mil, e uma disciplina sobre o que vale lembrar versus o que é ruído. Essa última parte é a parte difícil. Lembrar de tudo é o mesmo que lembrar de nada, o sinal se afoga. Uma memória útil é, na maior parte, uma boa política de esquecimento.

Troque o modelo e a memória sobrevive. Troque a memória e o modelo mais inteligente do mundo começa cada dia como um estranho.

Note o que isso significa para o teste de troca. As conversas que você teve, as decisões que registrou, os relacionamentos que o sistema aprendeu, nada disso vive no modelo. Vive no store ao lado dele. Atualize o modelo e esse histórico fica intocado; o novo modelo acorda já conhecendo sua empresa. Perca o store e nenhum upgrade te salva. O modelo é a parte mais barata do agent, o moat é o harness ao redor dele, e a memória é a primeira parede dele.

Tools: uma mente sem mãos é um chatbot

Um modelo consegue raciocinar sobre enviar o email. Não consegue enviá-lo. Essa frase é a diferença inteira entre um chatbot e um colega de trabalho, e não tem nada a ver com quão inteligente é o modelo.

A versão ingênua de tools é uma lista de funções parafusada no prompt, aqui estão quarenta coisas que você pode chamar, boa sorte. Faz uma demo linda e falha em silêncio. O agent escolhe a tool errada. Chama a tool certa com argumentos lixo. Tenta escrever quando o usuário só pediu para ler. Dispara uma ação que toca dinheiro real ou clientes reais sem um freio na frente. O modelo não está quebrado; a fiação está. Uma lista de funções não é um par de mãos. É uma pilha de alavancas sem rótulo.

Uma camada de tools real é, na maior parte, a parte sem glamour ao redor de cada função. É o guardrail que não deixa uma pergunta read-only disparar um write. É o freio que pausa qualquer ação com consequências e pergunta a um humano primeiro. É o caminho de recuperação para quando uma tool retorna um erro em vez de um resultado. É a disciplina de que o agent recebe algumas tools afiadas e bem descritas em vez de quarenta vagas, porque cada alavanca extra é mais um jeito de puxar a errada.

E aqui está a parte que sobrevive à troca do modelo: as integrações que você construiu, a conexão com o calendário, o CRM, o sistema de billing, os guardrails ao redor de cada, são suas, não do modelo. Um novo modelo herda cada uma delas no dia um e é imediatamente mais útil do que um modelo mais inteligente sem mãos. O alcance de um agent é determinado pelo que ele pode tocar, e o que ele pode tocar é algo que você constrói, uma vez, com cuidado, e mantém.

Evals: a única definição honesta de “funciona”

Agora a parte que os times pulam primeiro e mais se arrependem.

Pergunte a um agent escritor se a mudança dele funciona e ele vai dizer sim. Claro que vai, ele acabou de escrevê-la, rodou um teste, o teste passou. Mas ele também escreveu o teste, então o teste afirma o que o código já faz. Ele definiu “pronto”, então “pronto” é o que quer que ele tenha terminado. Uma mente avaliando o próprio trabalho é o juiz menos confiável que existe, e “funciona” vindo do autor é um sentimento usando um checkmark.

O modelo ingênuo de confiança é: o modelo disse que está pronto, então está pronto. Substitua uma palavra e a coisa toda desmorona. “Pronto” e “parece pronto” são afirmações diferentes, e o gap entre elas é exatamente onde os bugs vivem.

Um eval é a correção, e um eval não é um modelo. É um corpus de fluxos reais, as coisas que os clientes de fato fazem, rodado contra o agent a cada mudança, avaliado por um juiz que não tem nenhum interesse no trabalho. O agent roteou esta requisição corretamente? Lembrou do fato que deveria ter lembrado? Recusou a ação que deveria ter recusado? Cada fluxo é uma pergunta com uma resposta boa conhecida, e o eval é a diferença entre acredito que funciona e aqui estão duzentos fluxos que passaram e os três que não passaram, pelo nome.

“Funciona” é um sentimento. Um eval é a única definição honesta de pronto.

A razão de isto ser harness e não modelo: o corpus é seu. Ele codifica o que o seu produto deveria fazer, coletado de como os seus usuários de fato se comportam, incluindo cada borda estranha que eles encontraram e que nenhum benchmark jamais conteria. Troque o modelo e você roda o mesmo corpus de novo e sabe na hora se o novo é melhor ou só mais novo. Um leaderboard te diz que um modelo é inteligente em geral. Seus evals te dizem se ele está certo no seu trabalho, e só um desses dois números pode estar errado de um jeito que te custa um cliente.

O gate: a parte mais barata diz sim, o moat diz não

Empilhe memória, tools e evals e você ainda precisa de mais uma coisa, a que amarra tudo: algo que decide o que de fato pode ir para produção.

A pipeline ingênua não tem gate. O agent faz o trabalho, diz que está pronto, e o trabalho é merjado, ou pior, chega a um cliente, na força da própria palavra. Todos nós já vimos onde isso vai dar. O agent que confiantemente configurou um lembrete que nunca disparou. A mudança que passou em todo teste local e quebrou no segundo em que tocou o mundo real. O “pronto” que ninguém re-checou contra o que pronto deveria significar.

Um gate é um checkpoint determinístico pelo qual o agent mais inteligente do time não consegue passar na lábia. Não outro modelo perguntado “isto parece certo?”, esse carimba. Um gate que roda os evals, checa a prova, e recusa a mudança a menos que um fluxo real tenha rodado e um resultado real tenha voltado. Ele diz sim por padrão a nada. Ele é, de propósito, a coisa mais conservadora do prédio.

E é a coisa mais valiosa do prédio, que é a parte que surpreende as pessoas. O componente que produz o mínimo, nenhuma resposta, nenhum código, nenhum output esperto, é o que torna todo o resto confiável. O modelo é a parte que diz sim, consigo fazer isso. O gate é a parte que diz ainda não, você não provou. Uma dessas é uma commodity que você compra de três fornecedores. A outra é um padrão que você tem que construir e defender, e é a razão pela qual o output pode ser confiado sem um humano reler cada linha.

O teste de troca, rodado nas duas direções

Junte as quatro paredes e você pode rodar um experimento limpo que resolve o argumento inteiro.

Troque o modelo. Mantenha o harness. Sua memória ainda guarda cada conversa. Suas tools ainda alcançam cada sistema. Seus evals ainda avaliam contra seus fluxos reais. Seu gate ainda recusa o que não está provado. O novo modelo cai dentro de tudo isso e, se seus evals disserem, o produto fica melhor até terça. Nada sobre a empresa que o agent serve teve que mudar.

Agora troque o harness. Mantenha o modelo. O mesmo modelo brilhante, mas ele não lembra de nada, não pode tocar em nada, não é avaliado por ninguém, e vai para produção na própria palavra. Isso não é um produto pior. Não é um produto. É uma caixa de texto muito inteligente, exatamente igual à que seu concorrente também tem, porque eles compraram o mesmo modelo do mesmo fornecedor.

Esse é o teste, e ele só aponta numa direção. O modelo é a parte mais barata do agent, o moat é o harness ao redor dele. A coisa que você consegue substituir numa tarde não é onde sua vantagem vive. A vantagem vive nas quatro coisas que você não consegue comprar de prateleira: o que o agent lembra, o que pode fazer, o que o pega, e o que segura a linha sobre o que vai para produção.

A virada: construa a parte que ainda é sua no ano que vem

Aqui está a parte que não é sobre arquitetura.

Se você está escolhendo onde gastar as horas escassas e caras de um time pequeno, o leaderboard está te puxando para a única decisão que vai se resolver sozinha. O melhor modelo daqui a um ano não é o que está sendo lançado hoje, e qualquer que você escolha, vai trocá-lo, barato, numa tarde, atrás de uma interface estável, do mesmo jeito que trocou o último. Cada hora gasta agonizando sobre aquela coluna é uma hora gasta na parte do sistema que sempre ia ser substituída.

As horas que compõem são as outras. A memória que você ensinou os fatos da sua empresa. As tools que você conectou e protegeu para que um agent pudesse de fato agir. O corpus de fluxos reais que te diz, honestamente, se alguma coisa funciona. O gate que você está disposto a defender no dia em que todo mundo está cansado e o prazo é hoje à noite. Nada disso vem num lançamento de modelo. Tudo isso ainda é seu no ano que vem, e ainda funcionando, não importa quantas vezes o modelo embaixo dele mude.

O modelo mais inteligente do mundo é uma parte que você aluga. O harness é a coisa que você possui.

---

É isso que estamos construindo na Apollo, não uma aposta em qual modelo vence, mas o harness em forma de empresa ao redor de qualquer modelo que vença: um cérebro que lembra, mãos que agem, evals que dizem a verdade, e um gate que diz ainda não. O modelo vai continuar ficando mais barato e mais inteligente, e tudo bem. A gente nunca esteve construindo a parte barata.