Skip to content
self.md

■ SIGNALS // RADAR SIGNAL

Who gets to control the agent?

Three tools make agent work more inspectable: an orchestration layer, a sidecar for instructions, and a deck that checks its claims against the code.

Published Updated Read 3 min
■ [!] ON THIS PAGE ▼

self.md radar — 2026-09-01

A coding agent gets more useful when it stops being a terminal tab. That is also when its hidden instructions, approvals, and evidence stop being incidental. Three small projects are trying to make those things inspectable rather than mystical.

1. the agent harness is becoming a switchboard

Omnigent puts Claude Code, Codex, Cursor, OpenCode, Hermes, Pi, and custom agents behind one orchestration layer. The pitch is not another general-purpose assistant. It is continuity: start a session in one harness, supervise several at once, and keep the same work reachable from a terminal, browser, or phone.

Its policy model is the part worth watching. A policy can allow an action, deny it, or stop for approval; session policies run before agent-spec and server-wide policies. That gives a person a way to impose a local “ask before this” rule without treating whichever model happens to be running as the source of authority.

There is an obvious trap in the same design. Once a switchboard holds sessions, files, terminals, and shared access, it is no longer just a wrapper around interchangeable tools. It becomes another place where the work lives. Portability is only real if the record and the exit path travel too.

reading: Omnigent’s repository and architecture · its policy model

2. hidden instructions need a visible maintenance surface

Blume is a desktop sidecar for the rules, skills, hooks, and corrections that accumulate around coding agents. It watches several harnesses, keeps conversation history local, and proposes changes when the written setup drifts from what people repeatedly ask agents to do.

The useful claim is modest: do not let the instruction layer become a pile of dotfiles that nobody can explain until it fails. A suggestion still waits for review, with an exact diff to accept, dismiss, or save. That is closer to configuration hygiene than autonomous self-improvement.

The hard question is whether the sidecar can distinguish a recurring constraint from a temporary bad mood in a chat. “You asked for tests four times” may justify a project rule. It may also mean the agent was failing at its basic job. The difference is not something a frequency counter gets for free.

reading: Blume Sidecar

3. a deck should know when it has gone stale

SlideOps turns a repository into a slide deck, then checks whether claims in the deck still match the code. When a source changes, it can identify the affected slides instead of asking someone to rebuild the whole presentation from memory.

That is a small but serious move away from the usual “AI made the slides” demo. A deck used for a handoff, a client decision, or an internal plan is a claim about a system. If nobody can tell when that claim stopped being true, the polish is just a delayed failure.

The project also keeps its verification specifications beside the skill that produces the deck. Good. The proof should sit close enough to the artefact that the next person can run it, not in the head of whoever gave the presentation last month.

reading: SlideOps repository

left on the table

  • Omnigent and Blume both promise a better view of agent work. Neither removes the older question: where do the session records, instructions, and approvals go when you leave?
  • SlideOps has a narrow scope. That is probably why its check is legible. A deck can be tested against a repository; a strategy deck still needs someone willing to say the premise changed.
agents permissions developer-tools