This is what might get built next, run as a queue rather than a wish list. Every idea earns its place: it gets a risk class and the rules it must respect before any code is written. The standout tracks are below; the full register sits in the deep dive.
Everything AgentOS might do next, run as a queue rather than a wish list. Every idea becomes a row in the register with an ID, a risk class and the guardrails it must respect, and nothing gets built without one. The standout tracks come first, then the full live table. How a row becomes shipped software is the workflow page; what already shipped is the build log. Register current as at 10/07/2026.
The register does not rank by excitement, but this page can. What is queued next, and the tracks that change what AgentOS is.
A safety barrier so anything the system reads can never be mistaken for instructions telling it what to do. It warns rather than blocks, so work keeps moving.
Audited content is data, never instruction. The shipped fence design becomes code: run-scoped nonce boundaries around every untrusted block, tool results fenced at the executor loop, and authority-flavoured framing demoted. The fence warns and demotes; it never gates.
Every audit already pushes raw file bodies and website HTML into prompts unfenced, and one target-writable file is currently framed as judging authority. It is the highest-value safety work in the queue, and it is deterministic code only: no model spend, no new authority.
A chat screen that picks the right AI model for each request, under the same safety rules as everything else. The design is shipped and reviewed, with the build cut into slices.
A Studio chat tab riding the same guardrails: explicit pick, vendor-pinned auto, or full Auto through a pure two-stage router, with metered API calls and subscription CLIs as parallel execution classes. Design shipped and adversarially reviewed; four build slices cut.
Alerts and a read-only status page on my phone over a private secure network already work. The next step is approving or rejecting an item from the phone, with the same checks as at my desk.
Push notifications and a read-only mobile triage page over the tailnet already shipped. The gated next step is the first off-machine write: approve or reject an inbox item from the phone, issuing the same grant object through the same path as the desk.
The system runs scheduled work on its own. Approval is tied to the exact schedule I approved, so any edit switches it off until it is re-approved, and it can never queue up decisions faster than I review them.
Schedule, enqueue, auto-drain. Arming a schedule is a recorded act bound to its content hash, so any edit disarms it, and a decision-debt cap stops the machine generating decisions faster than the human reviews them.
Self-sovereign nodes pushing observability to a read-only centre. The centre never approves, never applies, and holds no authority channel back to a node: a fleet you can watch, not one you command.
A browser page that can make changes, wrapped in the same approval steps as everything else. Even software running on the same computer is treated as untrusted, and anything opened away from the machine can only look, never change.
An authenticated local write API terminating in the existing freeze, simulate, approve, apply spine. Localhost is treated as hostile-caller territory, and a link opened off-machine may reach a triage read at most, never the write API.
Mine run metrics, dispositions, and verifier verdicts for per-workflow signal, then feed it back into prompt, model, and route selection. Descriptive first: nothing changes agent behaviour without its own gated slice.
A code-owned registry of every user-state domain: settings, target registries, memories, skills, commands. Exports to a git-tracked repo with a fail-closed secret scan before anything leaves the machine. Config can narrow the export, never widen it.
Every audit gets the same controlled slice of my working context, and every use of it is traced in the report. It is the first step towards the system remembering context between runs.
The gateway serves a server-owned slice of operator context to every audit workflow: no default slice, no client-picked files, every injection traced in the report's evidence. The first concrete memory-over-MCP step: memory informs, the spine decides.
Quality per workflow measured on a fixed task set with bounded spend and a results ledger. Which model actually audits better, with receipts.
All 38 live rows, straight off the steering board. Role says why a row exists: boundary rows lock or open a constitutional line, keystones are load-bearing, unlocks enable a later step, hygiene keeps the runtime honest. Risk sets how much design happens before code. Shipped rows leave this table at closeout: 26 so far, narrated in the build log, so a prereq you cannot find below has already shipped.
| ID | Title | Role | Risk | Prereq | Status |
|---|---|---|---|---|---|
| 5O.2 | Injection fence implementation: nonce-fenced data channels | boundary | R1 | 5O.1 | up next |
| 5O.3 | Prompt-surface registry and injection telemetry | hygiene | R1 | 5O.2 | proposed |
| 5N.1 | Decision inbox: the "what needs me" projection | keystone | R0 | none | in progress |
| 5W.2 | Chat tab v1: explicit pick, metered class | unlock | R3 | 5W.1 | proposed |
| 5W.3 | Subscription execution class for chat | unlock | R3 | 5W.2 | proposed |
| 5W.5 | Model provenance in authority-plane records | boundary | R1 | none | proposed |
| 5W.4 | Tiers and Auto routing for chat | boundary | R3 | 5W.3, 5W.5 | proposed |
| 5V.4 | Remote decision surface: design gate | boundary | R0 | 5V.2, 5V.3 + demonstrated demand | proposed |
| 5G.1 | Unattended operation design: schedule, enqueue, auto-drain | boundary | R0 | none | proposed |
| 5G.2 | Unattended operation implementation | unlock | R3 | 5G.1 | proposed |
| 5G.3 | Schedule controls in Studio | unlock | R4 | 5G.2 | proposed |
| 5P.1 | Browser-on-node operate surface: design gate | boundary | R4 | none | proposed |
| 5Q.1 | Node and fleet foundation design: identity, push publisher, observatory | keystone | R0 | none | proposed |
| 5R.1 | Declarative workflow authoring design | boundary | R0 | none | proposed |
| 5S.1 | Portfolio context serve: slice registry and gateway endpoint | keystone | R2 | none | proposed |
| 5S.2 | Runner context module and content-audit migration | unlock | R1 | 5S.1 | proposed |
| 5S.3 | Code-audit executor and challenger voice slices | unlock | R1 | 5S.1 | proposed |
| 5S.4 | Studio context strip and degraded warning | polish | R2 | 5S.2, 5S.3 | proposed |
| 5T.1 | User-state registry and scheduled backup design | boundary | R0 | none | proposed |
| 5T.2 | Backup implementation and Settings tab controls | unlock | R4 | 5T.1 | proposed |
| 5M.1 | Workflow self-improvement from run data: design | boundary | R0 | 5H.2 | proposed |
| 5B.1 | Model evaluations and benchmarks design | validation | R0 | none | proposed |
| 5C.1 | Projects tab design, onboarding interview first | unlock | R0 | none | proposed |
| 5D.1 | Slack outbound notifications design | unlock | R0 | none | proposed |
| 5E.1 | Goals interface design | unlock | R0 | none | proposed |
| 5J.1 | Studio UX review and IA redesign | unlock | R0 | none | proposed |
| 5J.2 | IA restructure implementation | unlock | R2 | 5J.1 | proposed |
| 5J.3 | Run-completion notifications in the IDE | polish | R2 | none | proposed |
| 5J.4 | SSE live updates in Studio | unlock | R2 | none | proposed |
| 5J.5 | Open-source jump in the content-audit panel | polish | R2 | none | proposed |
| 5A.2 | Webview render harness: state-to-HTML snapshot tests | hygiene | R1 | 5A.1 | proposed |
| 5A.3 | Tier 1 extraction: sensitive pure helpers | hygiene | R1 | 5A.1 | proposed |
| 5A.4 | Tier 3 webview decomposition | hygiene | R2 | 5A.2, 5A.3 | proposed |
| 5I.2 | Register drift check | hygiene | R1 | none | proposed |
| 5K.3 | Make the smoke suite's live-site couplings hermetic | hygiene | R1 | none | proposed |
| 4G.4 | Website-audit advisory challenger, opt-in | validation | R3 | 4G.3 | proposed |
| 4G.6 | Studio launch of the website-audit graph | unlock | R2 | none | proposed |
| 4E.30 | Ledger enrichment design: category, type, anchor context | unlock | R0 | none | proposed |