InjectTaskReminder: ambient context injection for running tasks

[kennethsinder]

Problem

A2A models agent-to-agent communication around Message (role-tagged exchange) and Task (long-running work with streaming updates). Both assume the caller wants to add content the peer treats as turn input: a user-role prompt or a task artifact.

There's no first-class shape for ambient context: a short-lived, non-user-authored signal a caller wants a running peer to factor into its next turn, without claiming the user said it. Concrete cases:

• A coordinator tells a delegated worker "the upstream PR you depend on just merged; rebase before retrying" without that string entering the worker's user transcript as a fake user message.
• A monitoring agent nudges a worker mid-task: "your last action exceeded the configured cost budget."
• A workflow agent forwards a host-side file-watcher or CI event to the worker it delegated to.

Host-internal precedent exists: several coding agents inject ambient "system reminder" blocks at turn boundaries, with Claude Code's <system-reminder> pattern the most visible public example. Across an A2A boundary, though, implementors currently pick one of three workarounds:

1. Send a user-role Message with a synthetic "System reminder:" prefix. Pollutes the worker's user transcript and misattributes authorship.
2. Attach a custom artifact to the running task. Artifacts are outputs, not turn-scoped context.
3. Tunnel the payload through metadata on message/send. Works, but every adopter invents a private schema, so nothing interoperates.

Proposal

A dedicated operation targeting a running task, sibling to GetTask / CancelTask / SubscribeToTask (PascalCase across bindings, per v1.0 conventions):

{
  "jsonrpc": "2.0",
  "id": "req-019abf6b-...",
  "method": "InjectTaskReminder",
  "params": {
    "taskId": "task-019abf6b-7d51-7c1d-bb02-...",
    "reminder": {
      "id": "reminder-019abf6b-...",
      "body": "Upstream dependency PR landed; rebase before the next tool call.",
      "dedupeKey": "upstream:pr-1234",
      "ttlTurns": 2,
      "roleHint": "system",
      "source": "coordinator-agent"
    }
  }
}

• body: natural-language text the peer surfaces to its model on the next turn, in whatever role its runtime uses for ambient context (roleHint is advisory).
• dedupeKey: a newer reminder displaces pending ones with the same key, so repeated signals collapse instead of flooding the transcript.
• ttlTurns: reminders age out after N turns instead of accumulating.

Peers advertise support on the agent card (capabilities.reminders), and a reminder-emitted event on the existing SubscribeToTask stream gives callers visibility into when a reminder actually reached a turn.

An alternative shape is extending Message itself (a new role value or member) instead of an operation. I'd argue against it: Message.role is authorship, and reminders deliberately aren't authored by the user or the agent; implementations that switch on role would silently drop them; and the lifecycle fields (TTL, dedupe) don't belong on every message consumer's plate. v1.0's removal of kind discriminators in favor of member-based polymorphism points the same way: a distinct payload with a distinct lifecycle gets its own operation. But it's worth discussing if maintainers prefer extending the message surface. A third path is incubating this as a v1.0 versioned extension before (or instead of) core adoption.

Open questions

1. Core operation (proposed) vs a versioned A2A extension first.
2. Should dedupe/expiry lifecycle notifications ship in v1, or only the emitted event?
3. Should reminders propagate into sub-tasks a peer spawns, or stay task-scoped (simpler v1)?
4. Interaction with push notifications vs the streaming subscription.

There's a working implementation of this shape behind message/send metadata today, so the proposal comes from running code. Happy to turn this into a concrete schema PR or an A2A extension, whichever fits the project's process.

Disclosure: I drafted this with AI assistance and reviewed it before posting; the design and the reference implementation are human-maintained.