The failure this prevents is specific — a sub-agent burns the end of a limit window and the session the owner is actually sitting in dies mid-turn, because the credits went somewhere nobody was watching. So it is a condition on spawning rather than a refinement: an endpoint that can start unattended work without checking is wrong from its first call, and the symptom lands on someone else's conversation. Wired into POST /command-hq/commanders/new, which — this is the finding — already IS the spawn mechanism the sub-agents item was asking for. It starts a turn with ws: null, waits only for session:claude, and returns the transcript id, with command_hq_sessions naming, listing and costing it. So "commander or something lighter" answers itself: a commander costs nothing extra and a lighter thing would need its own registry to be visible at all. What is still missing is only the agent-callable surface. Refuses rather than queues or downgrades. Queueing means holding work against a window Officer does not control, and the reset it would wait for is a claim about a shared pool — every claude on the machine spends these, including terminals and pipelines. A refusal naming the window, the percentage and the reset is something a caller can act on now. The floor is 15% and the reasoning is in the file: the interactive failure is not "cannot start a chat", it is "a turn already in flight is cut off", and a turn costs a fraction of a window. Fails OPEN, deliberately. The numbers come from an external endpoint with a credential Officer does not own, so a blip or a signed-out CLI must not stop every spawn on the machine with an error about usage that has nothing to do with usage. The problem is reported so a caller can say "started, but unchecked". Seven tests on the pure rule — tightest window decides rather than the average, no limits allowed rather than blocked, exactly-at-the-ceiling refuses. Verified against the live account, where it correctly refuses right now at Session 90%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.4 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| sub-agents/an-api-endpoint-for-spawning-an-agent-with-a | An API endpoint for spawning an agent with a prompt | sub-agents | open | 2026-08-21 | stated | 1 |
An API endpoint for spawning an agent with a prompt. Wanted 2026-08-21. An agent calls it, names a prompt, and gets another agent running. A sub-agent system — but defined by the owner, which is the whole point of building one rather than leaning on the harness's own: the shapes, the limits and the vocabulary are Officer's, so every harness gets the same door and the definition does not change when a CLI does.
It has more of a starting point than it looks. startClaudeTurn already runs a turn with no browser
attached (nudger.ts:102, ws: null), so the mechanism for "run an agent from the backend" is proven —
what is missing is spawning a NEW one on request rather than feeding a known session, plus the surface
an agent can actually call, which is MCP or an authenticated route.
Open: whether a spawned agent is a Command HQ commander (named, listed, costed — command_hq_sessions
already does all three) or something lighter that disappears when it finishes; how its output returns to
the caller, streamed or awaited; and what the caller may set — model, effort, cwd, permission mode — versus
what Officer fixes.
Bounded by the budget rule in sub-agents/spawning-must-respect-the-account-s-own, which is not
optional. An endpoint that spawns freely is exactly how a weekly limit gets spent by something nobody
was watching.
2026-08-21, narrowing this considerably. The endpoint largely exists:
POST /api/command-hq/commanders/new takes a prompt, starts a turn with ws: null, waits only for
session:claude rather than the whole turn, and returns Claude's own transcript id. A commander is named,
listed and costed by command_hq_sessions already.
So the open question "commander or something lighter" answers itself from the code: making a spawned agent a commander costs nothing and gets all three for free, where a lighter thing needs its own registry to become visible at all. The budget condition is now on that route, so anything spawned through it already respects the window.
What is genuinely left is the SURFACE an agent can call — MCP tool or authenticated route — and how output returns to the caller. That is the remaining work on this item; the mechanism underneath it is done.