Porque o seu integrador não lhe constrói um agente

Pediu ao seu integrador de sistemas um agente de IA. A resposta veio com uma equipa de catorze pessoas, um roadmap de dezoito meses, uma fase de discovery e um steering committee com logótipo próprio. Algures pelo slide trinta, sentiu a gravidade familiar de um Grande Programa a formar-se em torno daquilo que esperava ser um projeto focado.

Aqui fica a explicação incómoda, e a tese deste artigo: o seu integrador não lhe consegue construir um agente — não por falta de talento das suas pessoas, mas porque o modelo de negócio dele vende horas, e os agentes existem para destruir horas. Esse conflito é estrutural, não moral. Nenhuma dose de boa vontade, de um lado ou do outro da mesa, o revoga. E, assim que se percebe o mecanismo, uma década de programas de IA corporativa encalhados 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 = pessoas × horas × tarifa. Tudo na forma como estas empresas vendem, alocam equipas e definem âmbitos decorre da maximização destes três fatores. A utilização é a métrica-deus; o banco tem de estar faturável; equipas grandes em prazos longos não são um defeito do modelo — são o modelo.

Coloque agora a construção de um agente dentro desta equação e veja-a comportar-se mal duas vezes:

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

Segundo: bem feito, é pequeno demais para contar. A versão honesta da maioria dos projetos de agentes — a que descrevemos em O abismo entre a demo e a produção — é um punhado de pessoas seniores durante dois meses, seguido de uma longa cauda de operação e melhoria. Para o plano de receitas de uma body shop, isso é um erro de arredondamento. Por isso a proposta incha até caber no modelo de negócio: entram a fase de discovery, as catorze cadeiras, o comité. Ninguém lhe está a mentir. É a forma do negócio que está a falar.

A armadilha do partner stack

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

Os agentes pedem a arquitetura oposta: fina, componível, agnóstica quanto ao modelo — um sistema pequeno que orquestra as ferramentas que já tem através de APIs, troca de modelos à medida que 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, nisso, é sua.

Os agentes são uma disciplina de produto, não de projeto

Aqui está o desalinhamento mais profundo, o único que subsistiria mesmo que os incentivos fossem puros. Um projeto tem um ritual definidor: a entrega final. Requisitos para dentro, entregável para fora, aceitação, saída. Todo o sistema operativo do integrador — contratos, alocação de pessoas, QA, o champanhe — está construído em torno desse fim.

Um agente não acaba. Começa na entrega:

Os evals têm de correr a cada alteração de prompt, de modelo ou de retrieval — para sempre.
A memória acumula-se e precisa de curadoria; os playbooks atualizam-se sempre que o agente é corrigido (o efeito composto que descrevemos em Os agentes precisam de memória, não de modelos maiores).
Os modelos ultrapassam-se uns aos outros; alguém tem de voltar a fazer benchmarks e trocar de motor sem partir comportamentos.
O negócio muda — preços, políticas, pessoas — e a ground truth do agente tem de mudar com ele.
A telemetria tem de ser vigiada por alguém com poder para agir sobre o que ela mostra.

Isto não é manutenção no sentido de «manter as luzes acesas»; é operação — mais próximo de gerir um pequeno produto do que de ser dono de um sistema entregue. Os projetos entregam-se; os produtos vivem-se. Um agente entregue como um projeto não falha dramaticamente — apodrece em silêncio: evals desatualizados, memória por podar, prompts afinados para um modelo de duas gerações atrás. A entrega final é onde os agentes vão morrer.

Não se compra um agente a um modelo de negócio que vende horas. Os incentivos não sobrevivem à fatura.

O que exigir em alternativa

A solução não é «contratar um integrador melhor». É contratar com incentivos de engenharia de produto — a quem quer que recorra, incluindo a nós:

Âmbito por resultado, não por número de FTE. O contrato nomeia o fluxo de trabalho, o estado de concluído e a meta mensurável — não o número de consultores presentes nas suas reuniões. (A filosofia de compra está em Não compre IA, compre resultados.)
Software a funcionar na segunda semana. Uma fatia fina do fluxo real, em contacto com produção, em dias — não um documento de arquitetura ao terceiro mês. A velocidade não é bravata; é a única forma honesta de descobrir onde estão os problemas a sério.
A suite de evals é um entregável nomeado. Casos golden, limiares de exatidão, execuções de regressão — versionados, entregues a si, seus. Um fornecedor que não aceita ser medido está a dizer-lhe qual é a previsão dele para essa medição.
Um acordo de operação e melhoria, ou um dono interno a sério. Alguém opera o agente depois do arranque: vigia a via dos erros, faz curadoria da memória, refaz os benchmarks dos modelos. Se for a sua empresa, o contrato tem de incluir a formação desse dono — não um PDF, um estágio prático.
Uma equipa com nomes. Dois a quatro engenheiros seniores, cujos nomes conhece, que não vão a nenhum steering committee. Se o organograma da proposta tiver mais camadas do que o diagrama de arquitetura, acredite no organograma.
Propriedade intelectual e direitos de saída. Os seus prompts, os seus playbooks, os seus dados, os seus evals — portáveis desde o primeiro dia. Tudo o resto é dependência com passos extra.

Repare no que esta lista faz: torna o trabalho pequeno, sénior, iterativo e permanente — exatamente o quadrante que o modelo das horas não consegue habitar, e é por isso que exigi-lo funciona como filtro. As empresas que não conseguem dizer que sim vão desculpar-se educadamente.

Como é que isto se faz na prática

A nossa resposta ao problema dos incentivos é estrutural: construímos como uma empresa de produto que por acaso serve clientes, a partir de um sítio onde há engenharia sénior disponível e onde a economia deixa o pequeno continuar pequeno — faz parte do porquê de construirmos em Portugal.

E operamos aquilo que entregamos, começando por nós. O assistente no canto desta página — pesquisa sobre todo o site, memória persistente — é nosso, está em produção, vigiado e melhorado. O hub de publicação que transforma um briefing em conteúdo para blogue, LinkedIn e Facebook faz correr a nossa própria operação de conteúdos. O motor que converte brandbook em website gera sites multi-tenant reais a partir de dados de marca estruturados, incluindo este. Nada disto prova que somos a escolha certa para o seu problema — mas prova que a disciplina de operação existe, porque seríamos os primeiros a sentir-lhe a falta, antes de qualquer cliente. O dogfooding é o único teste de honestidade nesta indústria que não se consegue fingir num slide. É também por isso que a nossa página de sistemas de IA descreve sistemas a funcionar, e não capacidades.

Um arquétipo claramente ilustrativo, para contraste: imagine um distribuidor de média dimensão que quer as encomendas recebidas automaticamente redigidas no ERP. A proposta do integrador: catorze pessoas, discovery, uma migração de plataforma «já agora», entrada em produção no Q4 do ano seguinte. A alternativa com forma de produto: três seniores; na primeira semana, o agente lê e-mails históricos reais e redige encomendas num sandbox; na terceira semana, corre em produção atrás de um gate de aprovação; na décima semana, a suite de evals diz que tipos de encomenda pode submeter sozinho. Tempo total decorrido: menos do que a fase de discovery do integrador. A diferença não foi o talento. Foi aquilo que o modelo de negócio de cada equipa precisava que fosse verdade.

A ressalva honesta

Os integradores não são vilões, e isto não é uma execução sumária da categoria. Grandes implementações de ERP, migrações de infraestrutura, reforço de equipas à escala, harmonização de sistemas em vinte países — trabalho genuinamente com forma de projeto, com entregas finais a sério — foi para isso que o modelo foi construído, e fá-lo bem. A tese é mais estreita e mais afiada: os agentes não têm forma de projeto. São pequenos, seniores, iterativos e permanentes — e nenhum talento dentro de uma estrutura movida a horas consegue manter essa forma por muito tempo, porque a estrutura ganha sempre.

Por isso, quando a proposta de catorze pessoas aterrar na sua secretária, não precisa de discutir com ela. Faça apenas as seis perguntas acima e veja o que acontece à sala.

Se quiser uma segunda leitura de uma proposta de agente que tenha recebido — incluindo «esta parte até está bem, mantenha», quando for esse o caso —, fale connosco. Na pior das hipóteses, sai a saber exatamente que incentivos está a comprar.