A2A Roadmap

[krrishdholakia]

Starting a discussion for how LiteLLM can support A2A.

How would you expect A2A to work with LiteLLM?

Common Asks:

• Allow adding agents onto LiteLLM
• Allow discovering agents
• Allow discovering agents by skills and capabilities
• Allow executing agents on LiteLLM (?)
• team/key permission management for agents

Relevant docs: https://google-a2a.github.io/A2A/latest/specification

[wagnerjt]

How would you expect A2A to work with LiteLLM?

LiteLLM's proxy would operate purely as a registry/catalog and the SDK would include an A2A client.

The proxy would include the same core functionality the MCP servers was implemented with:

1. CRUD operations to add, edit, and remove A2A servers
   Note: Only need to store the friendly name, description, and server uri
2. Team/Key permission controlled management

Reasoning: It is the A2A clients responsibility (external ones and litellm Sdk) to identify the associated agent it needs to interact with via the agent card which is required per A2A implementation server. This means Litellm proxy only needs to care about this small info and allow clients to discover the agents from some a2a endpoint. Ref agent card struct

From other discovery options, the UI can be a bit friendlier and include the catalog view that shows:

1. The A2A servers associated on the proxy
2. All of the agent cards for each proxy
3. Ways to filter or group by agent capability (fetched from the agent card)
4. Some way to make a call from the proxy to an A2A server
5. Allow two views for users, one strict to the A2A servers for that user and a "public" registry view to be visible to all proxy users (similar to the public model catalog).

Happy to help in this area as well!

[krrishdholakia]

Hey @wagnerjt so the goal would be to onboard this AgentCard onto the proxy, and make it discoverable?

# This will be the public-facing agent card
public_agent_card = AgentCard(
    name='Hello World Agent',
    description='Just a hello world agent',
    url='http://0.0.0.0:9999/',
    version='1.0.0',
    defaultInputModes=['text'],
    defaultOutputModes=['text'],
    capabilities=AgentCapabilities(streaming=True),
    skills=[skill],  # Only the basic skill for the public card
    supportsAuthenticatedExtendedCard=True,
)

[krrishdholakia]

Would you expect the agent url to be exposed or would this call be through litellm?

[wagnerjt]

I don't think litellm even needs to store the agent card, but rather where the agent would only store what is referred to the Service Endpoint: The url where the A2A service can be reached. Once clients know the various locations, the A2A client can look into the agent cards as needed

Refer to how agent discovery works and how litellm proxy could become the catalog in this discovery flow.

My understanding is the underlying A2A framework should cover identifying the agent to use and litellm plays the registry/agent discovery aspects only

[alecswan]

I agree with @wagnerjt proposal.

It is expected that the content of the agent card may change over time. So, litellm would persistently store the url of the agent card and load additional properties from the agent card at runtime in order to faciliate filtering of agents in the UI / API.
Invoking the agent from the litellm UI / API is not required for the first release. It would be a nice-to-have for later releases.

Here are some ideas for the API endpoints which somewhat mirrors the MCP API endpoints in litellm:

1. POST /v1/a2a/agent - accepts the url of the agent card and returns the uuid (could be just a hash of the url) generated for that agent as well as the content of the agent card (to ensure that litellm has permissions to read the card); the API key who initiated the request should be granted permissions to access and modify this agent's record.
2. PUT /v1/a2a/agent/{agent_uuid} - allows updating agent's url as well as permissions of API keys and/or teams who are allowed to read/update this agent record.
3. GET /v1/a2a/agent - iterates over agent records (uuid and url) stored in litellm database to which the invoking API key / team has been granted access; fetches metadata, such as name, description, capabilities, skills, etc. by loading the agent card from the url when the API is invoked; this API will be used from litellm UI to load agent properties needed for filtering / searching agents in the UI. This API call would be made when user visits the a2a tab in litellm UI. Refreshing the UI would make another call to this endpoint to load agent properties and cache them in the session to enable snappy filtering / search UI experience.
4. GET /v1/a2a/agent/{agent_uuid} - if the API key / team has permissions to access this agent's record, returns the entire content of the agent's card