Quando alguém me pergunta qual modelo eu uso, a pergunta faz sentido. Mas ela ainda está olhando para o motor e chamando aquilo de carro.

O motor importa. Um motor ruim limita a viagem. Um motor melhor pode tornar certas tarefas mais rápidas, mais baratas ou simplesmente viáveis. Só que ninguém atravessa uma estrada porque colocou um motor potente no chão da garagem.

Faltam chassi, direção, freio, painel, manutenção, uma rota e alguém responsável por decidir para onde vai.

Com IA acontece a mesma coisa. Um modelo pode escrever, resumir, classificar, extrair e raciocinar sobre o que recebeu. Mas ele não sabe, por iluminação divina, qual arquivo governa uma decisão, quais dados pode consultar, o que não pode publicar, quando precisa parar, como testar uma mudança ou como desfazê-la.

É para essa estrutura ao redor do modelo que eu uso a palavra harness.

TL;DR

Um harness de IA não é um cérebro consciente nem uma janela de conversa com acessórios. É o sistema que transforma a capacidade geral de um modelo em trabalho dirigido: regras escritas, contexto, memória e uma base organizada de decisões, ferramentas e procedimentos reutilizáveis, partes especializadas, permissões, políticas, validação, acompanhamento da operação, segurança, publicação e capacidade de voltar a um estado anterior. O nome não tem uma definição universal — cada plataforma recorta o termo de um jeito —, mas a ideia útil é simples: modelo é componente; operação confiável depende do ambiente que o cerca. Isso não torna o fornecedor irrelevante nem elimina as diferenças entre modelos. Torna dependências, decisões e limites visíveis para que trocar uma peça não destrua o carro inteiro.

O modelo não é a operação

Um modelo de linguagem recebe contexto e produz uma resposta. Ele pode ser excelente nessa parte e ainda ser insuficiente para executar um trabalho inteiro.

Para publicar um artigo, por exemplo, não basta gerar parágrafos. É preciso saber qual é a tese do autor, onde estão as fontes, como verificar uma referência, quais versões do texto existem, que imagem explica a ideia, que idioma está faltando, quais validações o site exige e em que ponto a publicação precisa esperar uma decisão humana.

Isso não é burocracia adicionada depois. É o trabalho.

Na engenharia do Codex, o agente de programação da OpenAI, a empresa chama de harness a camada que organiza o ciclo entre usuário, modelo e ferramentas. Em outro relato da empresa, o recorte se amplia para incluir persistência de conversas, configuração, autenticação, execução de ferramentas e extensões. A Anthropic também descreve sistemas agênticos como modelos ampliados por recuperação de informação, ferramentas e memória.

Essas fontes não criam uma definição oficial e universal. Mostram justamente por que eu não trato harness como nome mágico de produto: é uma palavra usada para a infraestrutura de coordenação que torna um modelo útil num contexto real.

Cinco coisas que costumam ser misturadas

Camada	O que é	O que não resolve sozinha
Modelo	O componente que interpreta entrada e produz saída	Não conhece a operação sem contexto e não administra o mundo fora da conversa por conta própria
Chatbot	A interface pela qual uma pessoa conversa com o modelo	Não define política, o registro autoritativo usado quando informações divergem, nem responsabilidade
Automação	Uma sequência definida: quando X acontece, faça Y	Não lida bem com ambiguidade só porque ganhou um nome bonito
Agente	Um sistema que pode escolher próximos passos e usar ferramentas dentro de um objetivo e de limites	Não deve receber autonomia ilimitada nem contexto genérico
Harness	A estrutura que conecta todas as peças, define contratos e torna o comportamento verificável	Não substitui julgamento humano, dados bons ou um processo que a empresa nunca conseguiu explicar

O acervo já trazia, em “IA não é uma coisa só”, um mapa de modelo, automação, agente e harness. Aqui eu acrescento o chatbot à conversa e aprofundo o harness: não como a quinta caixinha de uma lista, mas como o que impede as outras peças de virarem uma pilha de ferramentas com autoestima demais.

O que entra no carro inteiro

A metáfora visual deste artigo não mostra um cérebro. Mostra um motor cercado pelo restante da operação.

No centro está o modelo. Ao redor dele, eu penso em pelo menos quatro conjuntos de responsabilidades:

1. Contexto e memória. Onde o sistema encontra requisitos, decisões vigentes, fontes, preferências confirmadas e a diferença entre uma conversa antiga e um contrato atual. Uma conversa longa pode ajudar a pensar; não deveria ser a única fonte de verdade. Foi essa fronteira que encontrei quando a IA esqueceu uma decisão já tomada.
2. Ferramentas, skills e agentes. Ferramenta é a capacidade de pesquisar, ler, editar, consultar ou executar algo. Uma skill é um procedimento reutilizável que explica quando usar essa capacidade, quais entradas precisa, quais limites respeita e como verificar a saída. Subagentes dividem trabalho quando há uma separação real de responsabilidade; não são uma forma cara de transformar uma tarefa simples em reunião de condomínio.
3. Políticas e pontos de controle (gates). Permissões, aprovações, limites de custo e tempo, critérios para perguntar, recusar, escalar ou parar. São os pontos que permitem ou bloqueiam a continuidade de uma operação. Um agente que não sabe parar não é autônomo: é só rápido demais para o próprio bem.
4. Operação verificável. Validação, registros proporcionais de eventos (logs), testes, monitoramento, segurança, publicação de uma versão (deploy) e retorno a um estado anterior conhecido (rollback). Se a saída não pode ser inspecionada, corrigida ou desfeita, ela ainda é uma aposta — mesmo que venha com uma tabela bem formatada.

Essas camadas não precisam existir todas com a mesma complexidade. Um harness bom não é o que acumula módulos. É o que dá ao problema as proteções e capacidades de que ele realmente precisa.

Quando uma estrutura simples basta

É aqui que muita gente pega a bazuca.

Se uma tarefa tem entrada previsível, regra clara e saída conhecida, talvez o melhor seja código convencional, uma automação pequena ou até remover uma etapa inútil. Não existe medalha por chamar de “agente” um formulário que calcula frete seguindo uma tabela.

Uma conferência de dados, por exemplo, pode começar com uma verificação regida por regras que produz o mesmo resultado para a mesma entrada (validação determinística). Uma notificação recorrente talvez precise apenas de agenda e uma regra. Um processo confuso pode pedir levantamento de requisito antes de pedir IA.

O modelo entra quando linguagem, documentos variados, ambiguidade controlada ou comparação contextual acrescentam valor. O agente entra quando também precisa escolher uma sequência de passos dentro de limites. O harness cresce quando o custo de errar, a duração da operação, a quantidade de integrações ou a necessidade de reconstruir e examinar o que ocorreu (auditabilidade) justificam isso.

É a mesma disciplina que defendi em “IA no cotidiano não basta”: utilidade não é enfeitar uma tarefa simples com uma arquitetura que ninguém consegue manter.

Portabilidade não é independência absoluta

Eu não tenho interesse em montar uma operação inteira que desaba porque um fornecedor alterou uma tela, um preço ou o comportamento de um modelo.

Mas também não vendo a fantasia de independência absoluta. Modelos variam em capacidade, custo, contexto aceito, ferramentas, políticas e qualidade de resposta. Algumas integrações continuam externas. Migrar pode exigir adaptação, testes e uma decisão econômica real.

O objetivo mais honesto é outro: manter portáveis o que é seu.

• contratos e instruções que explicam como trabalhar;
• decisões, fontes e memória com origem clara;
• testes e critérios de aceite que comparam comportamento;
• interfaces explícitas para ferramentas e dados;
• artefatos gerados que possam ser revisados fora da conversa;
• registros suficientes para entender o que mudou;
• um caminho de rollback quando a mudança não se sustenta.

Se trocar o modelo exige calibrar algumas peças, normal. Se exige reaprender o negócio inteiro porque o contexto estava preso numa conversa ou numa caixa fechada, o problema não é só o modelo.

É arquitetura.

O que aprendi construindo o meu

No meu trabalho, eu atravessei a esteira completa: conversar para entender o requisito, transformar esse requisito em sistema, escolher arquitetura, implementar, publicar, monitorar, proteger e recuperar quando necessário.

Foi essa trajetória que me fez desconfiar tanto de soluções que começam pela ferramenta. Uma empresa pode ter uma ótima ideia e ainda não ter definido quem aprova, qual dado vale, onde a exceção entra ou o que acontece quando algo falha. IA não conserta esse vazio por telepatia. Ela só consegue atravessá-lo mais rápido.

Meu harness pessoal nasceu para evitar outro desperdício: explicar todo o meu modo de trabalhar do zero a cada conversa. Mas ele não transforma qualquer inferência sobre mim em regra. Como contei em “O ChatGPT já sabe muito sobre você”, contexto acumulado vira hipótese; só confirmação vira contrato.

E contrato não pode virar dogma escondido. Em “Hipótese não vira fato só porque a IA repetiu”, explico por que a wiki preserva origem, incerteza, consumidores afetados e condição de revisão. É assim que o sistema aprende sem reescrever o passado de fininho.

Não me serve um agente que só sabe concordar

Um harness não melhora apenas a execução. Ele pode melhorar a qualidade da conversa que vem antes dela.

Eu quero que um sistema encontre lacunas, mostre evidência contrária, diga quando uma fonte não sustenta a tese inteira e devolva uma decisão quando ela continua sendo minha. Isso é o oposto de programar uma voz para me dar razão com ótima dicção.

Esse princípio aparece em “A melhor resposta não é a que mais me agrada”. Não basta que o agente seja fluido, simpático ou rápido. Ele precisa ter permissão e estrutura para discordar, pedir mais contexto e não executar aquilo que ainda está mal definido.

É também por isso que eu desconfio de quem vende agentes genéricos como solução pronta. Uma base reutilizável é ótima. Fingir que ela já conhece os nomes, as exceções e a responsabilidade da empresa é outro assunto.

A pergunta útil não é “qual IA eu compro?”

Antes de escolher uma ferramenta, eu começaria por estas perguntas:

• Que decisão ou trabalho precisa ficar melhor?
• Onde está a fonte de verdade?
• O que é repetitivo, o que é ambíguo e o que não deveria ser automatizado?
• Que dado o sistema pode consultar, alterar ou nunca enxergar?
• Quando ele deve seguir, quando deve parar e quem recebe a exceção?
• Como vamos saber que funcionou — e como vamos voltar atrás se não funcionou?

Quando essas respostas aparecem, modelo, chatbot, automação e agente deixam de ser religião de ferramenta. Viram escolhas de arquitetura.

É nessa fronteira que a i-9.ai trabalha: transformar contexto difuso e requisito real em sistemas que possam ser operados, verificados e evoluídos. Às vezes isso pede IA. Às vezes pede uma automação simples. Às vezes pede tirar uma etapa inútil do caminho antes de fazer qualquer uma das duas.

O modelo pode ser excelente.

Mas ainda precisa de um carro que saiba onde estão os freios.

Continue lendo

• IA não é uma coisa só: modelo, agente, automação e harness: o vocabulário básico antes de desenhar a arquitetura.
• IA no cotidiano não basta: eu construí uma operação: como sair do uso pontual e pensar em capacidade operacional.
• A melhor resposta não é a que mais me agrada: o contrato de qualidade que orienta meus agentes.
• O ChatGPT já sabe muito sobre você. Antes de confiar, mande ele provar: como transformar contexto pessoal em regra revisável.
• Hipótese não vira fato só porque a IA repetiu com convicção: o recibo necessário quando uma premissa governa uma ação.
• Agentes genéricos podem ser seu pior primeiro contato com IA: por que uma demonstração não substitui descoberta.

Referências e limites de uso

As referências abaixo explicam práticas e terminologia de plataformas específicas. Não provam que todo harness funciona igual, nem que qualquer arquitetura elimina erro, risco ou responsabilidade humana.

• OpenAI, “Unrolling the Codex agent loop”: descreve o ciclo entre usuário, modelo e ferramentas que a OpenAI chama de Codex harness; é uma descrição de produto e engenharia da própria OpenAI.
• OpenAI, “Harness engineering: leveraging Codex in an agent-first world”: relata como documentação, estrutura de repositório, testes e ciclos de feedback foram usados num projeto interno; não é uma receita universal nem uma promessa de resultado para outra empresa.
• Anthropic, “Building Effective Agents”: distingue fluxos de trabalho e agentes e descreve modelos ampliados por recuperação, ferramentas e memória; reflete recomendações de engenharia da própria empresa.
• National Institute of Standards and Technology (NIST), dos Estados Unidos — AI Risk Management Framework 1.0: framework voluntário para governar, mapear, medir e gerenciar riscos de IA; não certifica esta arquitetura nem substitui controles específicos.