Reliability & Automation

The Terminal Brain

A committee of models reads over your shoulder in a live production shell. The watching tier cannot type. Not switched off, not configured down. There is no code path that types.

Designed, built, and operatePythontmuxxterm.jssystemd sandboxingTOTPMulti-model committee

Three independent lenses read the screen, and disagreement between them forces a human decision.
The watching tier cannot type. Not switched off, not configured down. There is no code path that types.
One keystroke drops it to watch-only. No confirmation, no grace period, no setting to disable it.

The problem

An AI that can type into a root shell on a live host is either the most useful tool you have or the worst incident you will ever write up, and the difference is entirely structural.

So the interesting engineering here is not the model. It is the set of things the model is unable to do.

The work is not in the browser

Every session runs inside tmux on the target host, so the layers fail independently. Close the laptop, lose wifi, restart the daemon, reboot the control-plane box. The work keeps running, and you resume by name.

Naming and resuming are one operation, which is what makes durability simple. A pinned session means this session should exist, not this session existed: press the button and anything pinned that is gone is recreated under the same name.

That is not how it was first built. The pseudo-terminal originally lived in the daemon, and three redeploys in one day killed live sessions. The regression test now starts work, kills the daemon, and asserts the job kept running with no daemon alive.

The committee

Attach the brain to a session and it asks what the session is for. From then on, every time the shell goes quiet (on quiet, not on a timer, and only if the screen actually changed) it reads the screen and tells you what it sees.

Three lenses run independently on a cheap model, then an arbiter on a strong one:

The committee
operator	what moves the goal forward
skeptic	is the obvious reading wrong
safety	what could this destroy
arbiter	reports dissent rather than averaging; combined risk is never lower than the safety lens gave
output	a suggestion a human accepts with a keystroke, never a keystroke itself

Three lenses read the same screen and an arbiter weighs them. It does not average them: disagreement is reported as dissent and forces a human, and the safety lens holds a veto on the risk grade. A split committee and a confident one must never look alike.

operator
Given the goal, what is the next keystroke that moves it forward?
skeptic
Is the obvious reading of this screen wrong? Stale scrollback, paused rather than finished, a yes/no prompt belonging to a different tool.
safety
If the obvious action were taken on a live host right now, what could it destroy?
The arbiter does not average them. Disagreement is reported as dissent and forces “needs human,” and the safety lens holds a veto on the risk grade. The combined risk is never lower than the one it gave. A split committee and a confident one must not look alike. Fewer than two lenses answering is not a committee: it returns “could not reach a quorum” and suggests nothing.

Why accepting a suggestion is not the same as typing

When you accept a suggestion, the page does not send bytes. It posts a reading number, and the daemon looks up what was actually said in its own transcript of the exchange.

That split is the whole safety story. A page that could post arbitrary keys “from the brain” would make the never-send list decorative, so it cannot. And it keeps two facts distinct in the audit log: “the operator typed y” and “the operator accepted reading twelve, which the committee graded medium risk and flagged as needing a human” are different events, and they should read differently a year later.

The guarantees that are load-bearing

A stale reading cannot be sent
Each reading records a hash of the screen it judged; sending re-reads the pane and refuses if it has moved on. An answer to a prompt that scrolled away would land on whatever is there now.
A reading can be sent once
The second attempt is refused.
One never-send list, two enforcement points
Loaded by both the arbiter and the daemon. One file so they cannot drift, two checks because they guard different boundaries. Both loads fail closed: no list, and the arbiter refuses to start while the daemon refuses to arm or send anything.
Credential prompts are permanently on it
A guess at a password prompt is an authentication failure the brain authored. It is logged as one, and enough of them trip a ban or lock an account. There is also no answer that could ever be right, so the only outcomes are wrong and worse.
The terminal daemon cannot reach the internet
Its egress is denied except for loopback and its targets. Rather than punch a hole in that for a model call, the committee lives in a separate service and is asked over loopback. It holds no SSH key and can reach no host. It is handed text and returns text.
The takeover is absolute
One human keystroke into the window drops it back to watch-only. No confirmation, no grace period, no setting to disable it. The moment two parties are typing into one shell, one of them has to stop, and it is not the person.

Cost, cadence, and testing

A reading costs roughly five cents and takes about twenty seconds. A session idling at a prompt all afternoon costs nothing, because the trigger is silence plus a changed screen rather than a clock.

Only high-risk readings that need a human page a phone. Narrating every reading to a notification channel would train the operator to ignore the channel that also carries session-opened alerts.

The regression harness uses a fake agent that genuinely responds, and where the committee legitimately answers “wait,” the harness reports NOT EXERCISED rather than passing silently.

Engineering decisions

The calls I made, and what each one cost.

Detach and kill are separate buttons.

Conflating them is how someone loses a migration by tidying their desktop.

The watch survives a daemon restart; the narration does not.

The work is on the target, so the watch should be. But replaying yesterday's readings would describe screens that no longer exist, and a confident description of a screen that is gone is worse than silence.

A held decision is re-asked on a backoff, not resolved by retry.

The committee is not deterministic. Re-asking a genuinely ambiguous screen a bounded number of times is honest; re-rolling until it says yes is not.

More systems

Reliability & Automation

I'm looking for Incident Commander and SRE roles.

If your team is drowning in toil, alert noise, or incidents that never quite close. That is the work I do.

Get in touch