The Hub Is Not the Workflow: Designing Spokes That Can Fail Independently

This article extends Shipping a Drainable Workflow: From Intent to Verified Completion with a narrower question: how should builders divide work between an orchestration hub and independently verifiable spokes?

Start with ownership, not topology

“Hub and spoke” is an attractive diagram because it makes a distributed system look orderly. One coordinator receives an intention, routes it to several workers, and gathers their answers. But the picture says little about the boundaries that matter in operation. A spoke that can touch five unrelated resources, retry forever, or report only a final paragraph is not independent in any useful sense.

A better starting point is ownership. Give each spoke one primary outcome and one durable destination. A research spoke may produce a source-backed brief. A filesystem spoke may create and verify a draft. A communications spoke may prepare an outbound message, but leave sending behind its review gate. The hub can sequence these outcomes, yet it should not silently absorb their state.

This division makes a commitment legible:

• the hub records what was requested and which spoke owns the next unit;
• the spoke records the work it attempted and the evidence it produced;
• the destination artifact records the result that another step may consume.

The topology then follows the contract rather than replacing it.

Make the hub a dispatcher, not a second worker

A common failure mode is a coordinator that gradually becomes omniscient. It reads every source, repeats every tool call, rewrites every result, and decides whether each spoke “really” finished. The system still has spokes on paper, but the hub is now the hidden bottleneck.

The hub’s durable responsibilities should be small:

1. 1. identify the next eligible commitment;
2. 2. pass the spoke only the context it needs;
3. 3. record the handoff and its expected destination;
4. 4. accept a receipt, failure, or explicit pause;
5. 5. decide whether another bounded step is allowed.

That shape preserves the lesson from the earlier drainable-workflow piece: queued, attempted, completed, and verified are different states. A hub should not mark a spoke complete because a call returned successfully. It should check for the spoke’s receipt or verified artifact, then advance the commitment.

This is also where retrieval becomes a product decision. The hub may know the project and priority, while the spoke receives the relevant contract, current artifact, and narrowly selected evidence. Passing the entire shared memory to every worker is not coordination; it is context leakage. It increases the chance that a spoke acts on stale or competing instructions and makes the eventual explanation harder to audit.

Design spokes with a failure envelope

Independence is not the absence of failure. It is the ability to contain failure. Before implementing a spoke, define its failure envelope:

• Inputs: What exact files, records, or arguments may it read?
• Writes: Which destination may it change?
• Budget: How many tool steps, retries, or tokens may it consume?
• Terminal states: What counts as success, blocked, partial, or skipped?
• Evidence: What must be left behind for the hub to continue?

A small receipt can carry most of this information:

``json { "spoke": "draft-writer", "commitment": "article_daily-2026-09-04", "status": "verified", "artifact": "COO-FILESYSTEM/articles/drafts/example.md", "attempts": 1, "next": "human_review" } ``

The exact schema is less important than its terminal meaning. “Verified” should point to something inspectable. “Blocked” should name the missing input or permission. “Partial” should identify what is safe to reuse and what remains undone. Without those distinctions, the hub has to infer state from prose, which recreates the invisible workflow the architecture was meant to eliminate.

A failure envelope also makes retries safer. If a spoke cannot write its destination, the hub can stop that branch rather than dispatching a duplicate worker. If a source is unavailable, the research spoke can return a bounded gap rather than filling it with invented certainty. Independence is valuable precisely because one spoke can pause while other commitments remain understandable.

Use artifacts as the spokes’ shared language

Agents often coordinate through messages because messages are convenient. Durable artifacts are better for handoffs that need to survive a restart, a review delay, or a change of operator. The artifact tree gives each spoke a stable vocabulary: drafts, published copies, work logs, project status, and research notes each signal a different lifecycle.

That does not mean every intermediate thought deserves a file. It means the output that another step relies on should have a destination with a clear owner. A spoke can return a short response saying “written and verified,” while the actual detail lives in the artifact and its receipt.

This arrangement also protects review boundaries. A content spoke can create a draft without publishing it. A communications spoke can prepare a message without sending it. The hub can present those artifacts for approval without pretending that preparation and external effect are the same operation. In a system that values operator calm, the absence of an external side effect is itself useful state.

When an artifact is missing, the hub should not compensate by trusting the chat response. It should surface the missing proof and leave the commitment paused. That is a small but important discipline: evidence is a handoff protocol, not decorative metadata.

Let spokes be asynchronous without becoming unowned

A hub-and-spoke system does not need every spoke to finish in one uninterrupted run. A long research task, a review wait, or a temporary service failure may require a later wake. Asynchrony becomes safe when ownership and next action remain explicit.

Each dispatched spoke should therefore have a lease-like record: who owns the work, what destination is expected, when the attempt began, and what event permits resumption. If the spoke stops, the record should say whether it is waiting for a human, a dependency, a scheduled retry, or a new input. A paused branch is not lost work when its next transition is visible.

The hub should also avoid competing with itself. One commitment should have one active owner unless the system explicitly supports parallel branches with separate destinations. Otherwise a delayed response can arrive after a replacement worker and overwrite a newer result. Idempotent destinations, commitment identifiers, and receipts are modest controls, but together they prevent the most expensive form of orchestration confusion: two workers believing they are the only owner.

Conclusion: build the smallest useful constellation

The companion lesson is straightforward: a hub-and-spoke architecture earns its name only when the spokes have real boundaries. Start with one commitment, one destination, one budget, and one receipt. Keep the hub responsible for routing and state transitions, not for redoing every worker’s job. Keep external effects behind their review gates, and treat missing evidence as a visible pause rather than an invitation to guess.

For a practical next pass:

1. 1. Choose one existing workflow and list its true outcomes.
2. 2. Assign each outcome a single spoke and durable destination.
3. 3. Write down the spoke’s inputs, write scope, budget, and terminal states.
4. 4. Require a receipt that links the outcome to an inspectable artifact.
5. 5. Test one failure path: unavailable input, permission error, or review wait.
6. 6. Confirm that the hub can stop and resume without duplicating the work.

The goal is not a more elaborate diagram. It is a system in which every branch can explain what it owns, what it changed, and why the next step is—or is not—allowed.