AI agents are made up of language. laserbrain holds the goal — the one the agent stated first, frozen where it cannot revise it, and checked against every step after.

Agents do not fail loudly

Agent drift is the gradual loss of alignment between an agent’s actions and the goal it was given.

One runs for an hour, reports progress at every step, and finishes something adjacent to your request. Nothing errored. The logs read like success. You find out when you read the transcript — after the tokens are spent.

• ·taking irrelevant steps
• ·getting stuck or looping
• ·making tool calls that no longer serve the task
• ·producing increasingly disconnected work while still appearing active

Asking the agent does not help much. It answers fluently either way, because the faculty that would notice the drift is the one that drifted. A system can assess itself — what it cannot do is make that assessment independent of the thing being assessed. That is the whole reason the reference is held outside the run.

Measured on ourselves: over one session the assistant building laserbrain was asked each step to report progress — advancing, stuck, or circling. It chose advancing 28 times out of 28, across a stretch of seven designs that were converging on nothing. Every report was true. The sequence was not.

Two failure modes, and they have different scopes

Constraint drop needs hand-offs: inside one agent with the rule still in its prompt, constraints held 36 of 36 across chains of up to eight dependent steps, which bounds the loss rate near 8% rather than at zero. Two of five constraint types showed no benefit for the same reason. So the curve above is a pipeline curve. Goal drift needs only length, and one agent working alone has plenty: on our own single-agent corpus the share of readings flagged goal-drift runs from 0% within a minute of your last message to 67.9% past thirty. All nine verdicts fire inside a single run. What we have not measured is whether catching it there improves the outcome — every controlled comparison we own ran on work that changed hands.

One boundary, stated plainly: this measures execution, where the goal is fixed before the run starts. On exploration — figuring out what to build while you build it — it will report drift continuously, correctly, and to no purpose. Use it on the tasks that fall out of the exploring, not on the exploring.

A reference the measured thing can revise is not a reference

laserbrain is a runtime goal-alignment harness for AI agents. It gives an agent a fixed reference for its intended goal, evaluates subsequent steps against that reference, and looks for signs that execution is drifting, stalling, looping, or spiralling. The aim is to detect unproductive motion early enough to intervene — not merely observe it afterward — so agent workflows use fewer tokens, take shorter paths, and remain more controllable.

It works on a different axis from its three nearest neighbours. Tracing records what happened for reading afterwards; laserbrain holds the goal while the run is still going. Hallucination checks ask whether an output is true; laserbrain asks whether it is still the work you asked for — a perfectly accurate answer to the wrong question fails here and passes there. Observability aggregates across runs; this is one signal inside one run. If you already run span-level tracing and continuous evaluation, laserbrain is a signal on the span.

The freezing is the product

A reference the measured thing can revise drifts along with whatever it is measuring, and every reading comes back healthy. We have watched that fail concretely: when a subagent was allowed to reset the ground, the parent goal was overwritten and every later check reported a perfectly on-track run that had gone somewhere else. That incident is why excursion and parent_goal exist.

It is a grammar, not a model. No second LLM judging the first, no network call in your loop, nothing to train. A fixed algebraic structure — four bands, XOR only — computed locally in single-digit milliseconds. The same grammar file backs the package, the hosted API and the MCP server, with a parity check that fails the build if they diverge.

The goal is written once, and never rewritten

• 1You configure it once. One line in an MCP client, or pip install laserbrain / npm install laserbrain in the loop.
• 2The agent states its goal on the first step. Thirty stopwords come out, one stem rule collapses inflection, and what remains is sorted into a set. That first rendered string is the laserscore, and the first one written becomes the ground.
• 3Every step after is scored against it. Φ is the displacement from ground, weighted 0.5 goal · 0.3 distance · 0.2 progress. Goal overlap is checked separately.
• 4Over the line, the agent is interrupted before the next tool call — and told which of nine things went wrong. Not warned afterwards: the point is the step that does not happen.

A reading is a time sample. add a CSV importer to the admin panel becomes ⟨add|admin|csv|import|panel⟩, and the laserscore renders as ⟨add|admin|csv|import|panel⟩ advancing d8. The goal itself is free text; the set is what gets compared.

How to attach it

Free and offline on one machine, or one line in an MCP config. The check runs in your loop, not on our server — there is no network call to make it work.

pip install laserbrain          # or: npm install laserbrain

# or attach over MCP — one line in your client config
"laserbrain": { "command": "laserbrain-mcp" }

quickstart walks the first run end to end; docs has the tool reference.

Nine things it can say, and only two stop you

In the order the harness tests them — first match wins, so the order is the definition. Four let the run carry on. Two warn once and interrupt on a repeat. Two interrupt immediately. The ninth reads the sequence rather than the step.

What we have actually measured

Everything on this page that is a number is either read from a file that rewrites itself, or it is here with the sample size beside it. The negative results are here too, because they are the results we got.

What drift costs

A constraint survives only if every step preserves it, which makes rolled throughput yield the honest measure: one correct deliverable took 30 calls where the goal was not held. Unaided retention of 0.965 per hand-off means 96% survive one hand-off and 75% survive eight — the curve at the top of this page. Held outside the run, it is flat at any depth.

What the evidence supports, and what it does not

How often it fires, by how long the session has run

The attention bands are read from data/attention.json, which sync-attention.mjs rewrites from the calibrated table and which fails the build when it falls behind. The figures are read from that file rather than restated here, so the page cannot fall behind it.

Who is running it

7,593 installs over 24 days, mirrors excluded — 24,808 raw, of which 69% are mirrors. Read from pypistats, never typed: check-uptake.mjs fails the build once the figure is more than 45 days old, so it cannot rot quietly.

The check is free. The console is the product.

The check tells you this run went wrong. The console tells you which runs keep going wrong — history, the waste ledger, and the drift corpus across every machine you attach.