Tools are part of the operating system

The old wiki kept Emacs variants as a tiny reference. The subject was never nostalgia. It was the idea that the editor can become a programmable environment instead of a passive text box.

A programmable environment lets the operator bind navigation, compilation, diagnostics, structured text, version control, and domain tools into one inspectable state machine. The advantage is not maximal customization. It is that repeated decisions become named commands, commands remain composable, and the full transition can be examined or changed locally instead of being trapped behind an opaque SaaS workflow.

The same standard governs current agent workflows: commands must be inspectable, context must survive, automation must remain interruptible, and the user must be able to see what changed.

An agent run should have a stable identity, objective, working directory, model route, tool scope, approvals, event log, diff, and terminal state. Detaching the UI must not destroy the run. Resuming must not guess which objective was active. Cancellation must reach owned processes, and the interface must distinguish stopped, failed, waiting for approval, and completed with unreviewed changes.

A good tool compresses intent without hiding state. If it saves keystrokes but destroys control, it is not leverage.

The right interface gives progressive disclosure: a terse status for routine work, structured evidence for review, and raw logs when diagnosis requires them. It keeps irreversible actions explicit and makes safe, reversible transitions fast. This is the same design pressure that shaped programmable editors—reduce interaction cost while preserving the operator’s ability to understand, redirect, and recover the system.