Aug 06, 2026 6 min read

What a Coordinator Solves: Queues, Project Setup, and Spokes

Most “AI agent” demos look like a clever chat window. You ask; it answers; maybe it runs a tool. That works until work has to survive overnight, involve another specialist, wait on a human decision, or land in a place someone else can find later.

COO/Operator bundle is a coordinator — an HTTP-first hub that turns principal intent into durable work: queued commitments, governed project folders, and delegated domain agents. It does not try to be every specialist. It decides what should run, where evidence lands, and which mechanism is cheap enough for the job.

This article focuses on three problems a coordinator is built for: queues, project setup, and spokes / machine-to-machine (M2M) agents.

The general problem: work without an operating picture

Without a coordinator, agent work tends to fail in the same places:

  • Intent evaporates when the chat ends.
  • Follow-ups live in someone’s head instead of a drainable queue.
  • Projects are folders of files with no OWNER, milestone, or next step.
  • Domain work (email, commerce, payments, coding) gets shoved into one overloaded prompt.

COO’s answer is operational shape: normalize the request, pick a mechanism, persist artifacts under COO-FILESYSTEM/, and keep commitments visible in Ops so a principal can steer without micromanaging every tool call.

Problem one: queues that never drain

What goes wrong

Ad-hoc agents create activity. Coordinators create commitments. The difference shows up when:

  • Three follow-ups are “important” and none has a wake time.
  • A blocked ask for the principal sits in chat history instead of an inbox.
  • Scheduled cadence (articles, outreach, publish) fights with one-off orders for attention.
  • Failures retry forever — or silently stop — with no operator-visible queue state.

What COO coordinates

COO treats work as queue-shaped:

  • Scheduled tasks live in a runtime queue (seeded cadence and principal-scheduled jobs) that wake/run-due actually drains.
  • Commitment queues (pause backlog + principal inbox) hold deferred and needs_user work so wake order is explicit.
  • Ops surfaces a scheduled rail so operators watch what is next without drowning in every internal lane.
  • Distillation is part of the loop: drafts under COO-FILESYSTEM/articles/drafts/ can be revisited so follow-ups become queue items instead of forgotten prose.

Edge case: interrupted publish

A principal asks for an article, then disappears. A chat-only agent either stops or invents a publish. A coordinator writes the draft under COO-FILESYSTEM/articles/drafts/, records proof in work logs when needed, and leaves publish/share as separate queued or review-gated steps. Prepared is not performed — and the next wake can resume from the artifact path, not from memory of the conversation.

Problem two: project setup without ownership

What goes wrong

“Start a project” in a chat agent often means a couple of markdown files and hope. Reality needs:

  • A stable home under COO-FILESYSTEM/projects/<id>/.
  • Execution docs (PROJECT_PLAN, PROJECT_STATUS, PROJECT_QUEUE, OWNER) so milestones are auditable.
  • A rule for who advances the work when the principal is offline.
  • A way to ship completed incubation out of the live projects tree so it stops looking like open work.

What COO coordinates

COO’s project posture is coordinator-shaped:

  • Filesystem contract — agent content belongs in COO-FILESYSTEM/; projects are first-class longer-running folders.
  • Execution docs — a canonical PROJECT_* baseline so gates and reviewers can check plan/status/queue sync instead of vibes.
  • Idle project advance — when configured, the coordinator proposes advance work from OWNER / milestone / PROJECT_QUEUE signals, then passes OWNER or invokes the matching modular agent (for example a coding spoke/agent) rather than polishing docs forever.
  • Ship path — scripts/coo_ship_project.py moves finished incubation to archive and updates the shipped ledger so the operating picture stays honest.

Edge case: two owners, one milestone

A coding project stalls because both COO and a specialist agent “own” the next milestone in different files. The coordinator’s job is not to rewrite the app in chat. It is to reconcile OWNER, record the blocker in PROJECT_STATUS when principal input is required, and invoke the owner that should implement — with the next step visible in the queue.

Problem three: spokes and M2M agents without a hub

What goes wrong

Teams either:

  • Stuff every domain into one mega-agent (untestable, unsafe, always warm), or
  • Spin every specialty as a full process (expensive, always-on, unclear who routes).

Neither scales. Domain ops need deterministic, reviewable paths. Persistent workers need isolation. Reasoning sub-tasks need to be ephemeral.

What COO coordinates

COO uses a cost ladder (cheapest mechanism that fits):

| Mechanism | Role under the coordinator | |-----------|----------------------------| | COO tool loop | Rare one-offs the hub can do inline | | In-process spoke | Deterministic domain ops via spoke dispatch (email, payments, shopkeeper mapping, …) — auditable, often review-gated | | In-runtime role agent | Ephemeral researcher / coder / reviewer thinking inside the hub | | Spawned M2M agent | Separate process(es) with their own port and state — delegated workers (commerce assist, cinnamon, saffron, …) started lazily |

Core principle: add capability as a spoke; spawn an M2M process only when persistent state, autonomy, or isolation forces it. Heavy mechanisms stay stopped by default and light up on first use.

The hub stays responsible for routing, approval envelopes where money or external side effects matter, and filesystem bridges so specialists write into known trees instead of inventing paths.

Edge case: refund vs research

“Refund the blue jacket” is not a research essay. The coordinator should route money movement through a spoke/payment path with review binding — not through an open-ended chat loop. Separately, “explain why refunds failed last week” can use a researcher role or M2M analytics worker. Same domain language; different mechanism; hub decides.

What this changes for operators

Thinking of COO as a coordinator reframes success:

  • Queues make follow-ups drainable and visible.
  • Project setup makes ownership and milestones durable under COO-FILESYSTEM/projects/.
  • Spokes and M2M agents keep specialists narrow while the hub remains the principal’s single front door (web, messaging bridges, Orders, Workflow, Ops).

You still need models, tools, and good prompts. The coordinator’s claim is narrower: when work matters, it should be queued or owned; when a specialist is needed, it should be invoked on purpose; when something is done, evidence should live on a path you can open tomorrow.

What COO does not promise

COO does not make every spoke healthy, every queue empty, or every M2M agent free to run. External services fail; principals stay in the loop for approvals and missing inputs. The coordinator’s job is to keep those realities explicit — in queue state, project docs, and dispatch contracts — instead of hiding them inside a single unbounded chat turn.

Sources and claim boundaries

  • COO/README.md — COO as author coordinator / HTTP-first operator surface (Orders, P2A, Workflow, Ops).
  • COO/docs/FILESYSTEM_CONTRACT.md — COO-FILESYSTEM/ layout, drafts vs briefs, project folders, operator loop into queue items.
  • COO/docs/development/AGENT_TOPOLOGY_AND_ACTIVATION.md — spoke vs role agent vs M2M cost ladder and lazy activation.
  • COO/docs/development/IDLE_PRODUCTIVE_WORK_PLAN.md — idle project advance, OWNER pass / invoke.
  • COO/docs/development/README.md — commitment queues, scheduled rail, spoke dispatch posture.

Scenarios (interrupted publish; dual ownership; refund vs research) are illustrative of coordinator routing and filesystem contracts documented in-repo. They are not claims about a specific live customer deployment.