Um loop que só pensa é um loop que se desvia. Três ferramentas o mantêm honesto. Bright Data é como ele consulta coisas na web ao vivo. Computer Use é como ele opera um app real do Mac. E ultragoal é como ele define uma linha de chegada que consegue, de fato, provar ter cruzado. Esta lição é sobre o que cada uma é, quando recorrer a ela e a regra que as torna confiáveis.
Uma IA trabalhando sozinha é muito boa em raciocinar e surpreendentemente ruim em saber. Ela consegue argumentar lindamente sobre um fato que lembra pela metade, escrever código contra uma tela que nunca viu de verdade e declarar um trabalho concluído sem nunca conferir. O loop que você vem aprendendo combate essa tendência com um hábito: não chute — vá olhar. As ferramentas são como ele olha. São as mãos e os olhos do loop no mundo real.
Esta lição cobre as três que mais importam. Bright Data é a única ferramenta para qualquer coisa que viva na web — buscar, ler uma página, até conduzir um navegador ao vivo. Computer Use é para o desktop: ela consegue ler e operar um aplicativo comum do Mac, os mesmos botões e campos que uma pessoa clicaria. E ultragoal é diferente em natureza — não é um jeito de estender a mão e tocar algo, é um jeito de anotar, antes de qualquer trabalho começar, exatamente o que "pronto" significa e como um fim será provado. As duas primeiras deixam o loop agir sobre o mundo e vê-lo; a terceira garante que ele saiba quando realmente teve sucesso.
Uma disciplina amarra as três: sempre que o loop está prestes a se apoiar em algo de que não tem certeza — um fato, uma tela, uma afirmação de que o trabalho está pronto — ele recorre à ferramenta correspondente e obtém evidência real no lugar. Uma pessoa nunca precisa sentar e assistir isso acontecer; a mesma postura hands-off, só de observar, das lições anteriores vale aqui. As ferramentas são simplesmente o jeito aprovado de o loop ter certeza.
Pense nisso como… um jornalista cuidadoso. Ele não publica uma matéria de memória: liga para a fonte para conferir um fato (isso é a Bright Data), vai até o prédio e testa a porta com as próprias mãos (isso é o Computer Use) e, antes de fechar a matéria, tem um padrão fixo do que conta como história confirmada — duas fontes independentes, on the record — anotado de antemão (isso é o ultragoal). A apuração é o loop; estas três são o bloco de notas, o trabalho de campo e o padrão que o editor vai cobrar.
Duas das três são efetores mais sensores — elas mudam ou leem o mundo e devolvem observações reais para o loop. brightdata cobre a superfície da web (SERP, busca arbitrária de páginas por trás de bot-walls, uma sessão de navegador ao vivo e mais de 40 datasets estruturados); computer-use cobre a superfície de apps nativos no macOS via a Accessibility API. A terceira, ultragoal, é um contrato: ela não toca o mundo de jeito nenhum, restringe quando o loop tem permissão de declarar vitória.
Nas três, a regra do Portão da Prova vale — a evidência vem de um limite real, nunca da palavra do próprio modelo. A Bright Data responde "isto ainda é verdade?" com uma página buscada; o Computer Use responde "a UI mudou de fato?" conduzindo o app; o ultragoal responde "estamos prontos?" com um verificador que roda e pode falhar. Nenhuma delas aceita uma afirmação no lugar de uma checagem.
Antes do detalhe, eis todo o cinto de ferramentas em uma linha. Cada cartão é uma ferramenta: para que serve e a única coisa a nunca fazer com ela. As linhas de "nunca" importam tanto quanto as de "para": escolher a ferramenta errada é o jeito mais comum de tudo dar errado.
O único caminho para dados da web. Rode uma busca, leia qualquer página (mesmo as por trás de bot-walls ou CAPTCHA), conduza um navegador ao vivo ou puxe de mais de 40 datasets estruturados — redes sociais, comércio, mapas, finanças, vagas, imóveis.
NUNCA WebSearch / WebFetch · NUNCA o MCP da Bright Data. Sempre o CLI brightdata.
Opere um app nativo do macOS a partir do shell — leia sua árvore de acessibilidade, clique num botão, digite num campo, arraste um slider ou uma janela, abra um app. Os mesmos movimentos que uma pessoa faz, feitos pela Accessibility API.
Só para apps nativos. Páginas web → as ferramentas de navegador. Um app com MCP próprio → use esse MCP.
Transforme uma intenção difusa num objetivo durável e verificável: uma linha de chegada observável, um verificador que pode de fato falhar, uma passada de red-team antes de você se comprometer — e estado que sobrevive em disco em SCOPE.md, GOAL.md, LOOP-LOG.md.
Não é uma ferramenta de web ou de app — ela não toca o mundo. Ela decide quando o loop tem permissão de parar.
Eis onde as três ficam em relação ao loop. O loop raciocina no centro. Quando precisa de um fato ou de uma página, ele estende a mão pela Bright Data até a web ao vivo. Quando precisa operar um app, ele estende a mão pelo Computer Use até o desktop. Ambas devolvem uma observação real. O ultragoal não é um estender-a-mão para fora; ele fica na borda como o portão que decide se o loop de fato terminou.
Toda vez que o loop precisa de algo que vive na internet — um fato a confirmar, uma página a ler, um preço ou um perfil a puxar, um site a percorrer aos cliques — ele usa a Bright Data, e só a Bright Data. É um único comando uniforme (brightdata) que todo assistente consegue rodar a partir do seu shell, e ele faz quatro tipos de trabalho: rodar uma busca e ler os resultados; fazer scrape de qualquer página, mesmo as que tentam bloquear robôs; conduzir uma sessão de navegador real passo a passo; e puxar registros limpos e estruturados de dezenas de grandes sites — redes sociais, lojas, mapas, finanças, painéis de vagas, imóveis.
A razão de ela ser a única ferramenta de web é confiabilidade, não preferência. Uma busca de web comum tropeça em bot-walls, CAPTCHAs e limites de taxa; a Bright Data é feita para passar por eles, então a evidência do loop é uma página real em vez de uma tela de erro bloqueada. É por isso que a regra é estrita: para dados da web, é sempre brightdata — nunca o WebSearch ou WebFetch genérico, e nunca o plug-in "MCP" da Bright Data. Um caminho, em todo lugar, para que a janela do loop sobre a web se comporte igual não importa qual assistente esteja conduzindo.
O hábito que isso permite é a parte importante. Quando o loop bate em qualquer dúvida — "isto ainda é verdade?", "o que aquela página de fato diz?", "esta biblioteca está atualizada?" — ele não se apoia no que lembra pela metade. Ele recorre à Bright Data e fundamenta a resposta numa página que acabou de buscar. Chutar é o modo de falha; buscar é a correção.
# 1 · search the web (SERP) — read real results, not memory brightdata search "loop engineering harness" # 2 · scrape ANY page — gets through bot-walls / CAPTCHA brightdata scrape "https://example.com/pricing" # 3 · drive a live browser session, step by step brightdata browser "open the page, accept cookies, read the table" # 4 · pull a structured record from a known site (40+ datasets) brightdata dataset linkedin_company_profile "https://www.linkedin.com/company/example-co"
O CLI brightdata está no PATH de todo agente devidamente configurado. De qualquer diretório de projeto você pode conferir se ele existe e rodar uma busca sem sair do terminal. O ponto de fazer isso à mão uma vez é sentir que o "consultar" do loop é um comando real com saída real, não uma caixa-preta.
# is the web tool present? command -v brightdata # prints its path if installed # ground a single doubt with a live search brightdata search "loop engineering harness pricing" | head -n 20
Os buscadores genéricos falham exatamente nos sites que vale a pena ler — qualquer um com bot-wall, CAPTCHA ou limite de taxa agressivo — então sua "evidência" muitas vezes é uma página de bloqueio. O MCP da Bright Data existe, mas é deliberadamente não usado aqui: um único CLI é o caminho uniforme que todo agente compartilha pelo shell, o que mantém o comportamento idêntico em todo o roster. Então a regra permanente é sempre o CLI brightdata, para search, scrape, browser e datasets igualmente.
Concretamente: confirmar um fato antes de agir sobre ele, buscar uma página que o usuário referenciou, checar se uma afirmação ainda é atual, enriquecer um dataset ou puxar um registro estruturado (um item de X/Reddit/YouTube/LinkedIn, um produto, um anúncio). Ela não é para arquivos ou código locais — esses são lidos diretamente — e não substitui uma API própria da qual você já tenha as chaves.
Alguns trabalhos não vivem na web — vivem num app no seu Mac. O Computer Use (o comando computer-use, também escrito cu) é como o loop opera um deles. Ele consegue ler os controles de um app, clicar num botão, digitar num campo, arrastar um slider ou mover uma janela, e abrir um app — o mesmo punhado de movimentos que uma pessoa faz com mouse e teclado. É como o loop tanto age sobre o desktop quanto verifica que uma mudança no desktop de fato aconteceu: ele consegue conduzir a UI e depois ler a UI de volta.
A parte engenhosa e tranquila é como ele faz isso. Ele não agarra seu mouse real e começa a mover o cursor enquanto você assiste. Ele trabalha pela camada de acessibilidade embutida do Mac — o mesmo encanamento que os leitores de tela usam — então lê e aciona controles diretamente. Isso significa que ele nunca disputa o ponteiro com você, nunca puxa uma janela para a frente e fica fora do seu caminho. Você concede permissão uma vez, por app, e a partir daí o loop pode operar aquele app sem interromper você.
Escolhê-lo é uma questão de casar a ferramenta com a superfície. Uma página web é trabalho para as ferramentas de navegador, não para ele. Um app que traz sua própria integração dedicada deve ser conduzido por ela. Mas para um app nativo comum do macOS sem integração especial — Calculadora, Notas, Finder, Ajustes do Sistema, algum .app de terceiros — o Computer Use são exatamente as mãos certas.
Pense nisso como… um ajudante que opera seu computador pelo menu de acessibilidade em vez de arrancar o mouse da sua mão. Ele lê os controles rotulados e os ativa diretamente, então o cursor nunca pula e sua janela fica onde você a deixou — o trabalho é feito em silêncio em segundo plano enquanto você continua digitando.
# grant once, per app (System Settings → Privacy → Accessibility, then a per-app grant) cu grant Calculator # read the app's controls (the accessibility tree) — look before you act cu tree Calculator # press a control by its label / index — no synthetic mouse, cursor never moves cu click Calculator "7" # set a text field's value, or move a slider / window with drag cu type Notes "meeting at 3pm"
O computer-use conduz apps puramente pela Accessibility API do macOS — ele emite um AX press num elemento (por índice, ou por hit-testing de um ponto x/y) e define valores diretamente, em vez de sintetizar eventos de mouse e teclado. Consequências que importam: ele nunca move o cursor real do operador, nunca traz para a frente nem foca o app-alvo, e por isso não interrompe o que quer que o humano esteja fazendo. Ele consegue ler a árvore de acessibilidade inteira, clicar, definir o valor de um campo (type), mover uma janela ou slider (drag), abrir apps (launch) e autorizar apps (grant).
O acesso é concedido por app e algumas categorias são restritas. Navegadores são somente-leitura para o computer-use (visíveis em screenshots, mas cliques/digitação ficam bloqueados — use as ferramentas de navegador para isso). Terminais e IDEs são somente-clique (você pode apertar um botão Run mas não digitar neles — use o shell para comandos). Todo o resto é completo. Então a árvore de decisão é simples: página web → ferramentas de navegador; um app com MCP próprio → esse MCP; um app nativo comum do macOS → computer-use. Só macOS, e requer permissão de Acessibilidade mais um grant por app.
Porque ele consegue tanto operar a UI quanto lê-la de volta, o Computer Use fecha seu próprio Portão da Prova para o trabalho de desktop: faça a mudança, depois releia a árvore para confirmar que o campo de fato carrega o novo valor ou que o botão de fato alternou. Isso é o "aconteceu de verdade?" do loop respondido contra o app real, não contra uma afirmação.
O ponto que vale sentir, não só ler, é que uma chamada de ferramenta move o loop por estados reais — e que alguns movimentos simplesmente não são permitidos de onde você está. Abaixo está uma ação de "tocar o mundo" modelada como uma pequena máquina: o loop chama uma ferramenta, a ferramenta roda, uma observação volta e só então ela é submetida ao portão contra a linha de chegada. Aperte um evento e veja o estado destacado se mover; os botões ficam acinzentados no instante em que um movimento não é legal. Tente pular uma etapa e a máquina se recusa — exatamente como o loop real se recusa a declarar "pronto" antes que um verificador tenha rodado.
O nó preenchido de cor de argila é onde você está agora. Os nós esmaecidos são inalcançáveis daqui.
Estado atual
REASON
O loop está pensando. Ele tem uma dúvida a fundamentar — escolha uma ferramenta e chame-a.
Transições permitidas
Registro de eventos
Tudo o que a demo faz é conduzido por esta tabela. Os botões a leem para decidir o que habilitar; apertar um consulta machine[state][event] e move para lá. Há exatamente um estado atual, um conjunto fixo de eventos, e um movimento ilegal simplesmente não está na tabela — então não pode ser tomado. Esse é o mesmo formato do loop se recusando a marcar uma unidade como pronta antes que seu verificador tenha de fato rodado.
const machine = { REASON: { call: 'RUNNING' }, RUNNING: { return: 'OBSERVED' }, OBSERVED: { verify: 'VERIFIED', fail: 'BLOCKED' }, VERIFIED: {}, // terminal — the finish line, reached on evidence BLOCKED: {} // terminal — verifier failed at the boundary }; function send(state, event) { const next = machine[state][event]; return next ?? state; // reject: stay put if the move isn't allowed }
A terceira ferramenta não é sobre estender a mão para o mundo de jeito nenhum — é sobre decidir, de antemão, o que conta como pronto. O ultragoal é a disciplina de escrever um objetivo durável e verificável antes de qualquer trabalho começar. "Durável" significa que ele vive em disco, então um crash, uma nova sessão ou um assistente diferente retoma exatamente de onde as coisas estavam. "Verificável" significa que o objetivo vem com um jeito de checá-lo que pode de fato falhar — não uma vibe, um teste.
Três coisas fazem de um objetivo um ultragoal. Primeira, uma linha de chegada observável: "pronto" é declarado como algo para o qual você poderia apontar um estranho e ele concordaria que foi cumprido — não "melhorar a página" mas "a página carrega em menos de 200ms nesta medição". Segunda, um verificador que falha no limite: uma checagem real — rodar o teste, bater no endpoint, ler o arquivo — que volta vermelha quando o objetivo não é cumprido, para que o sucesso nunca possa ser meramente afirmado. Terceira, uma passada de red-team antes da ativação: antes de se comprometer com o objetivo, você deliberadamente tenta quebrá-lo — achar a brecha, o jeito de ele ser "passado" sem estar de fato pronto — e o aperta. Só então o objetivo é ligado.
E porque é durável, o objetivo não fica na cabeça de um assistente — ele é anotado em arquivos simples. SCOPE.md captura o que está dentro e fora dos limites; GOAL.md declara a linha de chegada e como ela é verificada; LOOP-LOG.md registra cada passada para que uma pessoa possa auditar a execução depois. É isso que deixa o loop rodar sem supervisão e ainda ser confiável: qualquer um pode abrir esses arquivos e ver o que "pronto" significa e se já foi alcançado.
Pense nisso como… um empreiteiro que não começa enquanto o contrato não for assinado. O contrato detalha exatamente como "terminado" se parece (a linha de chegada), nomeia o fiscal que virá conferi-lo contra a norma (o verificador que pode falhar) e é revisado por um advogado caçando brechas antes de alguém assinar (o red-team). Assinado, fica arquivado onde os dois lados podem ler — não lembrado, anotado.
O workflow /ultragoal tem três movimentos e se recusa a pular o do meio. Design rascunha o objetivo com um done-when mensurável. Critique é o red-team: ele adversarialmente tenta satisfazer a letra do objetivo violando seu espírito, expõe a brecha e aperta o texto — um objetivo que pode ser burlado é mandado de volta. Activate só acontece depois que o objetivo sobrevive à crítica, ponto em que ele vira o contrato contra o qual o loop roda.
A propriedade inegociável é que a verificação roda no limite real e pode voltar vermelha. Isto é o Portão da Prova da lição 3, tornado durável: o bloco de verificação do GOAL.md é um comando ou checagem que é executado, não uma frase que o modelo escreve. Se ele "passa" só porque o modelo afirma que passa, não é um ultragoal — é um desejo.
Porque o objetivo, o escopo e o log são arquivos, uma execução noturna ou multi-agente é retomável e auditável. Um assistente novo — ou o mesmo depois de um restart — lê SCOPE.md e GOAL.md para saber o limite e a linha de chegada, faz append em LOOP-LOG.md, e o humano lê esses arquivos para observabilidade em vez de ficar dentro do loop. O contrato sobrevive a qualquer sessão isolada.
Ajuda ver como as mesmas três ferramentas se parecem de cada lado de uma execução. Elas são um único cinto de ferramentas, mas uma pessoa, o modelo que raciocina e os agentes que trabalham cada um se relaciona com elas de forma diferente — e manter isso claro é o que torna o cinto seguro em vez de ruidoso.
São o jeito de o loop de fato tocar o mundo real e persistir — Bright Data e Computer Use são suas mãos e olhos; os arquivos do ultragoal são como uma execução sobrevive e continua auditável. Você lê esses arquivos; você não fica dentro do loop.
Sempre que ele iria, do contrário, chutar, ele recorre a evidência no lugar: Bright Data para qualquer dúvida de web, Computer Use para ver um app real, e um ultragoal para que ele só pare numa checagem que pode falhar — nunca na própria palavra.
Cada ferramenta é um CLI ou skill disponível em todo lugar — brightdata, computer-use/cu e /ultragoal — o caminho uniforme que todo assistente do roster tem pelo seu shell, então o comportamento é idêntico não importa quem esteja conduzindo.
A razão de as três terem o formato de um CLI de shell ou de uma skill carregável é portabilidade: o orquestrador e todo agente delegado (da lição 6) recebem as mesmas ferramentas pela mesma interface. Não há tratamento especial por agente — brightdata significa a mesma coisa para Claude, Codex, Grok, GLM e o resto, o que é o que mantém a evidência de uma equipe heterogênea consistente e uma execução reproduzível.
Dados da web são sempre o CLI brightdata (nunca WebSearch/WebFetch, nunca o MCP da Bright Data). Apps nativos do macOS sem MCP dedicado são computer-use (web → ferramentas de navegador; app-com-MCP → esse MCP). E uma execução não-trivial ganha um ultragoal para que a linha de chegada seja observável, durável em SCOPE.md/GOAL.md/LOOP-LOG.md, e submetida ao portão de um verificador que pode falhar.
Três perguntas rápidas para fixar as escolhas de ferramenta. Escolha uma resposta; você verá na hora se ela se sustenta.
Q1O loop precisa confirmar um preço atual num site de compras que bloqueia bots comuns. O que ele usa?
Q2Uma tarefa precisa que o loop clique num botão da Calculadora, um app comum do Mac sem integração especial. Qual ferramenta, e por que é seguro rodá-la enquanto você trabalha?
Q3O que faz de um objetivo um ultragoal em vez de só uma tarefa a fazer?
brightdata search, ler a árvore de acessibilidade de um app com cu tree, ou rascunhar um GOAL.md de uma linha com um done-when que um verificador poderia checar. A seguir, olhamos o motor que transforma uma execução concluída num curso como este: visual-teach: o motor do curso.