Neste harness, o trabalho corre AFK — longe do teclado. O loop inteiro — aprender, construir, verificar, decidir — corre sem uma pessoa alimentando o próximo movimento. Seu papel muda de operador para observador: você lê o que aconteceu, não aperta os botões. A máquina só para por você em um tipo específico de decisão — e nunca para te entregar uma tarefa.
AFK significa away from keyboard (longe do teclado). Na maioria das ferramentas, "a IA te ajuda a trabalhar" significa um vai-e-vem apertado: ela faz um pouco, depois para e espera você digitar a próxima instrução, aprovar o próximo passo, clicar no próximo botão. Este harness é construído ao contrário. Uma vez que o objetivo é definido, o loop conduz o trabalho inteiro — descobrir o estado, fazer uma mudança, provar que funcionou, decidir se continua — por conta própria, passo após passo, sem uma pessoa no meio.
Então o que sobra para o humano? Observabilidade. Essa é uma palavra pomposa para uma promessa simples: a qualquer momento você pode ver exatamente o que o sistema fez e está fazendo, sem ter de participar disso. Você lê um log em andamento, você lê um relatório, você confere uma linha de status. Você é uma pessoa parada numa janela observando uma cozinha, não um cozinheiro na estação. O trabalho não pausa porque você desviou o olhar, e não precisa das suas mãos para continuar.
Isso importa porque a falha que ele evita é muito comum. No momento em que um sistema precisa de um humano para avançar — "aguardando aprovação", "por favor confirme", "o que devo fazer agora?" — ele deixa de ser autônomo. Ele vira uma coisa que só corre tão rápido quanto você consegue cuidar dela, e estagna no instante em que você sai. O harness recusa isso. O padrão é: continuar, deixar um rastro, e só parar pelo humano em um tipo bem específico de decisão (chegaremos a qual exatamente).
Há mais uma metade da regra, e é a parte que as pessoas entendem ao contrário. O humano não só fica de fora do fazer — o humano também nunca recebe a checagem. O sistema não termina seu trabalho e então se vira para você com uma lista de tarefas "agora teste isto, por favor". A verificação é trabalho da máquina também. Sua leitura é para o seu próprio entendimento e confiança; ela nunca é uma fila de tarefas que os agentes descarregaram em você.
Pense nisso como… o painel de um carro autônomo versus ser o instrutor de direção com o segundo freio. Um painel mostra velocidade, rota e o que o carro enxerga — você fica informado, e pode assumir se algo genuinamente exige um humano, mas você não está dirigindo, e o carro não te pede para avaliar a baliza depois. O harness te coloca no banco do passageiro com um ótimo painel, não no banco do instrutor pisando nos pedais. Onde a analogia se quebra: um carro pede que você assuma por causa de perigo; este harness te puxa apenas para uma decisão que é propriamente sua — não porque travou.
Toda tarefa não-trivial nesta suíte é conduzida pelo loop, e o loop é projetado para correr sem supervisão: LEARN → ANALYZE → EXECUTE one bounded unit → VERIFY at the real boundary → DECIDE, repetido até convergir no done-when mensurável do Portão de Escopo (lição 3). Nada nesse ciclo trava por causa de uma pessoa. DECIDE escolhe "ir de novo" ou "convergiu" a partir de evidência que o próprio loop reuniu, não da palavra de um humano.
O humano lê três coisas e não escreve nada do trabalho: uma narrativa em andamento (LOOP-LOG.md), um relatório final de observabilidade (review.md) e uma leitura de status ao vivo. Esses são saídas append-only da execução — o humano consome, os agentes produzem. As mãos do humano nunca entram no caminho de execução; é isso que "nunca no caminho" significa.
Metade um: os LLMs nunca travam esperando um humano em trabalho de rotina. Metade dois: os LLMs nunca entregam ao humano uma tarefa de QA. Juntas elas forçam o sistema a ser genuinamente autônomo em ambas as direções — ele nem estagna por você nem delega sua checagem para você. A única exceção é uma bifurcação deliberada e bem definida, coberta na seção 8.
Três tipos de jogador dividem este palco, e o método inteiro funciona porque cada um fica na sua faixa. Vale nomeá-los claramente, porque a mágica do AFK é, na verdade, só uma divisão limpa de trabalho.
O humano — esse é você — faz exatamente uma coisa durante uma execução: observar. Você lê o log, você lê o relatório, você dá uma olhada no status. Você define o objetivo no início, e pode ser chamado de volta para uma decisão especial no fim, mas entre os dois você não executa e não testa. Os LLMs (os modelos conduzindo o trabalho) carregam a disciplina: eles nunca ficam parados esperando você em trabalho de rotina, e nunca se viram para te entregar uma tarefa de checagem — eles mantêm o loop girando e deixam um rastro atrás de si. Os agentes (o orquestrador e os trabalhadores a quem ele delega) fazem a construção e a prova, e emitem o relatório — review.md — como um registro do que foi observado sobre a execução, não como uma lista de afazeres apontada para você.
Leia o diagrama abaixo como três faixas que quase nunca se cruzam. O único lugar onde uma linha volta até o humano é a única bifurcação tracejada à direita — e isso é uma decisão, não uma tarefa.
Eis a ideia inteira em uma única forma. O loop gira por conta própria — cada passo alimenta o próximo, e "ir de novo" retorna ao início sem a permissão de ninguém. O humano fica ao lado do loop, lendo suas saídas, nunca conectado à corrente que o faz girar. A fiação proibida — a seta vermelha tracejada — é um humano colocado dentro do loop, onde a máquina teria de parar e esperar um clique para continuar. É exatamente isso que o AFK remove.
A única regra
Se o sistema tem de esperar um humano para dar seu próximo passo de rotina, ele não é AFK. O humano pertence ao lado do loop, lendo-o — nunca dentro do loop, alimentando-o.
"Observabilidade" só é real se há algo concreto para observar. Neste harness há três coisas, e essa é a lista inteira. Você não escava as entranhas nem prende um depurador; você lê três saídas simples que a execução mantém atualizadas para você.
Primeiro, LOOP-LOG.md — a narrativa em andamento. Cada passo do loop acrescenta algumas linhas: o que aprendeu, a única unidade que escolheu, o que mudou e como verificou. Lê-lo de cima a baixo é como ler o diário de bordo de um navio: você vê a jornada, em ordem, como aconteceu. Segundo, review.md — o relatório que o agente de QA escreve quando o trabalho converge. É um retrato de como a execução terminada se parece sob inspeção: o que foi checado, o que se sustentou, o que merece a atenção de um humano. Terceiro, a leitura de status — um "onde estamos agora mesmo" de uma olhada só: qual passo, convergido ou ainda correndo, qualquer bloqueio. Entre esses três você sempre sabe o passado (log), o veredito (review) e o presente (status) — sem nunca tocar nos controles.
Pense nisso como… acompanhar um longo cozimento pela porta de vidro do forno. O LOOP-LOG.md é o timer passando por cada estágio; a luz de status te diz que ainda está assando ou que ficou pronto; e o review.md é o bilhete que o padeiro deixa descrevendo como o pão saiu. Você aprende tudo o que precisa só olhando — nunca precisa abrir a porta e enfiar as mãos.
LOOP-LOG.md cresce em uma entrada por passo do loop e nunca é reescrito — essa imutabilidade é o que o torna confiável como registro. status é uma visão derivada (passo atual, flag de convergido, bloqueio aberto) que você pode imprimir a qualquer momento. review.md é produzido uma vez, na convergência, pelo validador — e, criticamente, por um agente que não é o que construiu o trabalho, então o relatório é uma leitura independente, não uma auto-avaliação.
Um console em streaming tentaria um humano a pular dentro e dirigir. Arquivos e um comando de status mantêm a relação de mão única: o humano puxa informação quando quer, e o loop nunca espera para ver se ele puxou. Puxe, não empurre; leia, não dirija.
A prova de que o VERIFY rodou no limite real (lição 3) é exatamente o que aterrissa nessas saídas. Observabilidade e o Portão de Prova são duas visões de uma só ideia: toda afirmação que a execução faz é respaldada por algo que um humano pode ir ler.
Esta é a regra pela qual os modelos vivem, dita o mais claramente possível. Em trabalho de rotina, um LLM nunca para para esperar um humano. Se ele esbarra numa bifurcação que pode resolver por evidência — qual arquivo, qual correção, se o teste passou — ele resolve e segue em frente, deixando o raciocínio no log. Ele não posta "me avise como você gostaria de prosseguir" e fica ocioso. Ficar ocioso na rotina é exatamente o comportamento que transforma um loop autônomo de volta num trabalho de babá.
A regra-espelho é igualmente importante: um LLM nunca entrega ao humano uma tarefa de QA. Quando o trabalho está feito, os agentes não se viram para você e dizem "por favor rode os testes" ou "você pode confirmar se isto está certo?". Checar o trabalho é parte do trabalho, e o trabalho pertence à máquina. O relatório que você lê depois é o resultado dessa checagem, já feita — não um pedido para você fazê-la. Se você alguma vez sentir que o sistema terminou te entregando lição de casa, algo deu errado com a disciplina.
Junte as duas e você tem o formato de um sistema genuinamente AFK: ele nem estagna esperando você, nem descarrega sua verificação em você. Ele corre, ele checa a si mesmo, ele anota o que aconteceu, e só estende a mão para você na única decisão que é verdadeiramente sua — que é a seção depois da próxima.
Rotina = qualquer coisa resolvível a partir do artefato, do escopo ou de uma fonte confiável. Um fato faltante é buscado (via Bright Data CLI para fatos da web, lição 9), não perguntado ao humano. Uma instrução ambígua é resolvida relendo o done-when, ou escolhendo a interpretação mais segura e registrando a escolha. Só uma decisão irreversível, para fora, ou de intenção de negócio tem permissão para deixar a faixa de rotina — essa é a bifurcação na seção 8.
O passo VERIFY é inegociável e nunca exportado. O validador que escreve review.md é ele próprio um agente na execução — geralmente um modelo diferente do construtor, então é uma checagem independente em vez de uma auto-avaliação — mas ainda é a máquina checando, não o humano. O humano lendo review.md está auditando confiança, não completando o plano de testes.
Onde uma fase tem perguntas, os agentes as respondem por conta própria e só elevam uma pergunta genuinamente author-only com uma recomendação anexada. O viés é fortemente em manter o humano fora do loop, precisamente para que o loop possa correr enquanto o humano está ausente.
Sinta a diferença. Abaixo estão duas formas de rodar o mesmo trabalho longo. O da esquerda não é AFK: ele para e espera um humano a cada passo de rotina, então as "crenças desatualizadas" do humano (e a estagnação) se acumulam quanto mais ele desvia o olhar. O da direita é AFK: ele continua rodando e simplesmente anota o que faz, então a imagem do humano fica fresca pela leitura — a custo zero para a execução. Aperte Próxima rodada algumas vezes e veja a distância abrir.
Para a cada passo de rotina para esperar um clique. No momento em que o humano desvia o olhar, o progresso estagna e a imagem dele fica desatualizada.
Continua rodando e acrescenta ao LOOP-LOG.md a cada rodada. O humano lê quando quer; a imagem nunca está desatualizada e a execução nunca esperou.
O tempo avança a cada rodada, esteja o humano olhando ou não. Só a execução AFK continua progredindo e mantém o humano informado — porque observar é só leitura.
async function round() { const step = plan(); await waitForHumanClick(); // stalls here until a person acts return run(step); }
async function round() { const step = plan(); const out = run(step); // keeps moving on its own appendTo("LOOP-LOG.md", out); // leaves a trail to OBSERVE return out; }
A diferença inteira é uma linha: apague o await waitForHumanClick() e substitua por um appendTo("LOOP-LOG.md", …). Esse único movimento transforma "um humano tem de estar no caminho" em "um humano pode ler o rastro" — autonomia mais observabilidade, em vez de babá.
Quando uma execução converge, um agente escreve review.md. É fácil interpretar errado para que serve esse arquivo, então vamos ser exatos. É um relatório: uma descrição de como o trabalho terminado se parece quando um agente independente o inspeciona. Ele enfaticamente não é uma lista de tarefas atribuída ao humano. Não há nenhum "TODO: testar o fluxo de login" te esperando ali, porque o teste já aconteceu — é sobre isso que o relatório está reportando.
Por que a distinção importa tanto? Porque no instante em que um relatório vira uma lista de afazeres, o humano está de volta no caminho. "Aqui estão cinco coisas para você verificar" é só babá usando um chapéu mais bonito — a execução não terminou de verdade, ela parou e delegou. Um relatório de observabilidade verdadeiro fecha o loop: ele diz isto foi feito, aqui está a evidência, aqui está o que um leitor externo deve saber. Você o lê para decidir se confia no resultado, não para descobrir o que ainda tem de fazer.
Pense nisso como… um laudo de inspeção predial quando você compra uma casa. O inspetor já subiu no telhado e abriu as torneiras — o laudo te diz o que ele encontrou para que você possa tomar uma decisão. Um bom inspetor te entrega as constatações; um ruim te entrega uma escada e diz "vá conferir o telhado você mesmo". O review.md são as constatações, nunca a escada.
# review.md — RHG search-handler run · converged ✓ ## What was checked (by the validator, not the human) - empty-query guard: covered — pytest test_empty_query_returns_400 now passes - regression suite: green — 12 passed, 0 failed (was 11 passed, 1 skipped) - real boundary: hit — curl "/search?q=" → 400, observed live ## How it looks under inspection - change is one bounded unit (a guard in api.py); no scope creep - LOOP-LOG.md trail is complete: 3 passes, each with proof ## For the reader's awareness (NOT tasks) - downstream callers of /search were not audited — out of this run's scope - consider a follow-up goal if empty-body POSTs need the same guard
Abra-o como qualquer arquivo: cat review.md, ou leia-o no seu editor. A seção "for the reader's awareness" é observabilidade, não atribuição — ela nomeia coisas que um leitor externo deveria saber, frequentemente explicitamente fora do escopo. Se você decidir que uma delas importa, isso vira um novo objetivo para uma execução nova, definido da forma normal — nunca é uma tarefa implícita que a execução deixou para você.
O agente validador — por política, não o agente que construiu a mudança — então o relatório é uma leitura independente. Numa execução multi-agente o construtor e o validador são modelos diferentes; o humano lendo o relatório é a terceira checagem, a mais externa, auditando confiança em vez de fazendo QA.
Existe exatamente uma situação em que a execução autônoma vai deliberadamente pausar e puxar o humano. Não é porque travou, e não é porque quer que você teste algo. É uma bifurcação só do usuário: uma decisão que é genuinamente sua de tomar porque é irreversível, alcança para fora, no mundo, ou expressa intenção de negócio que o sistema não consegue inferir.
Exemplos: publicar algo público, enviar dinheiro, apagar dados que não podem ser recuperados, escolher entre duas direções que são ambas válidas mas significam coisas diferentes para o negócio. Essas não são rotina — nenhuma quantidade de leitura do artefato te diz qual delas o humano quer. Então o loop para, mas para da forma certa: através de um handoff deliberado, apresentado pronto para decisão. Isso significa que o sistema já fez toda a lição de casa — reuniu os fatos, dispôs as opções e anexou sua recomendação — para que o humano faça uma escolha limpa e o loop retome. Você está respondendo a uma pergunta bem formulada, não pegando uma tarefa abandonada.
Todo o resto — toda bifurcação de rotina — o loop resolve por conta própria. Essa única exceção, estreita, é o único fio que vai do loop de volta às mãos do humano, e mesmo então ele te entrega uma decisão, totalmente preparada, nunca uma tarefa.
Pense nisso como… um piloto automático que voa a rota inteira, mas para uma coisa pergunta ao comandante: "Dois aeroportos de desvio válidos, aqui estão clima, combustível e minha recomendação — sua decisão." Ele não pede ao comandante para voar; não pede ao comandante para re-checar seus instrumentos. Ele faz o único julgamento que só um humano deveria ter, e o faz totalmente instruído.
No front-end Forge (lição 4) este é o mecanismo de handoff: a execução trava apenas numa bifurcação só do usuário e a apresenta pronta para decisão. Em todo o resto o viés é auto-responder e seguir em frente. "Pronto para decisão" é uma barra dura — um handoff que só diz "e agora?" é um defeito; ele tem de carregar os fatos reunidos, as opções dispostas e uma recomendação.
Uma decisão ganha um handoff se for irreversível (não pode ser desfeita de forma limpa — deletes destrutivos, envios), para fora (deixa o sandbox em direção ao mundo — publicação, dinheiro, terceiros) ou intenção de negócio (codifica uma preferência que o sistema não consegue ler do artefato ou do objetivo). Falhe os três e é rotina: o loop decide e registra.
Eis como a observabilidade se parece como as coisas reais que você faria enquanto uma execução está em curso — todas elas leituras, nenhuma delas direção. Você acompanha o log, você imprime o status, você lê o relatório quando ele chega. Note que não há comando aqui que avance o trabalho; esse é o ponto.
# watch the running narrative as passes append to it tail -f LOOP-LOG.md # one-glance: which pass, converged or going, any blocker cat status # or: ./status # when it converges, read the independent report (findings, not chores) cat review.md # there is NO "advance" command — the loop moves itself. # the human only ever acts at a decision-ready handoff.
A partir do diretório de trabalho da execução: tail -f LOOP-LOG.md acompanha a narrativa ao vivo; cat status imprime o passo atual e a flag de convergência; cat review.md lê o relatório do validador assim que ele existir. Os três são leituras puras — rodá-los nunca muda a execução nem a desbloqueia.
Não existe, intencionalmente, nenhum comando loop next ou approve para trabalho de rotina. O único ponto de ação humana na execução inteira é o handoff numa bifurcação só do usuário (seção 8), e esse é trazido a você explicitamente, pronto para decisão. Se você se pegar procurando um botão para apertar para manter as coisas andando, o sistema está te dizendo que não precisa de um.
Vamos assistir a uma execução de formato real inteiramente do assento do observador. O objetivo foi definido à noite: "fazer /search rejeitar uma query vazia com um 400." Você vai dormir. Eis todo o seu envolvimento — quatro momentos de leitura, e exatamente uma decisão.
Você escreve o done-when e inicia a execução. A partir daqui você não digita outra instrução. O loop assume: LEARN lê o repositório, ANALYZE escolhe uma unidade, EXECUTE adiciona o guard, VERIFY atinge o endpoint real. Você está dormindo durante tudo isso.
O agente está em dúvida se o Flask devolve None ou "" para um parâmetro vazio. Isso é rotina — um fato que vive na web — então ele o fundamenta via Bright Data CLI e escreve a resposta no LOOP-LOG.md. Ele não esperou por você. Reversível, inferível, interno: o loop decide e registra.
tail LOOP-LOG.md mostra três passos limpos, cada um com prova. cat status lê converged ✓. cat review.md é um relatório independente: guard coberto, 12 passados, limite real atingido em /search?q=. Ninguém te entregou um teste para rodar — já estava feito. Você está auditando confiança, não fazendo QA.
O review.md anota uma bifurcação só do usuário aguardando: a correção está pronta para ser publicada publicamente, e publicar é para fora e irreversível. O handoff está pronto para decisão — diff resumido, risco anotado, recomendação: "ship". Você responde uma vez. O loop retoma e publica. Esse único clique é a única vez em que a execução precisou das suas mãos.
O que o humano fez a noite toda
Definiu um objetivo, leu três arquivos, respondeu uma pergunta pronta para decisão. Zero passos de rotina, zero tarefas de QA. O loop correu AFK de ponta a ponta; a observabilidade te contou tudo; a única bifurcação que era verdadeiramente sua foi entregue a você totalmente preparada. É isso que é o humano ficar fora do caminho.
# LOOP-LOG.md — fix/empty-query (AFK, no human in the path) [pass 1] LEARN api.py:42 has no empty-q guard; suite 11 passed, 1 skipped [pass 1] ANALYZE pick ONE unit → add guard returning 400 on empty q [pass 1] EXECUTE added guard in api.py [pass 1] VERIFY curl "/search?q=" → 400 (real boundary) · pytest 12 passed [pass 1] DECIDE done-when met → converged [fork] user-only: publish (outward, irreversible) → decision-ready handoff # human answered: ship → loop resumed → published. no QA delegated.
Lembrar vence reler. Responda cada uma de memória antes de espiar — a opção que você escolher é corrigida na hora, com uma nota do porquê. Sem pistas na formatação; as respostas estão espalhadas de propósito.
Q1Durante uma execução AFK de rotina, qual é o trabalho do humano?
Q2Um LLM esbarra numa bifurcação de rotina que pode resolver pelo artefato. O que ele faz?
Q3O que é o review.md?
Q4Qual decisão tem permissão de pausar o loop por um humano?
Q5O que "pronto para decisão" significa para um handoff?
cli -p.