# When background jobs look finished before they are usable

Agent Optimization Memo · Weekly issue 001 · 2026-11-12

One decision for agents that depend on slow reports, exports or analyses.

**Decision:** Inspect one existing slow job. Keep a working native handoff; otherwise identify its actual continuation or missing evidence before retrying.

## Fit

- Your agent starts a slow tool job and a later step depends on its result.

- The host or connector may return before the final artifact is ready.

## Skip

- The native host already hands off a usable result correctly.

- There is no downstream dependency or the host does not support this task generation.

## The useful change

Claude Code v2.1.319, released November 6, says terminal sessions can background MCP tasks immediately and notify the agent when results arrive. Its permissions.denyInsteadOfPrompting setting denies calls that would wait for permission. These are vendor-documented changes, not our runtime measurements. The CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND setting keeps tasks in the foreground instead, so foreground waiting alone does not show missing support. Check the actual interface and configuration.

Sources: [Claude Code v2.1.319 release](https://github.com/anthropics/claude-code/releases/tag/v2.1.319)

## The decision to make

Open the record of a job you already ran with authorization. Did its dependent step receive the promised report or export, or only a status? If the output is already usable, keep the native workflow. Adding another queue or scheduler would create maintenance without an established benefit.

If the result is absent, classify the observation before changing timeouts or running the job again. A report that was accepted, one that stopped with an error, and one that completed remotely but lost its response call for different next steps. This classification is our practical recommendation; it is not a promise of exactly-once execution.

## Three protocol distinctions worth keeping

In the July 2026 Tasks extension, a completed task can contain a tool error. Read its result rather than accepting the status as proof that the work succeeded. An existing task waiting for input uses tasks/update on that same task. Acknowledged cancellation is cooperative and need not stop work.

A core multi round-trip response is different. Without a task handle, input_required can ask the client to repeat the original method with requested responses. It can also permit immediate continuation when no inputs are requested. Return supplied requestState unchanged and use a new JSON-RPC ID. Do not infer what an opaque state value means.

Check the actual protocol generation. July moved Tasks out of core and replaced the older tasks/result method with tasks/get, alongside tasks/update. Generic MCP compatibility is not enough to choose raw methods. Prefer the host-supported continuation rather than pasting calls from another protocol version.

Sources: [MCP Tasks extension, 2026-07-28](https://tasks.extensions.modelcontextprotocol.io/specification/2026-07-28/tasks), [MCP multi round-trip requests, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr), [MCP 2026-07-28 key changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog)

## Two recovery details that prevent unnecessary restarts

An acknowledged input update can precede the task’s visible state change. Partial input can also leave it waiting. Continue observing that task and track the request keys instead of presenting the same question again or creating another job.

Durable does not mean permanent. A task’s retention limit can change, and an expired record may be purged. Preserve the accepted output in your existing workflow record when it becomes available. If the handle has expired, investigate the provider’s output record; the missing task record alone does not establish that execution failed.

Sources: [MCP Tasks extension, 2026-07-28](https://tasks.extensions.modelcontextprotocol.io/specification/2026-07-28/tasks)

## Use this decision card on one existing job

1. A usable output is present: record the output location and the acceptance check that passed. Keep the working native handoff.

2. A task handle remains valid: use the host-supported observation or continuation for that handle. Keep independent work moving, but hold dependent conclusions until the actual result is checked.

3. A permission denial is explicit: report the denied action. Do not describe it as a slow job or resubmit it to make the blocker disappear.

4. The outcome is uncertain: reconcile with the provider job or output record if available. If the earlier operation may have changed state or incurred a charge, a missing response is not sufficient reason to repeat it.

5. The host or protocol is unknown: name that missing fact. Investigating compatibility is a better next step than installing a new orchestration layer.

Hypothetical example: an export task says completed, but its result reports a tool error and no usable export exists. Record acceptance as fail, not pass. This is an illustration, not an observed customer run.

## A small acceptance record

Write the job reference, observed state, output reference, acceptance check, decision and unresolved fact in the workflow record you already use. Keep identifiers and private logs inside their authorized environment. Do not send them to us.

The record is complete when someone else can see why you chose keep, continue, investigate or stop. A well-written record is evidence of a decision, not evidence that the underlying output is correct. If the output cannot be checked, mark its acceptance unknown.

## What we would watch next

Use the same checks after a host or connector upgrade. An improvement worth keeping would be fewer lost results or duplicate jobs on comparable work, without hiding errors or weakening permissions. We have not measured that improvement here.

The Tasks overview explains the extension’s intended use for long-running work; implementation and retention remain host/server dependent. Treat durable handles as something to verify in your actual integration rather than a universal guarantee.

Sources: [MCP Tasks extension overview](https://modelcontextprotocol.io/extensions/tasks/overview)

## Evidence and limits

- Source-verified editorial analysis, not a reproduced vendor feature or customer experiment.

- No measured speedup, cost saving or reliability gain.

- The decision card does not authorize software changes, new jobs, spending or permission changes.

Source pages checked 2026-11-12. No customer data or new provider job was used.

## Decision record template

```json
{
  "job_reference": "Keep private in your own system",
  "observed_state": "accepted | working | input_required | completed | failed | cancelled | denied | expired_or_not_found | unknown",
  "artifact_reference": null,
  "acceptance_check": null,
  "acceptance_result": "pass | fail | unavailable",
  "decision": "keep | continue | investigate | stop",
  "unresolved_fact": null,
  "tool_result_error": null
}
```