O harness: o modelo é apenas o motor

Você provavelmente já ouviu alguém dizer:

« Nosso produto usa GPT. »

Ou Claude. Ou Mistral. Ou Qwen.

Ótimo.

Mas isso, no fim das contas, diz muito pouco sobre o que o produto realmente faz.

Duas aplicações podem usar exatamente o mesmo modelo e ainda assim ter capacidades, desempenho e até comportamentos radicalmente diferentes.

Por quê?

Porque entre a sua aplicação e o modelo existe uma camada da qual se fala bem menos: o harness.

E você vai ver que ela é provavelmente uma das camadas mais importantes da IA moderna.

Voltemos ao nosso documento

No primeiro artigo desta série, pegamos um exemplo extremamente simples: você carrega um documento grande e pede:

« Faça um resumo em 5 pontos. »

Vimos então que, antes mesmo de o seu documento chegar ao modelo, software clássico já podia entrar em ação:

• ▸extrair o texto do PDF,
• ▸dividir o documento,
• ▸procurar as passagens interessantes,
• ▸montar o prompt,
• ▸enviar as informações ao modelo,
• ▸recuperar a resposta dele,
• ▸eventualmente pedir que recomece.

Na época, chamei isso simplesmente de camada de software.

Hoje, um termo começa a se impor para designar boa parte dessa mecânica: o harness.

Mas o que é um harness?

Para simplificar bastante:

« O modelo pensa. O harness organiza o trabalho dele. »

Imagine um motor no meio da sua garagem.

Mesmo com 500 cavalos, você não vai muito longe com ele.

Ele precisa de:

• ▸um volante,
• ▸uma caixa de câmbio,
• ▸rodas,
• ▸freios,
• ▸sensores,
• ▸um tanque,
• ▸um painel,
• ▸e um motorista ou um sistema capaz de decidir para onde ir.

Com um modelo de IA é igual.

O modelo pode ser extremamente competente, mas ele não conhece espontaneamente os seus documentos internos, não tem acesso ao seu CRM, não sabe necessariamente quando fazer uma busca na internet e não decide magicamente como dividir uma tarefa complexa em dez etapas.

Tudo isso precisa ser organizado por software.

Isso é o harness.

E isso muda muita coisa na forma como olhamos para a IA.

Um modelo sozinho é bastante limitado

Peguemos um LLM clássico.

Você dá texto a ele. Ele devolve texto.

Já é impressionante, evidentemente.

Mas imagine agora que você peça:

« Diga quanto faturamos com o cliente Dupont este ano e compare com o ano passado. »

O seu modelo provavelmente não faz ideia de quem é Dupont.

Ele não conhece o seu sistema de faturamento.

Ele não tem os direitos de acesso necessários.

Ele não sabe qual base de dados consultar.

E, sobretudo, você provavelmente não quer entregar toda a sua contabilidade a cada pergunta.

Vai ser preciso, então, construir um ambiente para ele. Por exemplo:

• 01entender que a pergunta é sobre faturamento;
• 02identificar o cliente no seu CRM;
• 03chamar a sua ferramenta contábil;
• 04recuperar apenas os dados necessários;
• 05eventualmente fazer um cálculo;
• 06passar os resultados ao modelo;
• 07verificar se a resposta respeita o formato esperado;
• 08exibir o resultado ao usuário.

O modelo fez apenas uma parte do trabalho.

Todo o resto pertence ao harness.

Primeira função: dar o contexto certo

Você talvez tenha ouvido falar muito de prompt engineering nos últimos anos. Como escrever o melhor prompt?

• ▸"Você é contador há 25 anos…"
• ▸"Responda passo a passo…"
• ▸"Se você não souber a resposta, diga…"

É útil.

Mas estamos começando a passar de uma lógica de prompt engineering para uma lógica bem mais ampla de context engineering.

A pergunta passa a ser menos:

« Como devo formular a minha frase? »

e mais:

« De quais informações o modelo realmente precisa para cumprir esta tarefa? »

Porque encher a janela de contexto dele com 300 páginas inúteis raramente é boa ideia.

O harness poderá então selecionar os elementos interessantes:

• ▸as instruções da empresa;
• ▸o histórico relevante da conversa;
• ▸certos documentos;
• ▸os resultados de uma busca;
• ▸as respostas de uma ferramenta;
• ▸o trabalho feito nas etapas anteriores.

E transmitir ao modelo apenas aquilo de que ele precisa naquele exato momento.

É aqui que reencontramos o nosso famoso RAG, do qual já falamos. Em vez de dar toda a sua documentação ao modelo: pergunta → busca das passagens interessantes → modelo → resposta.

O harness orquestra a busca.

O modelo analisa as informações que lhe são trazidas.

Segunda função: dar ferramentas à IA

É aqui que as coisas ficam bem mais interessantes.

Um LLM já pode decidir:

« Para responder a esta pergunta, preciso usar esta ferramenta. »

Isso pode ser:

• ▸fazer uma busca na internet;
• ▸consultar uma base de dados;
• ▸ler um documento;
• ▸enviar um e-mail;
• ▸consultar um calendário;
• ▸executar código;
• ▸chamar o seu CRM;
• ▸iniciar outro software interno.

Você começa então a obter o que se chama comumente de agente.

Peguemos um exemplo bem simples. Você diz:

« Marque uma reunião com o Paul na semana que vem. »

O modelo pode entender a sua intenção.

Mas o harness precisa permitir que ele:

• 01identifique o Paul;
• 02consulte o seu calendário;
• 03recupere as disponibilidades;
• 04eventualmente consulte o calendário do Paul;
• 05proponha um horário;
• 06aguarde a sua validação;
• 07crie o evento.

E, sobretudo… é preciso impedir que a IA faça qualquer coisa.

Você provavelmente quer autorizar o seu agente a consultar o seu calendário. Talvez não queira permitir que ele apague todos os seus compromissos.

Isso também é papel desta camada de software.

MCP: a tomada USB dos nossos agentes?

Evidentemente, se cada desenvolvedor precisar construir uma conexão diferente para cada ferramenta, vamos recriar rapidamente o maravilhoso mundo das integrações de TI, em que cada um tem a sua API, o seu formato e a sua documentação de 453 páginas.

É justamente para responder a esse problema que protocolos como o MCP — Model Context Protocol surgiram.

A ideia é bem simples: padronizar a maneira como um agente pode descobrir e usar ferramentas ou recursos.

Foi por isso, aliás, que escolhemos na SOCLE construir os nossos agentes em torno desse tipo de protocolo: evitar ao máximo recriar uma integração específica para cada nova capacidade.

Terceira função: decidir o que fazer em seguida

Dar uma ferramenta ao modelo é uma coisa.

Ainda é preciso decidir quando usá-la.

É aqui que entra o que geralmente se chama de ciclo agêntico. Simplificando bastante: observar → refletir → agir → observar o resultado → recomeçar.

Peguemos a busca por um restaurante. O seu agente poderia:

• 01entender que você procura um restaurante italiano;
• 02usar uma ferramenta de busca;
• 03obter cinco resultados;
• 04perceber que você pediu um restaurante aberto hoje à noite;
• 05verificar os horários;
• 06eliminar os restaurantes fechados;
• 07olhar as disponibilidades;
• 08apresentar as três melhores propostas.

Não fazemos mais necessariamente usuário → modelo → resposta, mas usuário → modelo → ferramenta → modelo → ferramenta → modelo → resposta.

E isso pode continuar por várias dezenas de etapas.

O harness é a mecânica que mantém esse ciclo vivo.

• ▸Ele transmite os resultados.
• ▸Ele guarda o estado.
• ▸Ele controla o número de iterações.
• ▸Ele detecta os erros.
• ▸Ele pode pedir que a IA mude de estratégia.
• ▸E, sobretudo, ele decide quando é hora de parar.

Porque um agente que pensa eternamente é filosoficamente fascinante, mas economicamente bem catastrófico.

E se um modelo não bastasse?

Podemos ir ainda mais longe.

Por que usar o mesmo modelo para absolutamente todas as tarefas?

Peguemos uma reunião gravada. Precisamos:

• ▸entender um arquivo de áudio;
• ▸distinguir os interlocutores;
• ▸transcrever o que dizem;
• ▸corrigir certos erros;
• ▸entender o contexto de negócio;
• ▸eventualmente gerar uma síntese.

Um único modelo enorme poderia teoricamente tentar fazer tudo. Mas não é necessariamente a melhor solução.

Na SOCLE, por exemplo, o nosso sistema de transcrição combina vários tratamentos: um agente especializado em reconhecimento de voz faz a transcrição, e depois um agente LLM pode aplicar uma correção contextual levando em conta os interlocutores e as informações de negócio.

Cada tecnologia é usada onde faz sentido.

É exatamente esse o interesse de raciocinar em ecossistema de agentes em vez de um modelo único.

O multi-agente

E, claro, porque adoramos complicar as coisas assim que elas começam a funcionar, podemos dar vários agentes ao nosso harness.

Imagine uma equipe numa empresa. Você tem:

• ▸um jurista;
• ▸um desenvolvedor;
• ▸um comercial;
• ▸um contador.

Você poderia contratar uma pessoa extremamente inteligente e pedir que ela vire especialista nas quatro áreas. Ou usar vários especialistas e deixá-los colaborar.

Num sistema multi-agente, o princípio é parecido. Um agente pode receber o pedido e repassá-lo a outro agente mais especializado.

O harness vira então uma espécie de maestro.

• ▸Quem trabalha?
• ▸Em que ordem?
• ▸Quais informações devem passar de um agente a outro?
• ▸Eles devem trabalhar em paralelo?
• ▸Quem verifica o resultado?

Na SOCLE, usamos em particular o protocolo A2A — Agent-to-Agent para estruturar essas trocas entre agentes.

O objetivo continua o mesmo: evitar que cada nova combinação exija reconstruir o seu produto inteiro.

Quarta função: escolher o modelo certo

E é aqui que você vai entender por que, no capítulo anterior, expliquei que um modelo é, no fim das contas, "apenas um algoritmo".

O seu produto não precisa necessariamente estar casado com GPT, Claude ou Mistral até que a morte os separe.

O harness pode constituir uma camada de abstração entre a sua aplicação e os seus modelos. Imagine:

• ▸um modelo pequeno e rápido para classificar um pedido;
• ▸um modelo especializado em código para analisar um programa;
• ▸um modelo mais potente para uma tarefa complexa;
• ▸um modelo multimodal para entender uma imagem;
• ▸um modelo local para certos dados sensíveis.

O seu usuário, por sua vez, não precisa saber que acabou de usar quatro modelos diferentes. Ele quer apenas que o problema dele seja resolvido.

E esse é um ponto que nos importa muito na SOCLE: não achamos que um produto de IA deva ser construído em torno de um modelo. Ele deveria ser construído em torno de uma necessidade.

Os modelos passam então a ser recursos que o sistema escolhe conforme a tarefa a cumprir.

O modelo mais potente nem sempre é o melhor produto

Talvez seja a ideia mais importante deste artigo.

Imaginemos duas empresas usando exatamente o mesmo modelo.

Empresa A

Ela envia a sua pergunta direto ao LLM com um prompt enorme de 15 páginas.

Empresa B

O harness dela:

• ▸identifica a sua intenção;
• ▸recupera apenas os documentos necessários;
• ▸seleciona as ferramentas certas;
• ▸controla as permissões delas;
• ▸usa um modelo especializado para uma subtarefa;
• ▸verifica o resultado;
• ▸pede validação humana se necessário;
• ▸registra todas as etapas.

É também por isso que comparar soluções de IA apenas perguntando "qual LLM eles usam?" começa a se tornar uma pergunta insuficiente.

É como comparar dois carros apenas perguntando quantos cavalos o motor tem. Isso importa. Mas você esquece tudo o que está em volta.

Human-in-the-loop: às vezes, a IA deve simplesmente perguntar

Outro elemento particularmente importante num harness: saber quando não agir sozinho.

Imagine uma IA usada num contexto jurídico. Ela pode:

• ▸transcrever uma entrevista;
• ▸identificar os interlocutores;
• ▸apontar uma incoerência;
• ▸propor uma correção.

Mas alterar definitivamente um depoimento sem validação humana seria, evidentemente, uma péssima ideia.

O harness pode então introduzir pontos de controle: IA → proposta → validação humana → continuação do tratamento.

É o que se chama de human-in-the-loop.

E, ao contrário de certas visões muito futuristas da IA, isso não é necessariamente uma falha de automação. Às vezes é exatamente o que torna a automação utilizável.

Em um dos nossos clientes da área jurídica, usamos justamente essa abordagem: diferentes etapas do tratamento podem ser verificadas e corrigidas pelo usuário antes da validação.

Quinta função: observar o que acontece

É provavelmente um dos aspectos menos sexy da IA.

E, no entanto, se você quiser colocar um sistema em produção, ele se torna indispensável.

O seu agente acabou de produzir uma resposta ruim. Por quê? Foi:

• ▸o modelo?
• ▸o prompt?
• ▸o documento recuperado pelo RAG?
• ▸uma resposta ruim de uma ferramenta?
• ▸um problema de roteamento?
• ▸uma etapa anterior que errou?
• ▸uma informação presente na memória?
• ▸outro agente?

Se o seu sistema consiste apenas em pergunta → grande caixa-preta → resposta, boa sorte.

Um harness industrial deve, portanto, permitir também acompanhar o desenrolar do tratamento. Na SOCLE, buscamos justamente tornar as diferentes etapas observáveis.

• ▸Qual agente foi chamado?
• ▸Qual ferramenta?
• ▸Qual documento?
• ▸Qual modelo?
• ▸Quanto tempo?
• ▸Em que ordem?

Isso permite entender o que a sua IA realmente faz. Mas também medir o custo dela.

Porque uma IA que faz você ganhar 3 minutos de trabalho consumindo 12 € de computação a cada pedido talvez não seja o fantástico projeto de transformação digital anunciado no PowerPoint.

E a segurança nisso tudo?

Assim que você dá ferramentas a uma IA, a questão se torna evidentemente crítica.

Um chatbot que alucina uma capital é chato. Um agente conectado ao seu sistema de informação que alucina uma ação é ligeiramente mais problemático.

O harness deve, então, poder impor regras:

• ▸quais ferramentas são acessíveis;
• ▸quais ações exigem validação;
• ▸quais dados podem ser transmitidos;
• ▸quantas ações podem ser realizadas;
• ▸quais usuários têm quais direitos;
• ▸quais resultados devem ser verificados.

Quanto mais a IA se torna capaz de agir, mais essa camada se torna importante.

A segurança de um sistema agêntico não pode, portanto, repousar apenas sobre "pedimos gentilmente ao modelo, no prompt, para não fazer besteira."

Seria prático. Mas evitemos.

Afinal, onde está a inteligência?

Quando o ChatGPT surgiu, associamos naturalmente toda a inteligência que observávamos ao modelo. Era lógico.

Mas, à medida que os nossos sistemas ficam mais complexos, a fronteira fica bem mais difusa.

Uma parte do desempenho vem do modelo. Outra vem:

• ▸da qualidade das ferramentas;
• ▸do contexto que lhe é fornecido;
• ▸da memória;
• ▸do RAG;
• ▸do roteamento;
• ▸da orquestração;
• ▸dos ciclos de verificação;
• ▸dos outros modelos em volta dele.

O sistema de IA passa então a ser mais importante que o simples modelo. E essa é provavelmente a evolução mais interessante que observamos hoje.

Passamos de "qual modelo você usa?" para "que sistema você construiu em volta dos seus modelos?"

Em resumo

Ele traz a ele:

• ▸contexto;
• ▸documentos;
• ▸memória;
• ▸ferramentas;
• ▸regras;
• ▸uma capacidade de agir;
• ▸outros agentes;
• ▸mecanismos de controle;
• ▸observabilidade.

E, sobretudo, ele transforma uma simples chamada de modelo em um verdadeiro produto.

É também por isso que na SOCLE trabalhamos antes de tudo nessa camada. O nosso objetivo não é criar o próximo modelo generalista: outras empresas já gastam alguns bilhões para isso ;)

O nosso trabalho consiste em permitir que as empresas construam, em torno desses modelos, sistemas utilizáveis: agentes, RAG, ferramentas compatíveis com MCP, ecossistemas multi-agentes baseados em A2A, controle humano e acompanhamento das diferentes etapas.

O modelo passa assim a ser uma peça intercambiável dentro de um sistema maior.

E isso nos leva naturalmente ao próximo capítulo. Porque todo esse belo sistema — os agentes, as ferramentas, os modelos chamados em cascata — precisa rodar em algum lugar.

Spoiler: isso consome concreto, eletricidade e silício.