feat(eve): plan subagents as background tasks

[ruiconti]

This is the contract for running subagents as durable background tasks after the agent-messaging stack lands. It changes no runtime behavior.

Today a subagent call leaves the model step as a private runtimeAction. eve starts the child, then keeps the parent turn open until every child in the batch finishes. Local children can forward input and authorization through that active turn; remote children can only report completion or failure.

That boundary works for synchronous delegation. It does not work for background work: the parent cannot move on while the child runs, progress has no shared local/remote path, and non-terminal communication depends on the original turn still being alive.

Proposed flow

With experimental.tasks, each subagent call creates a durable task. The original tool call receives one task receipt, closing that call. Progress, input requests, authorization, completion, failure, and cancellation then move over the task boundary without keeping the parent turn open.

parent model
    |
    v
parent harness ---- creates/indexes ----> task run
    |                                      | owns lifecycle state
    +---- resolves ---------------------> agent handle
    |                                      | owns child address
    +---- dispatches --------------------> child executor
                                           |
                                           +---- updates task run

parent returns to task through task_peek / task_await / notifications

The ownership split is the main design decision. The task run is the single writer for lifecycle transitions. The parent session stores only the taskId -> taskRunId index. Agent handles remain the source of child identity and routing. Credentials stay in private bindings and never enter model context or history.

The dedicated task run comes from the failure exposed by #1190: callback routes and child executors need to update task state, but neither owns the current threaded session snapshot. A separate durable run gives those writers a stable boundary and serializes competing updates.

Delivery shape

The rollout is additive. Flag plumbing, task storage, gated controls, and delegated execution land inert first. A later stage moves the six child flows onto the task wire and lets the flag select the new mode. Local/remote normalization and flag removal come last.

This plan assumes the agent-messaging stack #1328-#1331 as its addressing layer. Tasks compose with agent handles; they do not introduce another child-session identity or credential store.

The first implementation is subagents only. Authored tools, built-ins, connections, skills, dynamic workflows, and the public defineTool API stay unchanged. MCP Tasks provides lifecycle vocabulary and control semantics, not an MCP endpoint.

Review focus

• Sequencing: the design and delivery plan currently disagree on whether agent messaging is already the baseline. They should both describe tasks as phase 2.
• Creation: define the task shape before child acknowledgement, including local metadata and dispatch-start failure.
• Wake policy: decide when terminal and input_required updates wake a parked parent instead of waiting for an explicit task control.
• Busy semantics: decide whether task_send queues behind a running child or returns AGENT_BUSY.
• Trust and retention: narrow which fields an executor may update, then define how long terminal tasks remain addressable.

Part of #1084.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
eve-docs	Ready	Preview	Jul 31, 2026 9:32pm
eve-docs-4759	Ready	Preview, v0	Jul 31, 2026 9:32pm

[ruiconti]

Let's defer tool async communication to after a2a communication stack lands i.e., phase 2.