Protocol direction: rewind/time-travel, tool displayName, and the reserved transport flags (resumable / pushNotifications)

[contextablemark]

@ferponse surfaced five design questions with some protocol-level implications in a single burst.
Rather than answer them one PR at a time, capturing them here together so that the necessary
discussion can be centralized. The maintainers of other SDKs and integrations are therefore
invited to weigh in before anything lands in core.

PR-side execution and merge sequencing for the related pull requests is tracked separately in #2162.

These five all ask the same meta-question — lift into core, or leave integration-local?
A couple of them (notably #2106, and the framing of #2091) reach for
A2A shapes as the ready-made answer, so it's worth being
explicit about a design principle up front:

AG-UI is meant to be a general-purpose, framework-agnostic protocol. It should
interoperate cleanly with A2A, and we're happy to borrow good ideas from it — but we're
disinclined to pull A2A-specific shapes into the core surface, because that would couple
every AG-UI consumer to one framework's model, even if changes are optional. The bar for a
core change here is "is this the right general-purpose shape?"; A2A-specific concerns
generally belong at the integration
boundary.

With that lens, grouping these together so the protocol moves in one coherent direction rather
than piecemeal.

---

1. Conversation rewind / edit / regenerate — "time travel" · #2154

Today every integration re-infers rewind intent by diffing incoming messages against its own
persisted history. Proposal: standardize it at the protocol level.

• Option 1: an optional rewind/fork anchor on RunAgentInput
  (rewindBeforeMessageId / forkFromMessageId), mirroring the existing resume /
  ResumeEntry precedent already in the protocol.
• Option 2: a documented divergence convention (message id as the anchor) — treat as
  accompanying spec docs, not a new field.
• Option 3: a dedicated lifecycle event — defer as a follow-up.

Question for the thread: does Option 1 fit the RunAgentInput contract cleanly, and does
any integration have a reason it can't honor a fork anchor? Are there alternative approaches that
would work better across frameworks?

2. Server-decided display name for tool calls · #2146

Frontends currently duplicate (and re-localize) the toolName → human-label mapping. Proposal:
let the server attach a display name.

• Option A: a small optional displayName on ToolCallStart / ToolCallResult.
• Option B: a CUSTOM-event convention instead of a first-class field.
• Option C: out of scope — keep it a frontend concern.

Question: is a first-class optional field worth the surface-area cost vs. the CUSTOM
convention?

3. Reserved pushNotifications transport flag · #2106

The reserved flag is currently hollow (advertised, no contract), so it needs a contract or it
should stop being advertised. The proposal models it directly on A2A PushNotificationConfig —
which is exactly the coupling the principle above cautions against.

• Option A (lean): design an AG-UI-native push contract — a minimal, transport-agnostic
  webhook/delivery shape expressed in AG-UI's own vocabulary. A2A's design is a useful
  reference for what fields a push contract needs; we can stay interoperable with it and lift
  the genuinely general parts without adopting the A2A type as our own.
• Option B: keep the flag reserved until there's a concrete, non-A2A-specific consumer
  driving the exact shape.
• Option C: adopt A2A PushNotificationConfig directly — least work, but couples a core
  capability to A2A's model; this is the one I'd want strong justification for.

Of the changes proposed, this is the one I'm most concerned about - if we're going to start
adding support for push notifications, it needs to be carefully considered and done in a platform-
and transport-agnostic fashion. Even the use of the term "webhook" is already indicating a bias.

4. Reserved resumable transport flag · #2105

Also hollow: the flag exists with no backing wire mechanism. Proposal: a monotonic per-run
sequence number on BaseEvent + Last-Event-ID for SSE resumption.

• Decision needed: where does the sequence live (on BaseEvent? the transport envelope?)
  and how is resumption requested (Last-Event-ID header? query param?).
• Worth noting this one is already framework-agnostic — a sequence number + Last-Event-ID is
  standard SSE with no A2A coupling — so it's the more straightforward of the two reserved
  flags.

#3 and #4 are one decision: define what the reserved transport flags actually mean on the
wire. Both should land as AG-UI-native contracts; once the wire shapes are blessed, they
convert from design to accept-and-spec.

5. Bidirectional shared state across an A2A boundary · #2091

More a question than a proposal: the blessed architecture when the state-owning agent sits
behind an A2A boundary (editable-form use case).

• Lean (answerable now): the orchestrator owns and relays shared state; sub-agents are
  stateless across the boundary. This is the general answer regardless of what sits on the other
  side (A2A or anything else). Any A2A ↔ STATE_DELTA DataPart mapping is an integration-level
  enhancement — explicitly not a core change — which keeps core from taking a dependency on
  A2A's data model.
• Action: capture as a short docs page rather than a spec change.

---

The cross-cutting call

1. Design principle: AG-UI stays general-purpose and framework-agnostic. We interoperate
   with A2A at the integration boundary and borrow good ideas, but A2A-specific shapes don't get
   pulled into core. Does anyone see a case here where that principle should bend?
2. How much new optional surface are we willing to add to core (RunAgentInput rewind
   anchor, tool displayName) — and is each the right general shape, not just the shape one
   integration needs today?
3. Which of these get blessed now → @ferponse implements, vs deferred, vs declined?

Once there's rough consensus here, I'll convert the accepted items into scoped issues and note
which ones @ferponse is picking up.