The keyboard was part of the product model.
IEEE Spectrum's history of the Bloomberg Terminal describes the 1982 Market Master as a monochrome display, custom keyboard, controller, and private network. Its color-coded function keys named market tasks. Users could request data and analysis without memorizing every command.[1]
The design grew with the job. The article records a trackball in 1990, audio hardware in 1992, multilingual keyboards by 1996, and fingerprint authentication in the early 2000s. Those additions were not decorative. Each one exposed a new mode of work or a new trust boundary.[1]
The useful lesson is not "build a weird keyboard." It is "make the operating model visible."
Agent IDEs now have the same density problem.
Visual Studio Code 1.140 adds a Copilot harness, experimental multi-folder sessions, remote delegation, a research preview for multi-model orchestration, shared worktree folders, and enterprise controls. The release notes also say the harness runs in a dedicated agent-host process and can be reached from several windows.[2]
That is a lot of machinery behind one chat input. A prompt can ask for any of it, but free-form language does not show the current folder, authority, process, or escape route. The interface still needs stable names for repeated operations. It needs separate controls for changing reach and stopping work.
Commands need discovery and dispatch proof.
VS Code's keyboard documentation already has the right pieces. Its shortcut editor lists commands with and without keybindings. Users can filter the list, inspect conflicts, and turn on dispatch logging to see which shortcut and command the editor received.[3]
Accessibility help also changes by context. It covers the editor, terminal, notebook, Chat view, and Inline Chat. Keyboard-only navigation and screen-reader support are first-class paths rather than an afterthought.[4]
An agent command deck should combine those ideas. Show a short set of named jobs. Keep the native keyboard path. Display the target and authority before execution. Record the dispatched command after execution. Put Stop where it cannot disappear behind a model response.
Do not turn every command into a permanent key.
A dense interface becomes useful when controls match repeated work. Rare commands still belong in search. High-frequency commands deserve stable placement. Dangerous commands need an explicit confirmation and a visible scope. Recovery commands need a route that does not depend on the system being healthy.
- Count real command use before pinning anything.
- Keep labels literal and stable across menus, shortcuts, logs, and receipts.
- Show the target workspace and authority beside the action.
- Log the resolved command, not only the user's words.
- Test conflicts, keyboard access, screen-reader output, and Stop under load.