All posts
· 14 min read · Damiën Semler

A2A 1.1 turns a task into a shared workspace. The sender field is still an open PR.

The 1.1 branch has merged an ordered task timeline, a live channel and client-written artifacts. Attribution is still under review, and of 1,722 endpoints with a usable probe result in our registry, only 221 reject anonymous callers.

Between August and October, A2A's 1.1 development branch gained an ordered task timeline, a live bidirectional channel and artifacts written by the client. Taken together, these changes turn a task from one client's exchange with an agent into a server-ordered log that several parties can read and write.

The field that would record who wrote each entry has not been merged. PR #2310, which adds Message.sender, is open as of November 4. It proposes that the binding layer should populate the value from the authenticated connection, and that clients may supply it directly. In Agenstry's registry, 1,009 endpoints answered an anonymous probe and declare no authentication on their card. For those deployments, as described, there is no connection identity for a server to copy.

What is merged, and what is proposed

None of this is released. v1.0.1 remains the latest core version, the pending 1.0.2 contains one corrected gRPC URL example, and the roadmap gives v1.1 no date. All of the following could still change.

Merged into dev-1.1, per the branch comparison:

  • generation (#1810, August 12). A per-task counter that the server increments by exactly one on every state change, so a client can detect gaps and resume.
  • Timeline and artifact ordering (#2129, September 22). A coherent task history in place of separate, loosely related lists.
  • SendLiveMessage (#2153, October 19). One operation for a long-lived duplex session, a brief exchange, or attaching to a task purely to observe it.
  • Client-written artifacts (#2322, October 20). Clients can send artifacts to an existing task without a message, gated by a new user_artifacts capability. Artifact.role keeps client and agent output distinguishable.

Still open:

  • Message.sender (#2310). An optional string, promoted from a shared-task extension. The current diff also gives artifacts creator and contributors fields.
  • Cross-agent parent and child tasks (#2410). Describes Artifact.sender and ParentTask.sender, so sub-agents can contribute directly to a shared parent task through a hub that needs no model in the loop. The two pull requests do not yet agree on how artifacts are attributed.
  • Semantics refinements (#2411). Among other things, servers would set an artifact's role by its origin and reject client writes that claim to be the agent.

Multiple senders are not strictly new. Issue #2309, which prompted the field, notes that nothing in the protocol stops two users sending to the same non-terminal task if they know its ID, and that the agent cannot tell them apart. What 1.1 changes is how much of the design now assumes this kind of sharing.

One task on the 1.1 branch (illustrative) GENERATION ENTRY ROLE SENDER 2 Message: translate this document user not on branch 3 Artifact written by a client user not on branch 4 Status: working agent n/a 5 Message: use formal register user not on branch 6 Artifact: translated document agent not on branch Order and user/agent role are merged. Whether entries 2 and 5 came from one person is not recorded.

Order is not attribution

The generation counter gives every change on a task a total order, and it is well specified: the branch's specification tells clients how to detect a gap and what to conclude if a server does not implement the field. role separates user from agent. Neither identifies a party. Two people, or two calling agents, both appear as user.

The open proposal fills that gap with a plain optional string. Under #2310 as written, an agent applying per-sender logic should document whether it accepts client-supplied values. The difficulty for anyone reading the timeline later is that the two routes produce the same value: a string copied from a verified token and a string the caller typed look identical on the wire. Unless the final design adds a way to tell them apart, the distinction lives only in each server's documentation.

The same paragraph of the proposal says that any client holding a taskId or contextId for an active task may send messages to it. That describes today's behaviour, but as new specification text it sits awkwardly beside the requirement to scope access by the authenticated caller. A reader could take possession of an ID as sufficient. The final wording should say which rule governs.

The parent and child proposal raises the stakes, because it moves that string across agents. A sub-agent emits an update targeting the parent task, naming itself as sender, and the hub stamps a generation and rebroadcasts it to the others. Recipients then depend on whatever check the hub performed. The proposal lets a parent reject an invalid write, but the text we read does not define what makes a write invalid.

Observation makes read scoping load-bearing

SendLiveMessage can attach to a task without sending anything, and it can resume from a generation value. The specification already requires scoping by the authenticated caller for all operations that access tasks, and the operation returns TaskNotFoundError when a task does not exist or is not accessible. So the requirement exists. What the new operation adds is another binding-specific path on which to get it wrong, in a long-lived stream where access may be revoked after it opens. We described this class of failure in August, when official SDKs were still adding cross-tenant checks to task stores.

What the deployed field can support

We queried the registry on November 4 for agents whose cards our validator classes as current or legacy, then split the 1,722 endpoints whose probe outcome tells us something about authentication. Our probe sends a heartbeat SendMessage with no credentials. It records "answered" when an endpoint returns valid JSON-RPC, which includes a protocol error, so an answer does not prove the endpoint would accept work. "Declares auth" and "declares streaming" are card claims that we did not test further.

Endpoint behaviour Declares streaming No streaming Total
Rejects anonymous callers (401/403) 66 155 221
Answered; card declares auth 53 439 492
Answered; card declares no auth 59 950 1,009
Total 178 1,544 1,722

SendLiveMessage requires the streaming capability. On that basis, 66 endpoints, or 3.8%, both reject anonymous callers and declare streaming. They are the clearest candidates for a live channel with identity taken from the connection. Adding the 53 that declare auth but answered anyway, perhaps because authentication applies per method, gives 119 at most. The largest single group is the 950 that answered anonymously, declare no auth and do not stream. A public, stateless agent is a legitimate design, and sender attribution is not a problem it needs to solve. It does mean that shared-task semantics will be adopted by a small part of today's field first.

The migration to 1.0 has also reached parity among working endpoints. Of those that answered, 664 declare 0.3.x and 662 declare 1.0.x. Of those rejecting anonymous callers, 75 declare 0.3.x and 85 declare 1.0.x. Published cards lag behind: of the 3,686 valid cards with a version, 58.3% declare 0.3.x and 33.8% declare 1.0.x, against 65.5% and 25.5% of 1,910 cards on September 1. The denominator nearly doubled as coverage grew, so that comparison is only indicative. Support for the old line has not ended either: the Java SDK shipped v0.3.4 and v1.5.0.Final on the same day, November 3. The live channel is described as fully additive, so for that feature the practical question for a client is what each server declares rather than which version is newest.

What to test before relying on it

A card cannot show any of the following. As we argued about MCP tools hidden from a listing, what is advertised and what is enforced need separate evidence. For anyone implementing the branch, or evaluating an agent that claims to:

  1. Sender substitution. Authenticate as A and send sender: B. Record whether the server rejects it, overwrites it or stores it.
  2. Second principal. Create a task as A. As B, try to subscribe, send a message and write an artifact, on every advertised binding. The outcomes should match your stated sharing policy and be the same across bindings.
  3. Revocation during a stream. Remove A's access while a live stream is open, then resume from a lastSeenGeneration. Check that no further events arrive.
  4. Role by origin. Send a client artifact claiming ROLE_AGENT, and send any client artifact to an agent that does not declare user_artifacts.
  5. Forged parent writes. Once the parent and child design settles, write to a parent task from an agent that was never delegated to.
  6. Provenance in logs. Confirm that your own records show whether a sender was verified or merely asserted, even if the wire format does not.

What we're watching

The most consequential open point is whether #2310 ends with a way to distinguish verified from client-supplied senders, and whether the authorization guidance becomes normative. After that, whether the parent and child proposal defines what a valid cross-task write is. We will also rerun the table above after a 1.1 release. The 66 is the number that shows whether shared tasks are reaching deployed, authenticated agents.

Sources

Cite this post

@misc{agenstry-a2a-sender-attribution-2026,
  author       = {Semler, Damiën},
  title        = {A2A 1.1 turns a task into a shared workspace. The sender field is still an open PR.},
  howpublished = {Agenstry research blog},
  year         = {2026},
  month        = {nov},
  url          = {https://agenstry.com/blog/a2a-1-1-shared-task-sender-attribution}
}
← Back to blog Agenstry