Native A2A (Agent2Agent) Protocol Support in ChatGPT and Codex

ChatGPT Feature requests
,
1

Summary

I would like to propose first-class A2A (Agent2Agent) protocol client support across OpenAI’s user-facing products, including ChatGPT (Web and Desktop), Codex (App, CLI, and IDE extensions), and other applicable clients.

Today, users can register and interact with external MCP servers directly through supported OpenAI clients. I believe a similar native integration experience should be available for independent agents implementing the A2A Protocol v1.0.

The goal is not to introduce another agent development SDK or an MCP-to-A2A bridge, but to allow OpenAI products to act as fully capable A2A clients, with protocol-compliant discovery, authentication, communication, task management, and capability negotiation.

References:

Proposed Functionality

1. Native Agent Registration and Discovery

Allow users to connect external agents by providing an Agent Card URL, including the standard /.well-known/agent-card.json endpoint or another explicitly configured Agent Card location.

The client should:

  • Parse Agent Cards and discover available Agent Skills, capabilities, supported input/output modes, and security requirements.

  • Support authenticated discovery using GetExtendedAgentCard when advertised.

  • Negotiate compatible transport bindings through supportedInterfaces.

  • Handle A2A protocol version negotiation, including the A2A-Version service parameter.

  • Support signed Agent Cards and JWS signature verification when applicable.

  • Respect Agent Card caching and updates.

2. Authentication and Authorization

Provide native support for the authentication mechanisms defined by the A2A specification, according to the requirements declared by each agent.

This should include:

  • OAuth 2.0, including Authorization Code with PKCE, Client Credentials, and Device Authorization flows where applicable.

  • OpenID Connect discovery.

  • HTTP authentication, including Bearer tokens.

  • API Key authentication.

  • Mutual TLS for environments where client certificates are required.

The client should securely manage credentials, respect declared security requirements and scopes, and support credential renewal and revocation.

Importantly, it should distinguish connection-level authentication from in-task authorization, including handling TASK_STATE_AUTH_REQUIRED and securely facilitating additional user authorization without exposing credentials through ordinary agent messages.

3. Native A2A Communication and Task Management

Implement the protocol’s core interaction model, including:

  • SendMessage and SendStreamingMessage.

  • GetTask, ListTasks, and CancelTask.

  • SubscribeToTask when streaming is supported.

  • Support for both direct Message responses and stateful Task responses.

  • Multi-turn interactions using contextId, taskId, and referenceTaskIds.

  • Blocking and non-blocking execution using the defined returnImmediately configuration.

  • Correct handling of terminal, interrupted, and active task states.

Users should be able to delegate work to external agents, provide additional input when requested, inspect progress, cancel eligible tasks, and retrieve results without losing the remote agent’s execution context.

4. Streaming and Long-Running Operations

Support capability-dependent asynchronous communication through:

  • Server-Sent Events for supported HTTP-based streaming bindings.

  • Task polling through GetTask.

  • Resubscription to ongoing tasks.

  • Task status and artifact update events.

  • Push notifications and their configuration lifecycle when supported by the agent and the client infrastructure.

Long-running tasks should not depend on keeping the original chat response or network stream open.

Where feasible, users should be able to resume monitoring remote tasks after navigating away from a conversation or reopening the client.

5. Multimodal Messages and Artifacts

Support the A2A Message, Part, and Artifact models, including:

  • Text content.

  • Structured data.

  • File references and inline file content.

  • MIME-type negotiation through declared input/output modes.

  • Multiple artifacts per task.

  • Incremental artifact updates, including append and final-chunk semantics.

The client should preserve the distinction between conversational messages and task-generated artifacts, and present supported outputs through the existing product experience.

6. Protocol Bindings and Extensions

Support the standard A2A protocol bindings with capability and version negotiation.

As an initial implementation, JSON-RPC and/or HTTP+JSON could provide native HTTP-based interoperability, with gRPC support considered as an additional capability.

The client should also recognize declared A2A extensions, negotiate support using the defined extension mechanisms, and correctly handle required extensions that it does not support.

Unsupported capabilities should be surfaced clearly rather than silently assumed or emulated.

7. Product Integration, Permissions, and Security

A native integration should ideally provide:

  • A dedicated interface for registering, configuring, enabling, disabling, and removing external A2A agents.

  • Agent selection and task delegation from ordinary conversations.

  • Clear consent before sharing conversation context, attachments, or sensitive data with external agents.

  • User confirmation for sensitive or consequential operations where appropriate.

  • Per-agent permissions and appropriate organization or workspace controls.

  • Secure handling of remote files, URLs, credentials, and untrusted agent responses.

  • A consistent experience across supported OpenAI clients.

Why A2A Alongside MCP?

MCP and A2A serve complementary purposes.

MCP provides a standardized way to expose tools and external capabilities, while A2A provides a standardized model for communication and task delegation between autonomous agents.

An external agent may manage its own execution lifecycle, request additional input or authorization, produce artifacts, and continue working asynchronously.

Exposing that agent exclusively through an MCP wrapper can introduce an additional integration layer and may require manually mapping A2A-specific lifecycle semantics onto tool calls.

Native A2A client support would allow users to integrate specialized, independently developed agents without requiring those agents to adopt a particular OpenAI SDK, framework, language, or infrastructure.

Requested Outcome

I would like OpenAI to consider adding native A2A 1.0 client support alongside its existing MCP integration capabilities.

A phased implementation would be reasonable, beginning with Agent Card discovery, secure authentication, core message/task operations, and at least one standard protocol binding, followed by advanced features such as push notifications, additional transports, and expanded extension support.

Are there any plans to support native A2A clients in ChatGPT or Codex? Is there an existing feature request, roadmap item, or early-access initiative for this capability?

1 Like