Pass deadlines and cancellation down every delegated call

When an agent hands work to another agent or service, pass along how much time is left and forward a cancellation to every call it started, so abandoned work stops all the way down the chain.

Why

Delegation chains keep getting deeper: an orchestrator asks a support agent, which calls a refunds service, which calls a payment processor. If the orchestrator gives up after 30 seconds and nothing downstream knows, the rest of the chain keeps running, spending quota and holding locks, and may complete a refund nobody is waiting for. gRPC solved this for service-to-service calls, and its guidance carries over. With no deadline a client can wait effectively forever; a server that calls another server should honor the deadline set by the original client; and because clocks differ, gRPC passes the deadline on as a timeout with the elapsed time already deducted. Its cancellation guide adds that since servers are often clients of other servers, a cancellation should ideally reach all the work the original call started. MCP's 2026-07-28 specification asks implementations to set timeouts on every request to prevent hung connections and resource exhaustion, and tells a server that receives a cancellation to stop processing and free the resources involved. It also warns that a cancellation may arrive after the work finished, so a cancel is a request, not an undo, and the caller still needs to learn what happened. AX-SYS-24 gives one long job a handle; this principle covers the chain of calls behind it.

Do

Accept a time budget on every delegated call, pass the remaining time downstream, cancel child calls when the parent is cancelled, and report which steps had already completed.

Don't

Let downstream calls run on their own fixed timeouts after the caller has gone, or assume a cancel reversed work that had already finished.

Artifact

{ "jsonrpc": "2.0", "method": "notifications/cancelled",
  "params": { "requestId": "req_refund_77", "reason": "Parent task cancelled by orchestrator" } }

{
  "task": "refund_ord123",
  "status": "cancelled",
  "budget_ms": 27500,
  "completed_before_cancel": ["hold_released"],
  "not_started": ["refund_issued", "customer_emailed"]
}

The refunds service gave the processor call only what remained of its 27.5-second budget, stopped on cancel, and reports that the hold was released but no refund was issued. The notification is the MCP cancel over stdio; over Streamable HTTP, closing the response stream is the cancel.