A coordination hub each founder runs from their own side: your agents on your machine, the other founder's assistant across the wall, landing in the same place. Designed today, not yet built. Three decisions below, one of them Stacy's.
You open a hub, it shows what the fleet has been doing and what the other side has said, and you dispatch work back in plain language — it picks the transport per recipient. It is deliberately not a standing session: sessions die, and a stream that lives only in one conversation's scrollback dies with it.
Two files do the work. stream.md is the human-readable log — when, who, which direction, what. state.json is the live picture: who is convened, what is outstanding, when the other side was last checked.
The rule that keeps it honest: state.json is a cursor over real sources, never a second copy of them. It records that something was checked and what is open. It never duplicates the content. Everything that went wrong on the way to this design went wrong by ignoring that.
This build was briefed to make the hub the designated reader of #bench-log. That route was superseded before the brief was written.
#bench-log · Slack → GitHub issues · thehiagency/hi-agents
CANON §5 routes assistant-to-assistant coordination through GitHub issues, not chat relay. Craig's assistant-wall-spec §3 reaffirmed it the same day and was blunt about the alternative: "Not Slack. Stacy closed that and this does not reopen it." The fleet-messaging skill still carried the old route; Craig amended it and shipped the correction as v0.25.1, so installed copies get it on update.
Nothing is lost in the move. The reason #bench-log was attractive was that both founders could read every exchange. Issues give that for free, permanently, without either assistant doing anything.
Every one of these was a fix that had genuinely been made, sitting somewhere the people who needed it could not see:
A commit that never left the machine. A manifest that stayed on the old version, so plugin update was a silent no-op. A rendered page committed into a repo with no remote, so it never deployed. And a share link pinned to a version from before the thing it warned about was fixed.
The rule, written into the design: the source moving is not the running copies moving. Check the copy, not the source. It is why the hub reads canonical files rather than keeping its own, and why this page will not claim anything is live until someone has looked at the live thing.
| Recipient | Transport | Why |
|---|---|---|
| The other founder's assistant | GitHub issue | Canon. Works from both sides, auditable by both founders by default. |
| An agent, bounded task | Spawned as a subagent | Cheap, immediate, does not need that agent's session awake. |
| An agent, continuing a thread | Message its standing session | Only where continuity genuinely matters — see 05. |
Cross-founder is a mailbox, not a doorbell: you see what has been posted at the moment you look. Quiet stretches mean the other side has not posted, which is expected rather than broken.
Measured on Elizabeth's machine this week: a single cross-session message costs roughly 2.26M tokens and $2.59, because waking a standing session makes it re-process its entire context. Twenty-four of them over five days came to 14% of total fleet usage.
So the hub defaults to the cheap thing: spawn a subagent for anything bounded, and only wake a standing session when the thread it is already on genuinely matters. "Pull the whole fleet in" stays possible, but it is a deliberate act rather than a reflex.
This is also why the hub points at sources instead of copying them — asking "what am I waiting on?" should be one small read, not a replay of everything that ever happened.
Neither founder will sit in the hub all day, so a message from the other side could go unseen for days. The proposed fix is a small scheduled check — every two hours from 6am to 5pm Pacific, a window set by Stacy's working day, since hers is the side that posts.
Its job is not to fetch the news. Opening the hub already does that. Its job is to say there is news, so you know to look.
And it only earns its place if that is possible, which is untested. A scheduled run cannot message a session — it can only write a file, which opening the hub already covers. So unless a notification can fire from an unattended run, the routine is pointless at any frequency and should not be built. That gets tested before anything is written.
Two prerequisites, both on Elizabeth's machine: a read-only permission rule so an unattended run can read issues without stalling on an approval prompt, and an app restart so it loads. The hub works fully without any of this.
The hub ships inside the fleet plugin, so it arrives on both machines with the next update — no second repo, nothing to set up by hand. The GitHub issues are the seam between the two hubs, and each founder's own stream stays local and private to them.
What that means in practice: if only one founder runs a hub, it still works — issues are a mailbox and the other side can read them however they like. Running one on both sides is what makes it a conversation rather than a drop box.
Stacy's side would need the same read-only permission rule if she wants the notification routine, and her window would be set by Elizabeth's working day rather than her own.
Sequential rather than parallel, because the local pieces bind to the skill's shape — building both at once would mean guessing at an interface that is about to exist.
| Order | Who | Builds |
|---|---|---|
| 1 | Craig | The skill, into the fleet plugin, plus the design doc where both founders can pull it |
| 2 | Hub | The stream and state files, the routine and its guards, the routing |
The full design is written up and travels with the repo, so neither half is built from memory of a conversation.
Checking whether project status could be read from Asana rather than a new file, Craig found thirteen projects populated with real tasks and the Pipeline board at zero.
That matters because the August ops plan pegged Pipeline's WIP limits to hi!'s published capacity claims. If the board those claims derive from is empty, it is worth knowing whether the claim still has something standing behind it.
Parked at Elizabeth's instruction and surfaced here rather than quietly reconciled, because it touches claims discipline — which is a founders' call, not an agent's.