Boreal

Most agent tooling asks for trust. A prompt goes in, files change, and what comes back is a summary. Boreal treats a change as a transaction instead: the run, the check, the diff and the approval stay separate steps, and you can see which one you are in.

It runs on the Ariadne engine, which executes scoped tasks and records what each one was allowed to touch.

That order is built into the structure rather than agreed by convention. A task is a contract before it is a conversation: what it may write, what it may never touch, what it has to satisfy, and how many repair attempts it gets. A profile can ask for more evidence or more review. It cannot grant itself an approval or widen its own scope.

I kept approval out of the agent's reach. The confirmation is assembled from the engine's own records in a native window rather than from the page, and it says plainly that the identity is the caller's claim, not something Boreal checked. The agent never works inside your project either: a run gets a copy of the workspace as it was handed over, and that copy is what gets examined.

When a worker reports complete, that report decides one thing only, which is that there is now something to check. Everything else is recomputed. Boreal compares the working copy against the version the run started from, works out what actually changed, and runs the task's checks against the files on disk. Some of those results are unflattering on purpose: a workspace that moved while the run was going is refused rather than checked, because validating a different version would be theatre.

The review is built from the run's own before-and-after state, not from a file list the agent hands over. It lists every path that was created, changed or deleted, and approval belongs to one exact version of that content. Change the files afterwards and the approval goes stale by design.

Applying is journalled, so each file can be put back. A multi-file change is written one file at a time, so an interruption can land partway through: recovery works out how far it got, and a rollback restores the earlier bytes. If a file changed after you applied, the rollback stops, keeps both versions, and tells you.

A chat message can carry a proposal. It cannot carry a diff, a scope, an approval tied to specific content, and a way back.

A diff tells you what changed. It does not tell you whether the result is any good, which is how I ended up building a preview at all. Boreal runs the project for real, but only from a config the project declares and you explicitly trust, and only inside a frame that cannot reach back into the workbench.

Click anything in the preview and it reports what is rendering there and where the source says that line lives. Where the mapping cannot be confirmed, the panel says so rather than guessing. Inspecting is read-only; changing text or styles takes its own path, checked against the source before the file is written, with an undo beside it. Structural changes are proposed as tasks and reviewed like anything else.

The interesting failures happen between steps, so the store writes atomically and keeps a log. If the engine restarts with a run still marked running, that run becomes interrupted, with a record of how far it got, and the task goes back to a state it is allowed to run from. It does not quietly become a failure.

Half-applied changes are resolved the same way. Boreal compares every file against what it should have been, and a rollback restores the earlier version. A rollback that finds a file edited since the apply stops and keeps both copies. What you do not get back is the conversation: each run gets a fresh workspace and a fresh session, and continuity between attempts comes from the project's own records.

A packaged Windows build installs and runs. Here is how far it has actually got.

Boreal currently assumes that the diff, the check, the run record and rollback help people review agent work more carefully. The next useful step is to test that assumption rather than treat it as proven.

One comparison would put a summary-only review against Boreal's evidence-rich review, and measure what people catch, what they ignore, how long the review takes, and how confident they are in the decision.

I started Boreal to make AI coding agents better at changing interfaces, and that turned out to be the easier half. Producing a change is largely solved. Reading one is solvable. The part in between is not.

Someone has to look at a diff they did not write, decide whether it deserves to become real, and still be able to reverse that decision afterwards. So the workbench is arranged around that: scope the run, watch it, read the change, approve it, and keep it reversible until you have. Trust here is a property of a workflow you can inspect, not a claim the system makes about itself.