[Question] What's the idea behind ROLE_UNSPECIFIED ? and how should we use it ?

[edenreich]

I’m trying to wrap my head around the roles defined in the current A2A protocol:

ROLE_AGENT
ROLE_USER
ROLE_UNSPECIFIED

From the docs, this is how I understand it so far:

ROLE_AGENT is used when an A2A server sends a response back to an A2A client
ROLE_USER is used when an A2A client sends a message to an A2A server

That leaves ROLE_UNSPECIFIED.

What’s the idea behind it, and how is it supposed to be used? I couldn’t find any explanation for it in the docs.

I’m also trying to map these roles internally when the A2A server delegates work to an OpenAI-compatible agent that processes the request in natural language. In that case, how would you recommend mapping A2A roles to the roles we’re used to in other APIs?

For example:

ROLE_AGENT → assistant
ROLE_USER → user
ROLE_UNSPECIFIED → ?
ROLE_TOOL or ROLE_SKILL (doesn't exists? those are implementation details? how can I represent a skill result in the conversation history?)

I understand that the A2A protocol doesn’t require an LLM to exist on the A2A server at all. That said, from my own testing it feels very practical - and fairly common - to have one there.

How are others approaching this in practice? Curious to hear your thoughts.

[mikeas1]

ROLE_UNSPECIFIED is more of an artifact of the protobuf-based definition than an actual role. In protobuf, enums are transmitted as integer values over the wire. When the enum field isn't set, this means it gets a default value of 0. It's common practice to define the 0 value for an enum to be 'unspecified', meaning the value was not specified, not that the role is unspecified.

This general protobuf advice comes from a forward-compatibility viewpoint: imagine we introduce a new field that uses this enum in the future. An older client that's unaware of the field sends a message to a server that uses the newer version. Since the client didn't specify that field, it comes out as the zero value, which the server reads as UNSPECIFIED. The server now can behave differently knowing the field was not specified. If you set the zero value for an enum to a "real" value, say ROLE_USER, it would not be clear if the client intended that value or didn't specify one.

I’m also trying to map these roles internally when the A2A server delegates work to an OpenAI-compatible agent that processes the request in natural language

The reason it's limited to just user and agent is the nature of how A2A works. At present, there are only two parties in an A2A interaction: the caller, which gets ROLE_USER, and the callee, which gets ROLE_AGENT. And the only time there's any ambiguity as to the originator of a message is in the history field of Task. This is unlike LLM APIs, which generally accept a list of messages that interleave "assistant" and "user" roles.

Our viewpoint has been that how the agent generates messages (using an LLM, for example), or performs work (calling a tool, calling another agent, etc), are implementation details of the agent and not concerns of the caller. A2A agents are very black-boxed compared to, say, Agent Client Protocol (ACP) agents, which expose their entire inner workings. A2A takes a more hands-off approach, which means agents are not required to implement it, but allows that level of introspection and visibility via extensions.

So, specifically, I'd expect that an agent emitting tool call details would set role = ROLE_AGENT (since the agent is the one emitting the message), but have a DataPart containing the details of the tool call.

e.g.

{
  "messageId": "my-tool-call-message",
  "role": "agent",
  "parts": [{
    "type": "data",
    "data": {
      "type": "tool-call",
      "tool-name": "web-search",
      "params": {"query": "Agent communication protocols"}
    }
  }]
}

how can I represent a skill result in the conversation history

Interesting question, but I wonder if your clients care about this or not? What would they be expected to do with that information? I can see it for your metrics/logging purposes, but there are ways to solve that other than putting it in the data structures returned to a client. I'd be interested to hear if you've got a use case around this -- we're certainly open to extending the spec to add missing information.