In our last post we showed how we run our whole company as an org chart of AI agents: a manager that plans and delegates, folder-scoped department heads that each own one slice of the repo, a single daemon as the records office, and Nostr-signed decisions for the paper trail. The whole thing is reproducible and auditable, and most of the time it runs itself.
"Most of the time it runs itself" is the part that should make you pause. An autonomous company that plans, decides, and signs its own work still answers to two people: the two of us who own it. The two things we added since that post are both about the same problem, putting a human back in the loop. One is a private assistant we talk to. The other is a cockpit we watch. Neither makes the agents more autonomous. Both make them more accountable to us.
We layered a personal assistant on top of the company. We call it Shadow. It is not another department in the org chart. It sits above the chart and works for the two of us directly.
Shadow runs on a separate autonomous-agent runtime (the hermes agent), inside a rootless Podman sandbox. The sandbox is the point: it lets us hand an assistant real tools, a shell, files, the company's task queue, without handing it the run of the host machine. Secrets are masked out of the sandbox by mounting over them, so even with the vault unlocked in the working tree the assistant cannot read the keys.
We reach Shadow two ways. From a terminal when we are at a desk. And, the interesting one, by private direct message over Nostr, so we can check on or steer the company from a phone with no dashboard and no VPN.
The DM channel is NIP-17 private direct messaging, carried over NIP-59 gift wrap. A message is built up in layers:
your text
-> kind:14 rumor (the plaintext message, unsigned)
-> kind:13 seal (NIP-44 encrypted, signed by your real key)
-> kind:1059 gift wrap (NIP-44 encrypted to Shadow, signed by a throwaway key)
The outer wrap is signed by a fresh one-time key and encrypted to the recipient, so a relay that passes it along learns neither who sent it nor what it says. That is the metadata-private property NIP-17 is designed for, and we route every encrypt, decrypt, and unwrap through the same code path the cockpit uses, so the bridge exercises the real production crypto rather than a toy of its own.
Shadow only answers people it knows. The bridge carries an allowlist of our two personal Nostr public keys. A gift wrap is unwrapped far enough to read the true sender, checked against that list, and if the sender is not one of us it is dropped in silence: the assistant is never even invoked for a stranger. Shadow's own signing key is decrypted at boot from the committed, encrypted keyring (the same NIP-49 ciphertext model as the rest of the company) and never written to a log. As with everything else here, one passphrase unlocks it all and nothing sensitive sits on disk in the clear.
What Shadow is for comes down to three jobs.
First, owner-personal work, kept isolated from the agents. Drafts, confidential notes, anything that should not land in the shared repo lives in a private workspace mounted outside that repo and never committed. It is reachable by the two of us and by Shadow, and unreachable by the autonomous department agents, whose world is the shared repo. Private from the agents, not from us.
Second, routing company work to the orchestrator. When we ask Shadow for something that belongs to the company, it does not reach into a department itself. It opens a task on the orchestrator's company-wide queue in the engine, the same queue the cockpit writes to, and the company's normal machinery takes it from there.
Third, oversight. Shadow can read the live state of the company and tell us, in plain language, what the agents are doing and what is waiting on us.
The framing underneath all of this matters more than any single feature: Shadow is accountable, never covert. Private and access-isolated are not the same as hidden. It does not conceal its own actions from the people it works for. We could not build a sneaky one even if we tried, because the agent runtime scans its own persona file and refuses instructions written as covert or insider-threat behavior, anything that says hide from the humans or evade the audit. So we wrote the opposite on purpose: discreet, isolated from the other agents, fully accountable to us. The distinction is the whole design.
A signed audit log is excellent for "why did we ship this." It is poor for "what is happening right now." So the second addition is a visual cockpit for the company, an Astro app with a React island and a PixiJS canvas. Login is gated to a single Nostr key, ours. It reads the company's loopback engine and nothing else, and it publishes no company state to any public relay. On the cockpit, Nostr is login only.
The main view is a live top-down pixel-art office. Each department is a zone with its agent at a desk, and the number of little figures at that desk is the agent's count of concurrent sessions. When nothing is running, the office is quiet. When the agents pick up real work, the desks fill. It does not perform busyness; an idle company looks idle.
Beside the office sit three panels. A kanban rolls every department's tasks into three columns, to do, in progress, and done, with a composer to create and assign a task to any department or to the orchestrator's company-wide queue. A department detail view shows one team's head, status, queue counts, current task, and its recent thread messages, the same delegate, question, answer, report, and decision trail from the last post. An inbox groups those recent messages by agent so you can skim what the company has been saying to itself.
All of it reconciles from a single write of the engine roughly every five seconds, and tasks flow the other way as a single write. The floor, the kanban, and the inbox track the real state of the company within a few seconds of it changing. When the engine is down, the cockpit says so and falls back to placeholder counts rather than faking a running company.
A kanban that only shuffles cards is theater. The piece that makes the board real is the task executor.
It is a small poll loop running next to the engine. Each tick it reads the same cockpit state, finds departments that have open work, and atomically claims one task per department. A claim stamps the task with an owner and a time-boxed lease, and the engine's single-writer queue guarantees that two claimers can never grab the same task. For a claimed task it spawns a real omp coding-agent session, running that department's own agent prompt, pointed at the repo:
omp -p --cwd <repo> --approval-mode write \
--append-system-prompt .omp/agents/<role>.md \
"<task title>
<task body>"
When the session exits, the executor writes its output back onto the task and closes it. The lifecycle is the engine's task lifecycle, end to end:
cockpit composer / Shadow -> open (a fresh, unclaimed task)
executor poll -> claimed (owner + a time-boxed lease)
omp runs the department's agent on the repo
-> done (result recorded) or failed
If omp exits nonzero the task is marked failed, its lease lapses, and a later tick can reclaim it. There are guard rails around the whole thing: a cap on how many sessions run at once across all departments, at most one in-flight claim per department, a cap on how much session output is stored, and an approval mode on every spawned session. The executor is off by default and opt-in per work session, and it runs host-side, because a spawned omp session edits the repo for real. The net effect is that a task you type into the cockpit, or send to Shadow over a DM, becomes a claimed task, becomes a running agent, becomes a completed result with the output attached.
Metadata privacy is real here, and it is not absolute. The gift wrap hides the sender and the content. It cannot hide the recipient: Shadow has to be addressable for a relay to deliver anything to it, so its public key is visible on the outer event. NIP-17 also randomizes timestamps to blunt timing analysis. If your threat model needs to hide that the assistant exists at all, a public relay is the wrong transport, and the upgrade is a private relay we run ourselves.
The signing trust model is the same one we documented before, stated the same plain way. On a single-user, loopback-only box the daemon holds each role's key and signs on behalf of whatever author a local client names. That is daemon-level provenance, not per-process authentication. It is a deliberate trade for the local model, with a clean upgrade the moment the daemon leaves loopback: bearer-token auth on the endpoint plus per-caller-to-role binding, so a signature proves the authenticated caller.
The cockpit observes and steers; it does not yet gate. The one action we will not let an agent take on its own is crossing the repo boundary, reaching outside the company's own folder. The design for that approval is written down: such a step requires a human approval authenticated by our Nostr key in the cockpit, plus a signed compliance decision, before it can proceed. That approval surface is specced, not shipped. Until it exists the boundary stays closed and the cockpit stays read-and-steer only for those actions. We would rather say that out loud than imply a guard that is not built yet.
The pattern in both additions is the same. Autonomy was the easy part; we already had agents that plan, build, and sign their work. Oversight is the part you have to build on purpose, because nothing about an autonomous system produces it for free. A private assistant we can reach from a phone, and a cockpit that shows the true state of the work, are not ornaments bolted onto autonomy. They are how the two of us stay responsible for what the company does. The agents do the work. We stay in the loop, and we stay accountable for it.
I write about agent infrastructure, Nostr, and privacy-first systems as metaend. If you want to reach me, build on any of this, or tell me where it breaks, the door is here:
More writing lives at paragraph.com/@metaend.
Written by metaend.