Scheduler / IPC

A scheduler/IPC primitive queues work with dependency tracking and routes inter-agent messages so that mid-task discoveries reach the orchestrator in time to unblock the pipeline, rather than being silently swallowed.

How It Works

The Claude Code runtime exposes three cooperating surfaces. TaskList tracks work items and their state. SendMessage passes typed messages between agents -- including shutdown_request to terminate a worker cleanly. TeamCreate binds workers into a named group whose members can exchange messages synchronously, waiting for orchestrator acknowledgment before continuing.

These primitives land in explicit sequence. Version 2.1.32 proved the baseline pattern: agent teams with phase and role pivots outperformed fire-and-forget subagents on pipeline workloads. Version 2.1.71 added CronCreate/CronDelete tools plus /loop as a user-facing form -- the first surface an agent itself can call to schedule recurring work without a human re-prompting. Version 2.1.139 added /goal, a persistent completion condition that survives turn boundaries in interactive, -p, and Remote Control modes, turning each agent from one-shot into autonomous.

CLAUDE_CODE_DISABLE_BACKGROUND_TASKS is an instance of this primitive class: it is the instance-level flag that turns the scheduler surface off entirely, confirming the feature is modular and runtime-controlled.

"teams let them ask instead of thrash"

What the Runtime Test Found

The 2026-02-12 teams-vs-fire-and-forget test (28 tasks, 6 waves, ~47 files) produced the clearest evidence for when scheduling and IPC matter.

Wave 3 showed the failure mode of omitting IPC: a Sonnet combinator agent assumed @f3/vendor-alchemy-effect did not yet exist (it had been typechecking since Wave 1). It produced structurally correct but functionally empty stubs with // TODO: implement when vendor pkg exists. No message, no question -- the ambiguity resolved to a confident wrong assumption.

Wave 6 showed the fix. A Sonnet worker encountered a structural gap -- FullStackConfig had no slot for the runner service. It sent a message; the orchestrator replied "extend config later, don't block"; the worker continued to verification. The round-trip took seconds and unblocked the pipeline. Fire-and-forget would have skipped the gap silently or made the same wrong-assumption error as Wave 3.

Message latency was low; shutdown via SendMessage(type: "shutdown_request") was clean; the worker retained context across all three sequential tasks in the wave -- a capability fire-and-forget discards by design.

Why It Matters

The fundamental constraint is latency asymmetry. Static DAGs -- tasks fully specifiable in the dispatch prompt -- have no need for mid-run routing. But integration tasks, where one system's assumptions meet another system's reality, generate unknowns the prompt could not anticipate. Without a return channel, the agent must either guess (Wave 3 outcome) or halt. Scheduling + IPC converts that binary into a third option: route the question, receive an answer, continue.

The 2.1.32-to-2.1.169 arc hardened this substrate progressively: worktree isolation (2.1.50) removed the git index-lock collisions that made parallel workers unsafe; agent_id/parent_agent_id OTEL attributes (2.1.139) made parent/child routing traceable; dynamic workflows (2.1.154) scaled the pattern to tens-to-hundreds of coordinated background agents.

Caveats

Epistemic status: changelog-derived / not runtime-verified beyond the 2.1.32 baseline test. The Wave 6 finding is runtime-verified (2026-02-12). Cron scheduling, /goal persistence, and OTEL tracing attributes are changelog-derived and have not been independently reproduced in this lab. Idle notification spam (five pings in thirty seconds after task completion) is a known side effect of team workers -- system behavior, not agent behavior. Cost parity with sequential fire-and-forget was observed for three-task sequences; behavior at fleet scale (tens-to-hundreds of agents) remains unverified.