Technology · Brain Workers

Live sessions that do the real work.

When a request needs actual reasoning — research, multi-step tasks, writing or modifying an app's code — the FlashBrain launches a Brain Worker: a live, steerable session with its own tools and memory access.

View full diagram →

A worker isn't a one-shot script — it's a live, bidirectional session the FlashBrain governs for as long as it runs. It can inject a refinement mid-task ("actually, make it green" — without opening a second one), kill it outright, or answer a question the worker is waiting on.

What decides to spend a worker at all is a gate, not a guess: alongside the reflex model's own judgement, a choice classifier answers one enumerated question — escalate, or handle this inline. It is asked when your sentence is complete and read after the model, and it is deliberately biased: anything unsure, late or unreachable escalates, because a missed errand costs more than a wasted question. «Handle it inline» is not taken on the classifier's word either — if the reply you just heard promised to go and do it, the errand stands, because a promise with nothing behind it is the failure this gate exists to prevent. And before any of that, the cheapest question: does a card already on your screen do this? The same classifier is asked which declared action of which open card you meant, so an errand a player can answer in one call never becomes a background worker that takes minutes.

A search that's actually directed

Anyone can open a site, set two filters and read back the first three results. What a competent person does instead is look at forty options, read the reviews, check the photos, and only then propose three. The difference isn't the tools — a worker already drives a real browser — it's that somebody has to decide how wide to look and what counts as good.

So before a worker starts, a selection gets a brief: hard criteria that disqualify kept apart from soft ones that merely score, a minimum number of candidates to gather before discarding any, several distinct search angles (one route always returns the same subset), and a quality bar made of concrete checks rather than adjectives — "rated 8+ with at least 100 reviews", not "make it good". The brief also adds what an expert would think of and the request didn't say: travelling with your own car means you'll need somewhere to park it.

That brief is composed off the conversation's critical path, which is exactly why it can afford to think. Then the worker follows the funnel in order — gather wide, filter by the hard rules, score the survivors, and spend the real effort verifying only the finalists.

A selection you can audit: the worker reports how many candidates it genuinely evaluated, so "here are the three best" stops being indistinguishable from "here are the first three". If you'd rather it kept looking, saying so continues the same investigation with a wider net — you never restate your criteria.

The same structure works whatever the subject. Choosing a laptop, surveying the state of the art on a topic, researching a book, picking a library: the domain changes, the shape of directing a search doesn't. And a proposal can be made of pieces — somewhere to stay plus how to get there — so you compare and pick whole plans instead of assembling them yourself from separate lists.

Researching never commits: a worker proposes, it doesn't book, buy or pay. That decision stays yours, taken while looking at the options.

Agnostic of the executor

The interface underneath is a single seam — Claude Code, Codex and Grok Build backends exist today (the alternates in beta), and different backends can run side by side; behind each, a chain of providers hands over when one runs out of quota. Swapping the executor never touches how the FlashBrain talks to a worker.

Three channels, one durable record

Every request is one durable row — your words, the end state it has to reach, and its verdict. The live session registry writes into that row, so the UI, the agent and the logs all read the same answer, and a restart never loses what was running. Communication with a worker runs on three channels: injecting a refinement downward, the worker reporting status upward over the bus, and a request/response channel for a worker to ask a question or use a lent tool (like web search) under an explicit allow/confirm/deny policy — a worker can never call an operator-only capability on its own. The same holds on the engine's own API: a worker's request can never pass for your click — every change needs your screen's session, and workers only reach the doors named for them.

Every errand is bounded: it has a web-search budget, and when that is spent the worker delivers what it found instead of searching forever. A worker that goes quiet is asked to report, then announced; one that stalls is stopped loudly — never blindly relaunched.

A worker is killed as a full process group, never left as a zombie. A cancelled session simply stops — a hard failure always says so out loud, never silence.

The session registry is also what a user sees and asks about — "show me the active processes" opens a live view of exactly this state, plus scheduled crons, right next to the conversation. See What It Can Do in the User Guide.

The narrowest-scoped worker in the system

A worker can also be launched from a conversation on the agent network — but only opt-in, and with the tightest leash of any session: a disposable working directory, version control reachable only through a bridge scoped to one pre-authorized repository, and file access enforced by a real hook rather than a polite instruction. Two separate operator decisions have to both be in place before it can run at all.