Follow agent work after the connection drops

Start a nonblocking turn using the paired request and response example. Continue only when result.kind is task; save result.id and keep using the same endpoint and authenticated owner. The following bodies use illustrative task-10 from that example. Substitute the actual returned ID.

POST this request with Accept: text/event-stream and the same audience-bound Bearer token:

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tasks/resubscribe",
  "params": { "id": "task-10" }
}

The stream first reports the task’s current state, then follows subsequent changes. It does not reconstruct missing token history. An already terminal task can be reported and the stream closed immediately. The later method name is SubscribeToTask. Every task frame uses the requested method’s state vocabulary: tasks/resubscribe retains lowercase states; SubscribeToTask uses TASK_STATE_*, consistently with GetTask. This applies to the initial task and each subsequent update.

Choose a stream or a callback

An existing task can be followed with tasks/resubscribe using its ID and the caller’s authenticated identity. Reattachment returns the current state and follows subsequent changes; it is not a replay of every token emitted while disconnected.

For push delivery, first obtain an owned task ID and a publicly reachable HTTPS webhook. This request body follows the application’s push-notification probe:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tasks/pushNotificationConfig/set",
  "params": {
    "taskId": "task-10",
    "url": "https://integration.example.com/agent-updates",
    "authentication": {
      "scheme": "Bearer",
      "credentials": "callback-secret"
    }
  }
}

Send it to the agent endpoint with its audience-bound token. Store the returned configuration ID to inspect or remove this callback later. Secrets are not echoed in configuration responses.

Read a callback as a status update

A registered callback observes later task transitions; registering after completion does not replay an earlier transition. This representative body follows the current push payload builder. Its timestamp and identifiers are illustrative:

{
  "statusUpdate": {
    "taskId": "task-10",
    "contextId": "conversation-10",
    "status": { "state": "completed", "timestamp": "2026-09-12T09:00:05.000Z" },
    "final": true
  }
}

This HTTP callback body is a status event, not a JSON-RPC result or the generated answer. The dispatcher currently uses canonical lowercase task states for push delivery. Authenticate the configured callback credential, then read the task through the agent endpoint to reconcile its current status. A successful nonblocking turn stores its reply as task output, exposed as a text artifact on the completed task. An authorized task lookup or task subscription returns that artifact; the status-only callback does not carry the reply. Cancellation and approval pauses do not publish a successful result. Do not apply the request-dialect state projection to this payload by assumption.

Treat callback delivery as an external request

The outbound target guard checks the callback address; delivery rechecks its destination rather than trusting only the original registration. Literal private addresses and prohibited host shapes are refused, and redirects are not followed. This path does not pin DNS resolution to the connection, so deployment egress controls must cover hostnames that resolve into private networks. Use a receiver that authenticates the configured credential and handles repeated delivery safely.

Delivery records and retry processing make failures inspectable. A receiver outage does not turn a callback into proof that the underlying task failed. Inspect the task separately when reconciling progress.