Index
Hub · Build design · 5 September 2026

One place to convene the fleet, and one stream for everything it says back.

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.

What it is

01

A skill either founder loads, not a session either founder has to keep alive

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.

Lead Hub · with Craig

Both founders

What we found on the way

02

The brief pointed at the wrong channel, and canon had already moved

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.

Lead Craig · found by Hub

Both founders
03

The same failure appeared four times in one day, at four different levels

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.

Lead Hub

Both founders

How it routes

04

Three transports, chosen by who is being reached

RecipientTransportWhy
The other founder's assistantGitHub issueCanon. Works from both sides, auditable by both founders by default.
An agent, bounded taskSpawned as a subagentCheap, immediate, does not need that agent's session awake.
An agent, continuing a threadMessage its standing sessionOnly 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.

Lead Hub · with Craig

Both founders
05

Waking an agent costs real money, and that shaped the whole design

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.

Lead Craig · measured by Craig, applied by Hub

Both founders

The one open build question

06

A routine that says "there is news" — if a notification can actually reach you

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.

Lead Hub

Elizabeth

What Stacy would need

07

Symmetric by construction, but it is still a choice

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.

Lead Hub

Stacy

Who builds what

08

Craig first, then the local half

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.

OrderWhoBuilds
1CraigThe skill, into the fleet plugin, plus the design doc where both founders can pull it
2HubThe 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.

Lead Craig · with Hub

Both founders

One thing found in passing

09

The Asana Pipeline board is empty, and the capacity claims lean on it

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.

Found by Craig · raised by Hub

Both founders