Consolidate scheduler creation and todo continuation into the engine; remove CLI compensating layers

[acoliver]

Problem

The agentic turn loop lives inside the engine (AgenticLoop in packages/agents), and AgentImpl.stream() delegates directly to it. This was the goal of the core API refactoring (#2034, #2372, #1595). However, the CLI still has compensating layers that duplicate engine-owned responsibilities ? and these layers only exist in the CLI's React app, not in ACP/Zed or other consumers.

This divergence was discovered while fixing #2653 (ACP/Zed: task tool crash + todo_pause loop-break). Two specific divergences were found:

1. Scheduler creation: CLI has its own factory, ACP uses the engine fallback

The CLI registers a schedulerFactoryProvider via interactiveToolScheduler.ts that wraps scheduler.schedule in a proper closure. ACP/Zed does not register one, so the subagent falls back to initInteractiveScheduler() in packages/agents/src/core/subagentExecution.ts. That fallback had a receiver-loss bug (schedule: scheduler.schedule without binding this) that the CLI's factory masked. We fixed the symptom in #2655, but the root cause is that scheduler creation is not fully consolidated in the engine ? each consumer shouldn't need to provide its own correctly-binding factory.

Files involved:

• packages/agents/src/core/subagentExecution.ts ? engine fallback (now fixed)
• packages/cli/src/runtime/interactiveToolScheduler.ts ? CLI's separate factory
• packages/core/src/config/toolRegistryFactory.ts ? getInteractiveSubagentSchedulerFactory() indirection

2. Todo continuation: CLI has a React-layer loop on top of the engine loop

The CLI's useTodoContinuation.ts hook fires a brand new agent.stream() call after the engine loop finishes, if there are pending todos. This is a second, outer continuation loop that overlaps with what should be engine-owned behavior. It also has its own todoPaused gate (useTodoPausePreserver.ts) that was masking the fact that AgenticLoop.buildNextMessage() didn't stop on todo_pause.

We fixed AgenticLoop.buildNextMessage() to check for successful todo_pause (#2655), but the CLI still has the redundant React continuation layer. ACP/Zed has no such layer and relies entirely on the engine.

Files involved:

• packages/cli/src/ui/hooks/useTodoContinuation.ts ? React continuation loop (fires new agent.stream())
• packages/cli/src/ui/hooks/useTodoPausePreserver.ts ? React pause gate
• packages/cli/src/ui/containers/AppContainer/hooks/useTodoContinuationFlow.ts ? orchestration
• packages/agents/src/core/TodoContinuationService.ts ? engine-side service (exists but partially bypassed)
• packages/agents/src/core/MessageStreamOrchestrator.ts ? checks todoPauseSeen but doesn't see real tool responses from AgenticLoop

3. MessageStreamOrchestrator pause detection is wired to the wrong layer

MessageStreamOrchestrator checks for todo_pause via ToolCallResponse events from Turn.run(), but the real Turn only emits ToolCallRequest events. The actual tool responses come back later from AgenticLoop's scheduler ? which MessageStreamOrchestrator never sees. This means the orchestrator's todoPauseSeen detection only works in tests that mock Turn.run() to emit synthetic ToolCallResponse events. The existing MessageStreamOrchestrator.todoPause.test.ts tests mock this path and don't reflect real execution.

Context: Prior refactoring work

This is a continuation of the multi-issue effort to move the agentic loop and all engine behavior into the packages/agents package:

• Consolidate the agentic turn loop into the engine (agents package) with policy + approval injection points (Parent #1568) #2034 ? Consolidate the agentic turn loop into the engine (parent 0.10.0 Code Improvement Plan #1568)
• Interactive CLI must consume agent.stream() instead of assembling the agentic loop (part of #1595) #2372 ? Interactive CLI must consume agent.stream() instead of assembling the agentic loop
• Refactor CLI to consume core API #1595 ? Refactor CLI to consume core API (umbrella)
• Recording-native checkpoints and session branching: unify /chat save with /continue (part of #2614) #2625 ? Port Zed integration onto the Agent API; delete its hand-rolled chat loop
• PR Consolidate agentic turn loop into engine (Fixes #2034) #2050 ? Consolidate agentic turn loop into engine (Fixes Consolidate the agentic turn loop into the engine (agents package) with policy + approval injection points (Parent #1568) #2034)
• PR Interactive CLI consumes agent.stream() instead of assembling the agentic loop (Fixes #2372) #2382 ? Interactive CLI consumes agent.stream() (Fixes Interactive CLI must consume agent.stream() instead of assembling the agentic loop (part of #1595) #2372)
• PR Fix ACP/Zed: task tool crash + todo_pause loop-break (Closes #2653) #2655 ? Fixed the two ACP/Zed bugs in the engine (ACP/Zed: task tool crashes with 'this.isRunning is not a function' and todo_pause does not stop the continuation loop #2653)

The engine loop is in the right place. What remains is removing the CLI's duplicated/overlapping layers so there is one continuation and scheduling path for all consumers.

Proposed direction

1. Consolidate scheduler creation into the engine. The initInteractiveScheduler() fallback in subagentExecution.ts should be the canonical path. The CLI's interactiveToolScheduler.ts factory should be removed or reduced to configuration only (not method-binding). No consumer should need to know that scheduler.schedule requires a closure to preserve this.

2. Move todo continuation into the engine. The React useTodoContinuation hook's logic (checking for pending todos, generating continuation prompts, deciding whether to continue) should move into the engine ? either into AgenticLoop itself or into a dedicated continuation controller that AgentImpl.stream() uses. The CLI should become a pure event consumer.

3. Fix the MessageStreamOrchestrator pause detection. Either route real tool responses through the orchestrator, or move the pause check entirely into AgenticLoop.buildNextMessage() (where our Fix ACP/Zed: task tool crash + todo_pause loop-break (Closes #2653) #2655 fix already partially lives). The orchestrator's existing tests need to reflect real execution paths, not mocked ToolCallResponse events.

4. Remove or deprecate the React-layer pause gate. useTodoPausePreserver.ts and the todoPaused state in useTodoContinuation.ts should become unnecessary once the engine authoritatively handles pause.

5. Add integration tests that exercise the full agent.stream() ? AgenticLoop path for both CLI and ACP-style consumers, so behavioral parity is enforced.

Why 0.11.0

This is an architecture refactor that touches multiple packages. It should not block 0.10.0 feature work. The immediate bugs from the divergence were fixed in #2655 (merged to 0.10.0). This issue tracks the full consolidation.

@coderabbitai please create a plan

[coderabbitai]

🔗 Related PRs

#1311 - fix(todo-continuation): prevent pause looping by persisting pause state [merged]
#1886 - fix(stream): prevent Kimi tool call ID collisions and silent scheduler drops (Fixes #1872) [merged]
#2097 - Fix error-on-cancel and ESC not cancelling subagents (Fixes #2076, Fixes #2074) [merged]
#2382 - Interactive CLI consumes agent.stream() instead of assembling the agentic loop (Fixes #2372) [merged]
#2655 - Fix ACP/Zed: task tool crash + todo_pause loop-break (Closes #2653) [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[acoliver]

@CodeRabbit note The CLI does need layers to "display" and collect approvals but the core flow should live in the engine and be exposed via the api (maybe with callbacks)? Dunno if that's what it means. There should not be more than one way to get at the scheduler. its construction should be singleton... its should process messages and do callbacks or whatever (let's architect that properly)

[coderabbitai]

Warning

A plan generation is already in progress. Please wait for it to complete before requesting a new plan.

[coderabbitai]

Coding Plan

Summary

• Consolidate receiver-safe scheduler construction entirely in the engine (subagentExecution.initInteractiveScheduler), reducing the CLI's subagent factory to display-callback configuration while preserving the still-needed main scheduler for slash commands.
• Port pending-todo continuation from the CLI React hook into an engine-side controller driven by AgenticLoop, so continuation is one internal loop decision shared by all consumers instead of an externally-fired second agent.stream().
• Make AgenticLoop.buildNextMessage() the single authoritative pause handler, remove MessageStreamOrchestrator's dead synthetic-event pause branch, and delete the redundant CLI continuation/pause hooks (and the orphaned duplicate service).
• Enforce parity with real-infrastructure engine tests and a dual-path CLI/ACP API test so both surfaces behave identically on incomplete-todo scenarios.

Design Choices

Design Choice 1: Where should the ported continuation-decision logic live in the engine?

Options Considered:

1. Inline the decision (pending-todo detection, prompt generation, gating) directly inside AgenticLoop.buildNextMessage()/run().
2. Add a dedicated engine-side continuation controller (extending the existing TodoContinuationService) that AgenticLoop consults after a turn completes.

Chosen Option: 2

Rationale: A dedicated controller keeps the loop focused on tool scheduling, lets us reuse TodoContinuationService's existing pause/classification helpers, and mirrors the already-present hasSuccessfulTodoPause seam without bloating the loop.

Design Choice 2: How should continuation turns be surfaced to consumers?

Options Considered:

1. Keep continuation entirely internal to the loop so the continuation turn's events (text, tool-call, etc.) flow through the existing agent.stream() output naturally, with no new AgentEvent discriminant.
2. Add a new AgentEvent discriminant (e.g. todo-continuation) requiring updates to event-schema.ts, eventAdapter.ts, and every exhaustive consumer switch.

Chosen Option: 1

Rationale: Driving continuation inside the loop means the follow-up turn is just more of the same stream; this avoids a large blast radius across CLI/Zed dispatchers. An optional notice event may mark the continuation for debugging.

Design Choice 3: What to do with MessageStreamOrchestrator's todoPauseSeen detection?

Options Considered:

1. Remove the broken in-orchestrator pause branch and make AgenticLoop.buildNextMessage() the single authoritative pause handler.
2. Re-route real scheduler tool responses back into the orchestrator so its detection works.

Chosen Option: 1

Rationale: The #2655 fix already put authoritative pause handling in AgenticLoop; removing the dead orchestrator branch avoids re-plumbing tool responses across layers and eliminates a misleading test.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Consolidate scheduler creation and binding in the engine

Make the engine the single owner of receiver-safe scheduler construction so no consumer needs to supply a correctly-binding factory. The CLI keeps its main interactive scheduler (still required for slash-command tool execution and display-bucket identity) but stops owning subagent scheduler binding.

Task 1: Establish a single receiver-safe scheduler helper in the engine

Ensure all subagent scheduler paths converge on one binding-safe construction point.

• In packages/agents/src/core/subagentExecution.ts, confirm initInteractiveScheduler() is the canonical path and that its receiver-preserving schedule closure is applied uniformly to both the schedulerFactory-provided handle and the getOrCreateScheduler fallback.
• Extract the binding/closure wrapping into a small shared helper so any handle passed in from a consumer is normalized to a receiver-safe form inside the engine (defense-in-depth: a consumer supplying schedule: scheduler.schedule can no longer reintroduce the bug).

Task 2: Reduce the CLI subagent scheduler factory to configuration only

Strip method-binding responsibility from the CLI shim.

• In packages/cli/src/runtime/interactiveToolScheduler.ts, reduce useExternalSchedulerRegistration/useExternalSchedulerFactoryCreator so the CLI supplies only the React display callbacks (output/tool-update/editor callbacks) and lets the engine construct and bind the scheduler; remove the duplicated getOrCreateScheduler-plus-binding logic in the subagent path.
• Leave useScheduler() (main session scheduler keyed by config.getSessionId()) untouched — it remains the live path for slash-command tool execution and anchors the React display state.

Task 3: Simplify the core registration indirection

Trim the plumbing that existed only to inject a binding-aware factory.

• Review packages/core/src/config/toolRegistryFactory.ts (schedulerFactoryProvider/getInteractiveSubagentSchedulerFactory) and packages/core/src/config/configBaseCore.ts (subagentSchedulerFactory slot): reduce them to pass through display configuration only, or remove the slot if the CLI no longer needs to inject anything beyond callbacks.
• Verify remaining consumers of getOrCreateScheduler/setInteractiveSubagentSchedulerFactory across packages/agents (subagentRuntimeSetup.ts, task.ts), packages/a2a-server, and packages/core still compile and behave correctly against the simplified surface.

🤖 Prompt for AI agents

Implement Phase 1: consolidate scheduler creation and binding entirely in the
engine, so the CLI no longer needs to supply a correctly-binding factory for
subagent scheduling while its main interactive scheduler remains untouched.

- In `packages/agents/src/core/subagentExecution.ts`, verify
`initInteractiveScheduler()` is the canonical scheduler-construction path, and
ensure the receiver-preserving `schedule` closure is applied uniformly to both
the `schedulerFactory`-provided handle and the `getOrCreateScheduler` fallback.
Extract this binding/closure wrapping into a small shared helper so any handle
passed in from a consumer is normalized to a receiver-safe form inside the
engine, as defense-in-depth against a consumer supplying an unbound `schedule:
scheduler.schedule`.
- In `packages/cli/src/runtime/interactiveToolScheduler.ts`, reduce
`useExternalSchedulerRegistration`/`useExternalSchedulerFactoryCreator` so the
CLI supplies only React display callbacks (output/tool-update/editor callbacks),
letting the engine construct and bind the scheduler. Remove the duplicated
`getOrCreateScheduler`-plus-binding logic in the subagent path. Do not touch
`useScheduler()` (the main session scheduler keyed by `config.getSessionId()`),
since it remains the live path for slash-command tool execution and anchors
React display state.
- Review `packages/core/src/config/toolRegistryFactory.ts`
(`schedulerFactoryProvider`/`getInteractiveSubagentSchedulerFactory`) and
`packages/core/src/config/configBaseCore.ts` (`subagentSchedulerFactory` slot).
Reduce these to pass-through display configuration only, or remove the slot
entirely if the CLI no longer needs to inject anything beyond callbacks.
- Verify remaining consumers of
`getOrCreateScheduler`/`setInteractiveSubagentSchedulerFactory` across
`packages/agents` (`subagentRuntimeSetup.ts`, `task.ts`), `packages/a2a-server`,
and `packages/core` still compile and behave correctly against the simplified
surface.

Phase 2: Move todo continuation into the engine

Port the "keep working while todos are pending" behavior out of the CLI React layer and into the engine so ACP/Zed and non-interactive CLI gain parity automatically. Continuation becomes an internal loop decision rather than an externally-fired second agent.stream().

Task 1: Add an engine-side continuation controller

Centralize the pending-todo continuation decision.

• Extend packages/agents/src/core/TodoContinuationService.ts (or add a focused controller alongside it) to expose a post-turn decision: read active todos from TodoStore (packages/tools/src/tools/todo-store.ts), select the most relevant todo (in_progress before pending), respect the todo-continuation ephemeral setting, honor the paused state, and generate the continuation prompt text (including the YOLO-mode wording variant).
• Preserve the behaviors currently asserted in useTodoContinuation.spec.ts (trigger only when the turn finished with no blocking tool calls, attempt-count tracking, no double-fire on rapid completion, malformed-todo safety).

Task 2: Drive continuation from within AgenticLoop

Replace the CLI's external second stream with an internal continuation turn.

• In packages/agents/src/core/agenticLoop/AgenticLoop.ts, after a turn completes with no continuing tool responses, consult the continuation controller; if continuation is warranted, build the continuation message and feed it back into the loop as the next turn rather than terminating.
• Keep the existing successful-todo_pause stop guard as the authoritative gate that prevents continuation when the model deliberately paused.
• Ensure continuation turns emit through the normal event stream so all consumers render them without new event types (optionally emit a notice for observability).

🤖 Prompt for AI agents

Implement Phase 2: move the pending-todo continuation behavior from the CLI
React hook into the engine, so it becomes a single internal loop decision shared
by all consumers (CLI, ACP/Zed, non-interactive CLI) instead of an
externally-fired second `agent.stream()` call.

- Extend `packages/agents/src/core/TodoContinuationService.ts` (or add a focused
controller alongside it) with a post-turn decision capability: read active todos
from `TodoStore` (`packages/tools/src/tools/todo-store.ts`), select the most
relevant todo (`in_progress` before `pending`), respect the `todo-continuation`
ephemeral setting, honor the paused state, and generate the continuation prompt
text (including the YOLO-mode wording variant).
- Preserve the behavioral guarantees previously asserted in
`useTodoContinuation.spec.ts`: trigger only when the turn finished with no
blocking tool calls, track attempt counts, avoid double-firing on rapid
completion, and remain safe against malformed todo data.
- In `packages/agents/src/core/agenticLoop/AgenticLoop.ts`, after a turn
completes with no continuing tool responses, consult the new continuation
controller. If continuation is warranted, build the continuation message and
feed it back into the loop as the next turn instead of terminating.
- Keep the existing successful-`todo_pause` stop guard as the authoritative gate
that prevents continuation when the model deliberately paused.
- Ensure continuation turns flow through the normal event stream (no new
`AgentEvent` discriminant), so all consumers render them naturally; optionally
emit a `notice` event for observability/debugging.

Phase 3: Make the engine authoritative for pause and fix orchestrator detection

Consolidate pause handling so the React pause gate becomes unnecessary and remove the orchestrator's non-functional pause branch.

Task 1: Make pause state engine-authoritative

Persist and honor pause in the engine.

• Ensure AgenticLoop/continuation controller reads and writes paused state via TodoStore (the same side-channel Zed already observes), so a successful todo_pause stops continuation for all consumers and resumes on the next user turn without relying on CLI React context.

Task 2: Remove the broken pause detection from MessageStreamOrchestrator

Eliminate detection wired to events it never receives in production.

• In packages/agents/src/core/MessageStreamOrchestrator.ts, remove/retire the todoPauseSeen branch (_evaluatePostTurn/_processStreamIteration) that depends on ToolCallResponse events the real Turn never emits, deferring pause authority to AgenticLoop.buildNextMessage().
• Preserve the still-valid in-stream reminder behavior of TodoContinuationService (reminders/complexity escalation) that does operate on real request/response flow.

Task 3: Update orchestrator tests to reflect real execution

Replace synthetic-event tests with realistic coverage.

• Rework packages/agents/src/core/MessageStreamOrchestrator.todoPause.test.ts so pause behavior is asserted where it actually lives (engine loop) rather than via hand-fabricated ToolCallResponse generators; remove assertions tied to the deleted branch.

🤖 Prompt for AI agents

Implement Phase 3: consolidate pause handling in the engine so `AgenticLoop` is
the single authoritative pause handler, remove `MessageStreamOrchestrator`'s
non-functional synthetic-event pause branch, and update tests accordingly.

- Ensure `AgenticLoop`/the continuation controller reads and writes paused state
via `TodoStore` (the same side-channel Zed already observes), so a successful
`todo_pause` stops continuation for all consumers and resumes on the next user
turn without relying on CLI React context.
- In `packages/agents/src/core/MessageStreamOrchestrator.ts`, remove/retire the
`todoPauseSeen` branch (in `_evaluatePostTurn`/`_processStreamIteration`) that
depends on `ToolCallResponse` events the real `Turn` never emits in production,
deferring pause authority entirely to `AgenticLoop.buildNextMessage()`.
- Preserve the still-valid in-stream reminder behavior of
`TodoContinuationService` (reminders/complexity escalation), which does operate
on real request/response flow, and must not be removed.
- Rework `packages/agents/src/core/MessageStreamOrchestrator.todoPause.test.ts`
so pause behavior is asserted where it actually lives (the engine loop) rather
than via hand-fabricated `ToolCallResponse` generators; remove any assertions
tied to the deleted branch.

Phase 4: Remove the CLI compensating layers

With the engine authoritative, delete the redundant React continuation/pause stack and the orphaned duplicate service, leaving the CLI as a pure event consumer.

Task 1: Delete the React continuation and pause-gate hooks

Remove the second-loop machinery.

• Remove packages/cli/src/ui/hooks/useTodoContinuation.ts, packages/cli/src/ui/hooks/useTodoPausePreserver.ts, and packages/cli/src/ui/containers/AppContainer/hooks/useTodoContinuationFlow.ts, plus their .spec.ts/.test.ts files.
• Remove the now-orphaned packages/cli/src/services/todo-continuation/todoContinuationService.ts and its spec (zero production importers).

Task 2: Unwire the hook triggers across AppContainer

Clean up the ref/enum plumbing that drove the removed hooks.

• Update packages/cli/src/ui/containers/AppContainer/hooks/useAppBootstrap.ts (registerTodoPause), useInputHandling.ts (clearPause on submit), and useAppInput.ts (useTodoPausePreserver usage) to drop the pause/continuation wiring and the onTodoPause threading through useAgentStream/useAgentStreamOrchestration/useAgentEventStream.
• Update the AppContainer smoke tests (AppContainer.mount.test.tsx, AppContainer.keybindings.test.tsx, AppContainer.render-budget.test.tsx) that vi.mock the removed hooks.
• Confirm TodoProvider/TodoContext still function for passive display; keep only the display subscription, not continuation control.

🤖 Prompt for AI agents

Implement Phase 4: delete the CLI's redundant React continuation/pause stack and
the orphaned duplicate service now that the engine is authoritative, leaving the
CLI as a pure event consumer.

- Remove `packages/cli/src/ui/hooks/useTodoContinuation.ts`,
`packages/cli/src/ui/hooks/useTodoPausePreserver.ts`, and
`packages/cli/src/ui/containers/AppContainer/hooks/useTodoContinuationFlow.ts`,
along with their `.spec.ts`/`.test.ts` files.
- Remove the now-orphaned
`packages/cli/src/services/todo-continuation/todoContinuationService.ts` and its
spec, since it has zero production importers.
- Update `packages/cli/src/ui/containers/AppContainer/hooks/useAppBootstrap.ts`
(`registerTodoPause`), `useInputHandling.ts` (`clearPause` on submit), and
`useAppInput.ts` (`useTodoPausePreserver` usage) to drop all pause/continuation
wiring, including the `onTodoPause` threading through
`useAgentStream`/`useAgentStreamOrchestration`/`useAgentEventStream`.
- Update the AppContainer smoke tests (`AppContainer.mount.test.tsx`,
`AppContainer.keybindings.test.tsx`, `AppContainer.render-budget.test.tsx`) that
mock the removed hooks via `vi.mock`.
- Confirm `TodoProvider`/`TodoContext` still function for passive display only;
keep just the display subscription, not any continuation control logic.

Phase 5: Integration and parity tests

Lock in a single behavioral path for CLI and ACP-style consumers.

Task 1: Engine-level continuation and pause tests

Cover the new engine behavior with real infrastructure.

• Add tests under packages/agents/src/core/agenticLoop/__tests__/ following the existing real-loop/real-scheduler/real-bus, scripted-provider-only pattern (agenticLoop-test-helpers.ts), using the issue-number naming convention: assert continuation fires on pending todos, stops on successful todo_pause, respects the setting, and doesn't double-fire.
• Port the behavioral assertions previously in useTodoContinuation.spec.ts into these engine tests.

Task 2: CLI/ACP parity test

Enforce that both consumers get identical behavior from agent.stream().

• Add an API-layer parity test under packages/agents/src/api/__tests__/ using the dual-path harness (buildCliStyleConfig.ts, cli-turn-parity.early.spec.ts pattern) with @plan:/@requirement: tagging, asserting the public agent.stream() output for an incomplete-todo scenario matches between a CLI-style config and a bare ACP-style config.

🤖 Prompt for AI agents

Implement Phase 5: add integration and parity tests to lock in a single
behavioral path for CLI and ACP-style consumers of the new engine-owned
continuation and pause behavior.

- Add tests under `packages/agents/src/core/agenticLoop/__tests__/`, following
the existing real-loop/real-scheduler/real-bus, scripted-provider-only pattern
(`agenticLoop-test-helpers.ts`), using the issue-number naming convention.
Assert that continuation fires on pending todos, stops on a successful
`todo_pause`, respects the `todo-continuation` setting, and does not
double-fire.
- Port the behavioral assertions previously in `useTodoContinuation.spec.ts`
into these new engine tests.
- Add an API-layer parity test under `packages/agents/src/api/__tests__/` using
the dual-path harness (`buildCliStyleConfig.ts`, `cli-turn-parity.early.spec.ts`
pattern) with `@plan:`/`@requirement:` tagging. Assert that the public
`agent.stream()` output for an incomplete-todo scenario matches between a
CLI-style config and a bare ACP-style config.

Research

The agentic turn loop is engine-owned: AgentImpl.stream() (packages/agents/src/api/agentImpl.ts) delegates to AgenticLoop (packages/agents/src/core/agenticLoop/), which drives AgentClient.sendMessageStream() → MessageStreamOrchestrator.execute() per model turn. AgenticLoop.createSchedulerWithCallbacks() already calls config.getOrCreateScheduler(...) directly on an isolated, non-colliding session key. The subagent path routes through TaskTool → subagentExecution.initInteractiveScheduler(), which the #2653/#2655 fix made receiver-safe (the schedule closure now preserves this).

Two CLI-only compensating layers remain: (1) interactiveToolScheduler.ts registers a subagent scheduler factory (setInteractiveSubagentSchedulerFactory → toolRegistryFactory.getInteractiveSubagentSchedulerFactory() → TaskTool) that duplicates what the now-fixed engine fallback already does; and (2) a React continuation stack (useTodoContinuation.ts, useTodoPausePreserver.ts, useTodoContinuationFlow.ts) that fires a second agent.stream() when todos remain pending and maintains a todoPaused gate. ACP/Zed (zedIntegration.ts) calls agent.stream() with no such layers and thus silently under-performs on incomplete-todo scenarios. An engine-side TodoContinuationService exists (used by client.ts/MessageStreamOrchestrator for in-stream reminders) but is not reachable from AgenticLoop and does not perform proactive re-prompting. A fully orphaned duplicate lives at packages/cli/src/services/todo-continuation/todoContinuationService.ts. Todo state is persisted via TodoStore/todoEvents (packages/tools/src/tools/).

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: consolidate scheduler creation and binding entirely in the
engine, so the CLI no longer needs to supply a correctly-binding factory for
subagent scheduling while its main interactive scheduler remains untouched.

- In `packages/agents/src/core/subagentExecution.ts`, verify
`initInteractiveScheduler()` is the canonical scheduler-construction path, and
ensure the receiver-preserving `schedule` closure is applied uniformly to both
the `schedulerFactory`-provided handle and the `getOrCreateScheduler` fallback.
Extract this binding/closure wrapping into a small shared helper so any handle
passed in from a consumer is normalized to a receiver-safe form inside the
engine, as defense-in-depth against a consumer supplying an unbound `schedule:
scheduler.schedule`.
- In `packages/cli/src/runtime/interactiveToolScheduler.ts`, reduce
`useExternalSchedulerRegistration`/`useExternalSchedulerFactoryCreator` so the
CLI supplies only React display callbacks (output/tool-update/editor callbacks),
letting the engine construct and bind the scheduler. Remove the duplicated
`getOrCreateScheduler`-plus-binding logic in the subagent path. Do not touch
`useScheduler()` (the main session scheduler keyed by `config.getSessionId()`),
since it remains the live path for slash-command tool execution and anchors
React display state.
- Review `packages/core/src/config/toolRegistryFactory.ts`
(`schedulerFactoryProvider`/`getInteractiveSubagentSchedulerFactory`) and
`packages/core/src/config/configBaseCore.ts` (`subagentSchedulerFactory` slot).
Reduce these to pass-through display configuration only, or remove the slot
entirely if the CLI no longer needs to inject anything beyond callbacks.
- Verify remaining consumers of
`getOrCreateScheduler`/`setInteractiveSubagentSchedulerFactory` across
`packages/agents` (`subagentRuntimeSetup.ts`, `task.ts`), `packages/a2a-server`,
and `packages/core` still compile and behave correctly against the simplified
surface.
===============================================================================

Task: 2

Implement Phase 2: move the pending-todo continuation behavior from the CLI
React hook into the engine, so it becomes a single internal loop decision shared
by all consumers (CLI, ACP/Zed, non-interactive CLI) instead of an
externally-fired second `agent.stream()` call.

- Extend `packages/agents/src/core/TodoContinuationService.ts` (or add a focused
controller alongside it) with a post-turn decision capability: read active todos
from `TodoStore` (`packages/tools/src/tools/todo-store.ts`), select the most
relevant todo (`in_progress` before `pending`), respect the `todo-continuation`
ephemeral setting, honor the paused state, and generate the continuation prompt
text (including the YOLO-mode wording variant).
- Preserve the behavioral guarantees previously asserted in
`useTodoContinuation.spec.ts`: trigger only when the turn finished with no
blocking tool calls, track attempt counts, avoid double-firing on rapid
completion, and remain safe against malformed todo data.
- In `packages/agents/src/core/agenticLoop/AgenticLoop.ts`, after a turn
completes with no continuing tool responses, consult the new continuation
controller. If continuation is warranted, build the continuation message and
feed it back into the loop as the next turn instead of terminating.
- Keep the existing successful-`todo_pause` stop guard as the authoritative gate
that prevents continuation when the model deliberately paused.
- Ensure continuation turns flow through the normal event stream (no new
`AgentEvent` discriminant), so all consumers render them naturally; optionally
emit a `notice` event for observability/debugging.
===============================================================================

Task: 3

Implement Phase 3: consolidate pause handling in the engine so `AgenticLoop` is
the single authoritative pause handler, remove `MessageStreamOrchestrator`'s
non-functional synthetic-event pause branch, and update tests accordingly.

- Ensure `AgenticLoop`/the continuation controller reads and writes paused state
via `TodoStore` (the same side-channel Zed already observes), so a successful
`todo_pause` stops continuation for all consumers and resumes on the next user
turn without relying on CLI React context.
- In `packages/agents/src/core/MessageStreamOrchestrator.ts`, remove/retire the
`todoPauseSeen` branch (in `_evaluatePostTurn`/`_processStreamIteration`) that
depends on `ToolCallResponse` events the real `Turn` never emits in production,
deferring pause authority entirely to `AgenticLoop.buildNextMessage()`.
- Preserve the still-valid in-stream reminder behavior of
`TodoContinuationService` (reminders/complexity escalation), which does operate
on real request/response flow, and must not be removed.
- Rework `packages/agents/src/core/MessageStreamOrchestrator.todoPause.test.ts`
so pause behavior is asserted where it actually lives (the engine loop) rather
than via hand-fabricated `ToolCallResponse` generators; remove any assertions
tied to the deleted branch.
===============================================================================

Task: 4

Implement Phase 4: delete the CLI's redundant React continuation/pause stack and
the orphaned duplicate service now that the engine is authoritative, leaving the
CLI as a pure event consumer.

- Remove `packages/cli/src/ui/hooks/useTodoContinuation.ts`,
`packages/cli/src/ui/hooks/useTodoPausePreserver.ts`, and
`packages/cli/src/ui/containers/AppContainer/hooks/useTodoContinuationFlow.ts`,
along with their `.spec.ts`/`.test.ts` files.
- Remove the now-orphaned
`packages/cli/src/services/todo-continuation/todoContinuationService.ts` and its
spec, since it has zero production importers.
- Update `packages/cli/src/ui/containers/AppContainer/hooks/useAppBootstrap.ts`
(`registerTodoPause`), `useInputHandling.ts` (`clearPause` on submit), and
`useAppInput.ts` (`useTodoPausePreserver` usage) to drop all pause/continuation
wiring, including the `onTodoPause` threading through
`useAgentStream`/`useAgentStreamOrchestration`/`useAgentEventStream`.
- Update the AppContainer smoke tests (`AppContainer.mount.test.tsx`,
`AppContainer.keybindings.test.tsx`, `AppContainer.render-budget.test.tsx`) that
mock the removed hooks via `vi.mock`.
- Confirm `TodoProvider`/`TodoContext` still function for passive display only;
keep just the display subscription, not any continuation control logic.
===============================================================================

Task: 5

Implement Phase 5: add integration and parity tests to lock in a single
behavioral path for CLI and ACP-style consumers of the new engine-owned
continuation and pause behavior.

- Add tests under `packages/agents/src/core/agenticLoop/__tests__/`, following
the existing real-loop/real-scheduler/real-bus, scripted-provider-only pattern
(`agenticLoop-test-helpers.ts`), using the issue-number naming convention.
Assert that continuation fires on pending todos, stops on a successful
`todo_pause`, respects the `todo-continuation` setting, and does not
double-fire.
- Port the behavioral assertions previously in `useTodoContinuation.spec.ts`
into these new engine tests.
- Add an API-layer parity test under `packages/agents/src/api/__tests__/` using
the dual-path harness (`buildCliStyleConfig.ts`, `cli-turn-parity.early.spec.ts`
pattern) with `@plan:`/`@requirement:` tagging. Assert that the public
`agent.stream()` output for an incomplete-todo scenario matches between a
CLI-style config and a bare ACP-style config.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!