Por que seu integrador não constrói um agente de IA

Você pediu um agente de IA ao seu integrador de sistemas. Eles voltaram com um time de quatorze pessoas, um roadmap de dezoito meses, uma fase de discovery e um comitê diretor com logo próprio. Lá pelo slide trinta, você sentiu a gravidade familiar de um Grande Programa se formando em torno do que você esperava que fosse um build enxuto e focado.

Aqui vai a explicação incômoda, e a tese deste artigo: seu integrador não consegue construir um agente para você — não porque falte talento às pessoas dele, mas porque o modelo de negócio dele vende horas, e agentes existem para destruir horas. Esse conflito é estrutural, não moral. Nenhuma dose de boa vontade dos dois lados da mesa revoga isso. E, uma vez que você enxerga o mecanismo, uma década de programas corporativos de IA travados deixa de ser um mistério.

A física da hora faturável

Um negócio de integração de sistemas é uma equação: receita = headcount × horas × valor-hora. Tudo na forma como essas empresas vendem, alocam gente e dimensionam escopo nasce de maximizar esses três fatores. Utilização é a métrica-deus; o pessoal no banco precisa continuar faturável; times grandes em prazos longos não são um defeito do modelo — eles são o modelo.

Agora coloque a construção de um agente dentro dessa equação e veja a coisa desandar em dois pontos:

Primeiro: o entregável ataca a unidade de venda. Um agente que elimina dez mil horas por ano de trabalho de back-office é, para uma empresa que vende horas, um objeto estranho — uma máquina cujo propósito explícito é fazer horas desaparecerem. Dá para vender uma vez. Mas os instintos, as tabelas de preço e os critérios de promoção dessa empresa foram todos forjados vendendo a presença de esforço, e um agente é a ausência de esforço, transformada em produto.

Segundo: bem-feito, é pequeno demais para importar. A versão honesta da maioria dos projetos de agente — a versão que descrevemos em O abismo entre a demo e a produção — é um punhado de pessoas sêniores por alguns meses, seguido de uma longa cauda de operação e melhoria. Para o plano de receita de um body shop, isso é erro de arredondamento. Então a proposta infla até caber no modelo de negócio: entram a fase de discovery, as quatorze cadeiras, o comitê. Ninguém está mentindo para você. É o formato do contrato falando.

A armadilha do partner stack

Existe uma segunda camada de incentivos, mais silenciosa e igualmente amarrada. Integradores vivem dentro de programas de parceria: certificações, margens de revenda, acordos de co-selling com as grandes plataformas. Essas parcerias pagam — em margem de licença e em geração de leads —, o que significa que o espaço de respostas do integrador já está delimitado antes de você fazer a pergunta. O diagnóstico será, com uma confiabilidade notável, que você precisa da plataforma em que ele é certificado, mais o novo add-on de IA dela, mais horas de implementação por cima.

Agentes pedem a arquitetura oposta: fina, componível, agnóstica de modelo — um sistema pequeno que orquestra suas ferramentas existentes via APIs, troca de modelo conforme a fronteira avança e acumula o seu conhecimento em vez da contagem de licenças de um fornecedor. Ninguém se certifica em “fino e componível”. Não há margem nisso — para eles. A margem, nesse caso, é sua.

Agentes são uma disciplina de produto, não de projeto

Este é o descompasso mais profundo, o que continuaria existindo mesmo se os incentivos fossem puros. Todo projeto tem um ritual que o define: o handover. Requisitos entram, entregável sai, aceite assinado, saída. O sistema operacional inteiro do integrador — contratos, alocação, QA, o champanhe — é construído em torno desse final.

Um agente não termina. Ele começa no handover:

Evals precisam rodar a cada mudança de prompt, de modelo ou de retrieval — para sempre.
A memória se acumula e precisa de curadoria; os playbooks são atualizados sempre que o agente é corrigido (o efeito composto que descrevemos em Agentes precisam de memória, não de modelos maiores).
Os modelos se ultrapassam uns aos outros; alguém precisa refazer benchmarks e trocar de engine sem quebrar o comportamento.
O negócio muda — preços, políticas, pessoas — e a verdade de referência do agente precisa mudar junto.
A telemetria precisa ser acompanhada por alguém com poder para agir sobre o que ela mostra.

Isso não é manutenção no sentido de “manter as luzes acesas”; é operação — mais perto de tocar um produto pequeno do que de ser dono de um sistema entregue. Projetos são passados adiante; produtos são vividos. Um agente entregue como projeto não falha de forma dramática — ele apodrece em silêncio: evals defasados, memória sem poda, prompts ajustados para um modelo duas gerações atrás. O handover é onde os agentes vão morrer.

Você não consegue comprar um agente de um modelo de negócio que vende horas. Os incentivos não sobrevivem à nota fiscal.

O que exigir no lugar

O conserto não é “contratar um integrador melhor”. É contratar com incentivos de engenharia de produto — de quem quer que você contrate, inclusive nós:

Escopo por resultado, não por número de FTEs. O contrato nomeia o workflow, o estado de “pronto” e a meta mensurável — não a quantidade de consultores presentes nas suas reuniões. (A filosofia de compra está em Não compre IA, compre resultados.)
Software funcionando na semana dois. Uma fatia fina do workflow real, em contato com produção, em dias — não um documento de arquitetura no terceiro mês. A velocidade não é bravata; é a única forma honesta de descobrir onde moram os problemas de verdade.
A suíte de evals é um entregável nomeado. Casos golden, limiares de acurácia, rodadas de regressão — versionados, entregues a você, seus. Um fornecedor que se recusa a ser medido está te contando qual é a previsão dele para a medição.
Um acordo de operar e melhorar, ou um dono interno de verdade. Alguém opera o agente depois do lançamento: acompanha a fila de erros, faz curadoria da memória, refaz benchmarks de modelos. Se esse alguém é você, o contrato precisa incluir a formação desse dono — não um PDF, um aprendizado na prática.
Um time que você consegue nomear. De dois a quatro engenheiros sêniores, cujos nomes você conhece, que participam de zero comitês diretores. Se o organograma da proposta tem mais camadas que o diagrama de arquitetura, acredite no organograma.
Propriedade intelectual e direito de saída. Seus prompts, seus playbooks, seus dados, seus evals — portáveis desde o primeiro dia. Qualquer outra coisa é dependência com passos extras.

Repare no que essa lista faz: ela deixa o engajamento pequeno, sênior, iterativo e permanente — exatamente o quadrante que o modelo de horas não consegue habitar, e é por isso que exigir tudo isso funciona como filtro. As empresas que não conseguem dizer sim vão se despedir educadamente.

Como isso funciona na prática

Nossa resposta ao problema dos incentivos é estrutural: construímos como uma empresa de produto que por acaso atende clientes, a partir de um lugar onde engenharia sênior é encontrável e a economia permite que o pequeno continue pequeno — isso faz parte do por que construímos em Portugal.

E operamos o que entregamos, começando por nós mesmos. O assistente no canto desta tela — retrieval sobre o site inteiro, memória persistente — é nosso, em produção, monitorado e melhorado. O hub de publicação que transforma um único brief em conteúdo de blog, LinkedIn e Facebook toca nossa própria operação de conteúdo. O motor de brandbook para site renderiza sites multi-tenant reais a partir de dados estruturados de marca, incluindo este aqui. Nada disso prova que somos a escolha certa para o seu problema — mas prova que a disciplina de operação existe, porque sentiríamos a falta dela antes de qualquer cliente. Dogfooding é o único teste de honestidade desta indústria que não dá para fingir num slide. É também por isso que nossa página de sistemas de IA descreve sistemas rodando, não capacidades.

Um arquétipo puramente ilustrativo, para contraste: imagine uma distribuidora de médio porte que quer que os pedidos recebidos sejam rascunhados automaticamente no ERP. A cotação do integrador: quatorze pessoas, discovery, uma migração de plataforma “já que estamos aqui”, go-live no Q4 do ano que vem. A alternativa em formato de produto: três sêniores; na semana um, o agente lê e-mails históricos reais e rascunha pedidos num sandbox; na semana três, roda ao vivo atrás de um gate de aprovação; na semana dez, a suíte de evals diz quais tipos de pedido ele pode lançar sozinho. Tempo total decorrido: menos que a fase de discovery do integrador. A diferença não foi talento. Foi o que o modelo de negócio de cada time precisava que fosse verdade.

A ressalva honesta

Integradores não são vilões, e isto não é uma execução sumária da categoria. Grandes rollouts de ERP, migrações de infraestrutura, alocação de equipes em escala, harmonização de sistemas em vinte países — trabalho genuinamente em formato de projeto, com handovers reais — é para isso que esse modelo foi construído, e ele faz bem. A afirmação aqui é mais estreita e mais afiada: agentes não têm formato de projeto. Eles são pequenos, sêniores, iterativos e permanentes — e nenhuma dose de talento dentro de uma estrutura movida a horas sustenta esse formato por muito tempo, porque a estrutura sempre vence.

Então, quando a proposta de quatorze pessoas chegar à sua mesa, você não precisa discutir com ela. Só faça as seis perguntas acima e observe o que acontece na sala.

Se quiser uma segunda leitura sobre uma proposta de agente que você recebeu — incluindo um “essa parte está boa, pode manter” quando for o caso — fale com a gente. Na pior das hipóteses, você sai sabendo exatamente quais incentivos está comprando.