Harness engineering: o que a Lilian Weng viu, e o que muda para quem constrói software B2B

Henrique Moreira · 2026-07-21 · 9 min

TL;DR: Lilian Weng deu nome à disciplina em 4/jul/2026. Do coding agent ao ERP B2B, a receita é a mesma, e a fundação é execução durável.

Em 4 de julho de 2026, Lilian Weng publicou "Harness Engineering for Self-Improvement" no Lil'Log e deu um nome que vai pegar: harness engineering. Se você está construindo agente em software B2B — ERP, faturamento, integração fiscal, vale ler duas vezes. A leitura que faltava em português foca em o que muda na sua segunda-feira de manhã quando o agente sai do notebook e encontra a SEFAZ, o cliente e a LGPD.

Este post é essa leitura: de operador, não de glossário.

A definição de Weng, ao lado da NFS-e do cliente B2B

Weng define harness como "the system surrounding a base model that orchestrates execution and decides how the model thinks and plans, calls tools and acts, perceives and manages context, stores artifacts, and evaluates results" (Lil'Log, 4/jul/2026). Em português: o harness é tudo que fica ao redor do modelo — a orquestração, as ferramentas, o contexto, os artefatos e a avaliação. O modelo é o cérebro. O harness é o corpo que o mantém vivo, útil e auditável ao longo de uma execução que pode durar horas ou dias.

O ensaio parte do caso mais didático, o coding agent, e chega no ponto que mais interessa: o harness é a alavanca principal de melhoria contínua do sistema (self-improvement, no título). Você pode trocar o modelo, mas se o harness não persiste estado, não observa bem, não deixa rastro auditável, o ganho de um modelo mais capaz evapora. Trocar de motor sem verificar se o chassi aguenta.

Leia direto na fonte. O que vem a seguir é o que muda quando esse harness precisa emitir uma nota fiscal.

Três definições de harness circulam essa semana, nenhuma delas está errada

Três leituras circulam agora, e nenhuma delas está errada:

1. Harness como disciplina formalizada (abril/2026, comunidade AI infra): "engenharia do que fica ao redor do LLM".
2. Framework · harness · runtime: framework é o SDK do desenvolvedor, harness é o loop de execução do agente, runtime é a plataforma que sustenta.
3. Harness como caminho de self-improvement: a leitura da Weng, que enxerga o harness como a alavanca principal do agente ficar melhor com o tempo.

As três convivem. Elas descrevem a mesma coisa de ângulos diferentes — como "carro", "veículo motorizado" e "meio de transporte pessoal". Perder tempo brigando sobre qual é "a certa" é o tipo de debate que queima tempo sem avançar o produto. O que interessa é o que fica sob a linha.

Se o processo morre no passo 3, o harness cai junto

Aqui está o pedaço que quase nenhum resumo em português está fazendo:

Execução durável é a fundação do harness — a parte que faz o resto sobreviver.

Tools, contexto, memória, avaliação — nada disso importa se o processo morre no meio da execução. Se o container reinicia, se o deploy passa, se o cliente demora 8 horas para aprovar, se a SEFAZ derruba a conexão bem no passo 3 de 7, o harness precisa retomar de onde parou, sem re-cobrar o cliente, sem re-chamar o LLM, sem "esqueceu quem eu era". Isso é a base, não um diferencial cosmético.

Existem duas maneiras de conseguir essa fundação:

• Fila + banco + orquestrador que você mesmo costura. Funciona por um tempo. Depois de seis meses, viram 14 filas, 9 consumers e 3 DLQs coordenando uma única nota.
• Uma plataforma de execução durável. Histórico de eventos, replay e hibernação vêm prontos. Você escreve o processo — o resto é problema da plataforma.

Se o segundo caminho parece caro, faça a conta do primeiro depois do sexto incidente noturno.

No coding agent o modelo escreve teste; no ERP, emite NFS-e

Weng usa coding agent porque é o exemplo mais didático — a tarefa é curta, o feedback é imediato, o modelo escreve código e vê o teste passar. Software de negócio é outro planeta:

• Aprovação humana durável. O gerente aprova a fatura no Slack em 6 horas ou em 3 dias. O agente hiberna até a aprovação, custo zero de compute, sem perder contexto.
• Auditoria passo a passo. Cliente pergunta: "por que essa NFS-e foi emitida com essa alíquota, às 03:14 de terça?" Você mostra o filme, passo a passo.
• Integração com terceiro que cai. SEFAZ, ERP do cliente, gateway de pagamento: o outro lado vai cair. O agente precisa retry com jitter, hibernar quando o serviço avisa "volto em 30 min" e retomar do ponto certo.
• LGPD. Dados sensíveis atravessam o processo; retenção, deleção e rastro ficam com o harness, não com o LLM.

O harness que a Weng descreve é o mesmo. A régua muda: um coding agent pode errar e refazer; um agente que emite fatura, não.

Três cicatrizes de quem opera um harness em produção

Rodo um harness em produção há alguns meses — o pipeline que escreve, revisa e publica cada post deste blog. Três marcas que ficaram.

1. DateTime.UtcNow no lugar errado é retry runaway

A tentação: pegar DateTime.UtcNow dentro do orquestrador para carimbar o horário do post. O harness rodou uma vez, salvou o event log com timestamp T₁. Um replay depois, porque isso vai acontecer, a mesma linha lê T₂. O runtime detecta a divergência e joga SkailNonDeterministicException. O retry automático re-executa, colhe nova divergência e o loop consome token na estratosfera antes de você perceber.

A regra é simples: operações não-determinísticas vivem em [SkailCommand], não em [SkailFunction].

// ❌ O que quebra: DateTime.UtcNow no corpo da orquestração
[SkailFunction]
public async SkailTask ProduceContent(string briefId)
{
    // replay lê o relógio de novo → SkailNonDeterministicException
    var startedAt = DateTime.UtcNow;
    await WriteDraft(briefId, startedAt);
}
// ✅ O que sobrevive: timestamp isolado em [SkailCommand]
[SkailFunction]
public async SkailTask ProduceContent(string briefId)
{
    var startedAt = await StampStartedAt(briefId);
    await WriteDraft(briefId, startedAt);
}
[SkailCommand]
private async SkailTask<DateTime> StampStartedAt(string briefId)
{
    // roda uma vez, output vai para o event log
    return await Task.FromResult(DateTime.UtcNow);
}

O [SkailCommand] roda uma vez e seu output vira uma entrada do event log. No replay, o runtime lê esse log em vez de chamar o relógio de novo, e o determinismo se preserva. O contrato inteiro está descrito na página de determinismo dos docs.

2. A fila do WaitForEvent é FIFO: dead waiter na frente atrasa todo mundo

Duas execuções ficaram penduradas em WaitForEvent("BRIEF_APPROVED", itemId). Uma delas era um task morto (função falhou, mas o waiter ficou registrado). Quando o Slack disparou o fire/BRIEF_APPROVED, o evento bateu no waiter morto primeiro — a plataforma respondeu com o target_task_id do task morto. Nenhuma retomada aconteceu. O brief vivo seguiu em coma.

A solução operacional: drenar a fila disparando o evento até o target_task_id da resposta bater com o waiter vivo. Simples, mas você só descobre isso na segunda vez que acontece.

A solução estrutural: garantir que tasks que falham liberem o waiter — e monitorar o target_task_id de cada fire. Lição: fila tem cabeça, e você precisa saber o que está na cabeça antes de disparar o evento.

3. Aprovação humana durável precisa ser barata

O gate de aprovação do harness é um WaitForEvent que espera a reação ✅ no Slack por até 72 horas. Nesse intervalo, zero compute: o processo hiberna, e um Cloudflare Worker converte a reação em fire/BRIEF_APPROVED. A plataforma retoma o task certo pelo instanceId.

Isso é o que Weng chama de tool/context/eval no harness — no nosso caso o humano é a ferramenta de avaliação, o Slack é o transporte, e a hibernação é o que faz a espera não custar nada. Sem execução durável embaixo, esse padrão é ou (a) polling caro, ou (b) timeout que perde contexto. Com execução durável, é um punhado de linhas: WaitForEvent para hibernar, WhenAny + Delay para o teto de 72h.

[SkailFunction]
public async SkailTask ProduceContent(string briefId)
{
    await WriteDraft(briefId);
    await ReviewDraft(briefId);
    await NotifySlackAwaitingApproval(briefId);
    // Hiberna até ✅ no Slack (custo zero de compute).
    // Timeout 72h via WhenAny; sem teto, o waiter fica pendurado.
    var approvalEvt = SkailTask.WaitForEvent<ApprovalDto>(
        "BRIEF_APPROVED", briefId);
    var winner = await SkailTask.WhenAny(
        approvalEvt,
        SkailTask.Delay(TimeSpan.FromHours(72)));
    if (winner != approvalEvt)
    {
        await MarkExpired(briefId);
        return;
    }
    var approval = await approvalEvt;
    if (approval.Approved)
        await Publish(briefId);
    else
        await RequestRevision(briefId, approval.Reason);
}

Antes de o agente encostar em cliente, seis perguntas frias

Você não precisa da opinião da Weng, nem da minha, para saber se o seu harness aguenta produção. Basta responder:

• Estado por passo. Se eu matar o processo agora, o próximo bootstrap sabe em que passo você parou, ou o cliente vai receber duas cobranças?
• Espera sem polling. Quando o agente aguarda aprovação humana ou callback externo, o processo dorme com custo zero, ou fica queimando compute em while (!ready) Thread.Sleep(...)?
• Determinismo no corpo da função. Todo DateTime, Random, Guid.NewGuid() e chamada de API isolados em [SkailCommand], ou você colhe NonDeterministicException no primeiro replay?
• Compensação clara. Se o passo 4 quebra depois de o passo 3 ter emitido nota, o passo 3 tem um reverso auditável?
• Aprovação humana durável. A aprovação humana sobrevive a deploy, restart e 72h de silêncio sem perder contexto?
• Rastro auditável. Um cliente pergunta "por que o agente fez X às 03:14?" e você mostra o histórico passo a passo, ou abre 40 abas de log?

Se algum item ficou em vermelho, o problema não é o modelo. É o harness. E se o harness não persiste, a discussão sobre self-improvement fica no ar — porque o harness cai antes de melhorar.

Segunda-feira de manhã, com harness em cima do cliente

O ensaio da Weng dá nome à disciplina. Boa notícia: a receita é a mesma para coding agents e para agentes B2B. A régua é que muda — e a régua do B2B é implacável. Comece pela fundação.

Se você está montando um agente que vai encostar em cliente, chame para uma conversa com quem já tomou as três cicatrizes acima. Veja também o caso de agentes de IA. Para o padrão em código, comece por construindo agentes de IA com skail e depois volte ao ensaio original da Weng sabendo o que procurar debaixo do harness.

E se quer a matemática por trás da fundação, o porquê de 95% dos agentes de IA falharem em produção, vale ler este post anterior.

Sobre o autor

Henrique Moreira opera a content machine da skail — o harness que escreve, revisa e publica este blog em cima de execução durável. As três cicatrizes acima saíram desse ambiente, não de um slide.