The tools: Bright Data, Computer Use, ultragoal

An AI working alone is very good at reasoning and surprisingly bad at knowing. It can argue beautifully about a fact it half-remembers, write code against a screen it has never actually seen, and declare a job finished without ever checking. The loop you have been learning fights that tendency with one habit: don't guess — go and look. Tools are how it looks. They are the loop's hands and eyes on the real world.

This lesson covers the three that matter most. Bright Data is the one tool for anything that lives on the web — searching, reading a page, even driving a live browser. Computer Use is for the desktop: it can read and operate an ordinary Mac application, the same buttons and fields a person would click. And ultragoal is different in kind — it isn't a way to reach out and touch something, it's a way to write down, before any work starts, exactly what "done" means and how a finish will be proven. The first two let the loop act on the world and see it; the third makes sure it can tell when it has actually succeeded.

One discipline ties all three together: whenever the loop is about to lean on something it isn't sure of — a fact, a screen, a claim that the work is done — it reaches for the matching tool and gets real evidence instead. A person never has to sit and watch this happen; the same hands-off, observe-only stance from earlier lessons holds here. The tools are simply the loop's approved way to be sure.

Think of it like… a careful journalist. They don't run a story from memory: they phone the source to check a fact (that's Bright Data), they go to the building and try the door themselves (that's Computer Use), and before they file, they have a fixed standard for what counts as a confirmed story — two independent sources, on the record — written down in advance (that's ultragoal). The reporting is the loop; these three are the notebook, the legwork, and the standard the editor will hold them to.

Before the detail, here is the whole toolbelt on one row. Each card is one tool: what it is for, and the one thing to never do with it. The "never" lines matter as much as the "for" lines — picking the wrong tool is the most common way these go wrong.

Here is where the three sit relative to the loop. The loop reasons in the middle. When it needs a fact or a page, it reaches out through Bright Data to the live web. When it needs to operate an app, it reaches out through Computer Use to the desktop. Both send a real observation back. ultragoal isn't a reach-outward at all — it sits at the edge as the gate that decides whether the loop has actually finished.

Any time the loop needs something that lives on the internet — a fact to confirm, a page to read, a price or a profile to pull, a site to click through — it uses Bright Data, and only Bright Data. It is one uniform command (brightdata) that every assistant can run from its shell, and it does four kinds of job: run a search and read the results; scrape any page, even ones that try to block robots; drive a real browser session step by step; and pull clean, structured records from dozens of big sites — social networks, shops, maps, finance, job boards, real estate.

The reason it is the only web tool is reliability, not preference. A plain web fetch trips over bot-walls, CAPTCHAs and rate limits; Bright Data is built to get through them, so the loop's evidence is a real page instead of a blocked error screen. That is why the rule is strict: for web data, it is always brightdata — never the generic WebSearch or WebFetch, and never the Bright Data "MCP" plug-in. One path, everywhere, so the loop's window on the web behaves the same no matter which assistant is driving.

The habit this enables is the important part. When the loop hits any doubt — "is this still true?", "what does that page actually say?", "is this library current?" — it does not lean on what it half-remembers. It reaches for Bright Data and grounds the answer in a page it just fetched. Guessing is the failure mode; fetching is the fix.

Some jobs don't live on the web — they live in an app on your Mac. Computer Use (the computer-use command, also spelled cu) is how the loop operates one. It can read an app's controls, click a button, type into a field, drag a slider or move a window, and launch an app — the same handful of moves a person makes with a mouse and keyboard. It is how the loop both acts on the desktop and verifies a desktop change actually happened: it can drive the UI and then read the UI back.

The clever, calm part is how it does this. It does not grab your real mouse and start moving the cursor while you watch. It works through the Mac's built-in accessibility layer — the same plumbing screen-readers use — so it reads and presses controls directly. That means it never fights you for the pointer, never yanks a window to the front, and stays out of your way. You grant permission once, per app, and from then on the loop can operate that app without interrupting you.

Choosing it is a matter of matching the tool to the surface. A web page is a job for the browser tools, not this. An app that ships its own dedicated integration should be driven through that. But for an ordinary native macOS app with no special integration — Calculator, Notes, Finder, System Settings, some third-party .app — Computer Use is exactly the right hands.

Think of it like… a helper who operates your computer through the accessibility menu rather than by grabbing the mouse out of your hand. They read the labelled controls and activate them directly, so the cursor never jumps and your window stays where you left it — the work gets done quietly in the background while you keep typing.

The point worth feeling, not just reading, is that a tool call moves the loop through real states — and that some moves simply aren't allowed from where you are. Below is one "touch the world" action modelled as a tiny machine: the loop calls a tool, the tool runs, an observation comes back, and only then is it gated against the finish line. Press an event and watch the highlighted state move; buttons grey out the moment a move isn't legal. Try to skip a step and the machine refuses — exactly like the real loop refusing to declare "done" before a verifier has run.

The third tool is not about reaching out into the world at all — it is about deciding, in advance, what counts as done. ultragoal is the discipline of writing a goal that is durable and verifiable before any work starts. "Durable" means it lives on disk, so a crash, a new session, or a different assistant picks up exactly where things stood. "Verifiable" means the goal comes with a way to check it that can actually fail — not a vibe, a test.

Three things make a goal an ultragoal. First, an observable finish line: "done" is stated as something you could point a stranger at and they would agree it's met — not "improve the page" but "the page loads under 200ms on this measurement". Second, a verifier that fails at the boundary: a real check — run the test, hit the endpoint, read the file — that comes back red when the goal isn't met, so success can never be merely claimed. Third, a red-team pass before activation: before committing to the goal, you deliberately try to break it — find the loophole, the way it could be "passed" without really being done — and tighten it. Only then is the goal turned on.

And because it's durable, the goal isn't held in one assistant's head — it's written down in plain files. SCOPE.md captures what's in and out of bounds; GOAL.md states the finish line and how it's verified; LOOP-LOG.md records each pass so a person can audit the run later. That is what lets the loop run unattended and still be trusted: anyone can open those files and see what "done" means and whether it has been reached.

Think of it like… a contractor who won't start until the contract is signed. The contract spells out exactly what "finished" looks like (the finish line), names the inspector who will come and check it against code (the verifier that can fail), and is reviewed by a lawyer hunting for loopholes before anyone signs (the red-team). Once signed, it's filed where both sides can read it — not remembered, written down.

It helps to see how the same three tools look from each side of a run. They are one toolbelt, but a person, the reasoning model, and the working agents each relate to them differently — and keeping that straight is what makes the toolbelt safe rather than noisy.

Three quick questions to make the tool choices stick. Pick an answer; you'll see immediately whether it holds.