A conversa pública sobre IA empresarial girou em torno de modelos por dois anos. Qual modelo é mais inteligente, qual contexto é maior, qual benchmark caiu hoje. Essa conversa terminou. O modelo virou commodity. O problema não é mais ele. O problema é o ambiente onde o modelo opera, e a maioria das empresas está construindo esse ambiente errado, no escuro, e em paralelo por departamento.

O nome técnico do que está acontecendo é agent sprawl. Proliferação descoordenada de agentes. Marketing contrata um chatbot. RH contrata outro. Atendimento spawna três fluxos no n8n. Engenharia tem dois copilotos rodando. Finanças tem uma automação que ninguém mais entende. Cada um desses agentes carrega sua própria versão da empresa, suas próprias regras hardcoded, sua própria memória local, e nenhuma fala com a outra. Em seis meses, ninguém sabe quantos agentes existem, quanto custam, ou o que eles decidem em nome da empresa.

Esse é o novo débito técnico. Não é dívida de código. É dívida de coordenação.

O modelo é quem pensa. O harness é sobre o quê ele pensa.

Existe um dado experimental que precisa virar conhecimento comum entre quem decide tecnologia. Pesquisadores de Princeton mediram a diferença de performance do mesmo modelo de IA resolvendo as mesmas tarefas em dois ambientes diferentes. No primeiro, o modelo recebia um terminal cru. No segundo, recebia uma interface estruturada com busca limitada, visualização de arquivos com numeração de linha, linter integrado, e gestão de contexto. Mesmo modelo, mesmas tarefas. A diferença de acerto foi de mais de 60 por cento. Não foi nova versão do modelo. Não foi mais GPU. Foi o ambiente em volta do modelo.

Esse ambiente tem nome técnico: harness. É o conjunto de tudo que cerca a inteligência. As ferramentas que ela pode chamar. O formato em que recebe contexto. A memória que persiste entre sessões. As regras que ela não pode quebrar. Os feedbacks que ela recebe quando tenta algo errado. O harness é a infraestrutura cognitiva da operação. E é nele que a competição vai se decidir nos próximos anos, não no modelo.

Quando uma empresa contrata cinco agentes diferentes de cinco fornecedores diferentes, ela não está comprando inteligência. Está comprando cinco harnesses parciais, cada um otimizado para um caso de uso isolado, e nenhum deles compatível com o outro. Cada agente vira uma ilha. Cada ilha tem sua própria física. Resultado previsível: contradições constantes, duplicação de dados, decisões em loop, custo de tokens explodindo, e zero capacidade de a empresa raciocinar sobre si mesma.

A diferença entre cinquenta agentes e um sistema

Vale o exercício concreto. Pense numa empresa de cem pessoas que adotou IA da forma que virou padrão de mercado nos últimos dezoito meses. Tem um Copilot rodando no Office. Tem um agente da empresa A respondendo no site. Um agente da empresa B no WhatsApp. Um automation builder ligando coisas via API. Um SDR sintético prospectando. Um analisador de currículo no RH. Um BI generativo na diretoria. Cada um desses sete componentes foi contratado em um trimestre diferente, por um departamento diferente, com um contrato diferente.

Pergunta simples: quando o cliente reclama de um produto pelo WhatsApp, o agente do site sabe? O Copilot da reunião de produto na semana seguinte sabe? O analisador do RH considera a satisfação do cliente quando avalia o time de pós-venda? O BI da diretoria está olhando os mesmos dados que o agente do WhatsApp usa para responder?

A resposta honesta, em quase toda empresa que faz esse exercício, é não. Sete agentes operam em sete realidades paralelas. A empresa virou multiverso operacional. Quem está pagando a conta dessa fragmentação é a coerência da operação, e a conta é alta porque ela não aparece em nenhuma planilha como linha específica. Aparece como retrabalho, como decisão errada, como cliente perdido sem rastro, como time gastando reunião explicando entre humanos o que os agentes deveriam ter compartilhado entre si.

O caminho contrário existe. Em vez de N agentes com N contextos, a empresa adota um único reservatório de verdade, um único conjunto de regras estáveis, e um único protocolo de execução. Os agentes deixam de ser sistemas autônomos com identidade própria e passam a ser executores plugáveis que leem do mesmo lugar e escrevem no mesmo lugar. Quando o agente do WhatsApp responde uma reclamação, o registro vai para o mesmo arquivo que o BI da diretoria vai consultar amanhã. Quando o RH avalia um colaborador, ele lê do mesmo histórico que o pós-venda alimenta. A empresa para de ter sete cabeças e volta a ter uma.

Ontologia Operacional é o nome do harness centralizado

Existe um nome para isso quando a estrutura é desenhada com rigor: Ontologia Operacional. A ontologia é a forma como a empresa decide explicitamente o que existe no seu mundo (os Dados, os substantivos do negócio), quais são as regras que governam esse mundo (a Lógica, a gramática estável), e como acontecem as transformações dentro dele (as Ações, os verbos disponíveis). Essa tríade vira o sistema de arquivos da empresa. Tudo que qualquer agente precisa saber para agir está lá. Tudo que qualquer agente faz volta para lá.

O efeito prático é que o agente deixa de ser uma caixa preta com conhecimento próprio. Ele vira um operador que herda o contexto compartilhado, executa dentro de regras explícitas, e deixa rastro. Trocar um agente por outro fornecedor amanhã é uma operação local, porque a inteligência verdadeira da empresa não está no agente, está na ontologia. Os modelos vão e vêm. A ontologia fica.

Esse desenho responde a uma pergunta que está incomodando muito CIO em fim de ano: para onde foi todo o dinheiro de IA que gastamos em 2025? A resposta, na maioria dos casos, é que foi para construir sete harnesses parciais quando a empresa precisava de um. O custo recorrente disso não é o token, é a inconsistência. E a inconsistência só se resolve com arquitetura, não com mais ferramenta.

Quem desenha o harness

Surge uma consequência organizacional que algumas empresas já estão sentindo e a maioria ainda vai sentir. Ter agentes sem ter quem desenhe o harness é como ter motoristas sem ter quem desenhe a estrada. A primeira função que precisa existir numa empresa que leva IA a sério não é "head de IA" no sentido genérico. É um papel mais técnico e mais arquitetural: alguém que define como a empresa fica legível para máquinas, qual é o contrato estável entre os agentes, e como a coerência da operação é mantida quando dezenas de processos automáticos rodam em paralelo.

Esse papel se parece muito mais com engenharia de software de plataforma do que com PM de produto de IA. Não é por acaso que estão se valorizando rapidamente as pessoas que sabem desenhar ambientes onde agentes operam bem, em vez das que sabem operar um agente específico. O agente é commodity. O ambiente não.

Empresa que delega essa função para o fornecedor do agente entrega o miolo da sua arquitetura para fora. Empresa que delega para um departamento isolado cria mais um silo. O desenho do harness é função de fundação, ele tem que ser orgânico ao centro da empresa.

Diagnóstico em cinco perguntas

O sintoma de agent sprawl é diagnosticável. Vale o exercício para quem está dirigindo uma operação que adotou IA nos últimos dois anos:

  1. Quantos sistemas de IA com prompt customizado existem hoje na sua empresa? Se você precisa perguntar para cada departamento e somar, já passou da hora.
  2. Esses sistemas leem do mesmo reservatório de verdade? Se cada um tem sua própria base, sua própria FAQ, sua própria visão do cliente, eles não são parte de um sistema. São ilhas.
  3. Quando uma regra de negócio muda, em quantos lugares você precisa atualizar? Se é mais de um, você não tem ontologia. Tem regras espalhadas.
  4. Trocar de fornecedor de modelo amanhã quebraria quanto da operação? Se a resposta é "muita coisa", o lock-in está no agente, não na sua infraestrutura. Você é refém.
  5. Quem é o dono arquitetural do conjunto? Se a resposta é "ninguém, cada departamento cuida do seu", a empresa não tem dono do próprio cérebro coletivo. Tem zelador por sala.

Um sim apenas em duas dessas perguntas já indica que vale fazer o trabalho de unificar antes de adicionar o próximo agente. Empilhar mais um agente em cima de um harness fragmentado não resolve o problema, amplifica.

O caminho prático

A boa notícia é que a virada não exige reconstruir tudo do zero. Exige começar pelo centro e ir empurrando para as bordas. Primeiro, definir explicitamente os substantivos críticos do negócio (cliente, lead, pedido, ticket, projeto) e onde a verdade sobre cada um vive de fato. Segundo, escrever as regras estáveis que governam essas entidades, não em PDF de processo morto, mas em formato consultável por máquina. Terceiro, fazer cada agente novo (e gradualmente cada agente antigo) ler dessa fonte única e escrever de volta nela. Quarto, instituir uma disciplina de write-back: toda ação relevante deixa registro estruturado no mesmo lugar.

Quando essas quatro coisas estão feitas, a empresa não tem mais agent sprawl. Tem um sistema. E sistema é o que escala. Multiverso de chatbots não escala, ele se entropia até alguém puxar o plug.

A próxima onda da automação empresarial não vai ser comprada. Vai ser desenhada. E quem desenhar primeiro o harness certo vai correr em volta de quem ainda está contratando o quinto agente para tapar o buraco que o terceiro agente abriu.

Se você está nesse momento de decisão, vale começar pela conversa de arquitetura antes da conversa de fornecedor. A FSTech mantém uma metodologia aberta sobre Ontologia Operacional aplicada a empresas reais, com referência pública em fstech.digital/framework.