External Agents
External agents are built outside watsonx Orchestrate and can be used as collaborators for native agents. watsonx Orchestrate supports multiple provider protocols, including external_chat, the Agent-to-Agent Protocol (A2A), and specialized communication protocols for integrating with watsonx AI Agent Builder agents, watsonx Assistants, and Salesforce Agent Force agents.external_chat and A2A agents can be built on any underlying agent platform such as BeeAI, Langgraph, and CrewAI, where the user hosts the agent themselves, on Code Engine.
Providers
External Chat (Chat Completions API)
Theexternal_chat provider can be used to integrate with any agent that is capable of providing an OpenAI style chat completions endpoint and is the most common form of integration.
The documentation for this API spec can be found on the watsonx-orchestrate-developer-toolkit.
A reference Langgraph external agent can be found here.
Agent to Agent (A2A) Protocol
The Agent to Agent Protocol (A2A) is an open standard designed to enable communication and interoperability between multiple agentic systems. Because the standard evolves rapidly, watsonx Orchestrate specifies the A2A version in the provider field to ensure compatibility when communicating with agents. The currently supported version is 0.3.0. Earlier versions, such as 0.2.1, are deprecated and will be removed in a future release. To ensure continued support, use version 0.3.0 or later when registering A2A-compatible agents. For a sample LangGraph agent compatible with the A2A protocol, see the a2a-samples repository. To register an agent that is compatible with the A2A protocol, setprovider to external_chat/A2A/0.3.0, like the following example:
YAML
corr_id value received in the metadata of the initial request.
Push notifications use Bearer token authentication, where the token is generated from API keys as described in the Getting Started guide.
Callback URL and authentication
The callback URL is included in the request sent to the A2A agent. To send push notifications, you must:
- Use a valid API key to generate a Bearer token for authentication.
- Provide complete task update details in the notification payload, following the A2A protocol’s task object specification. Partial status updates are not sufficient.
WXO supports the A2A protocol only over
JSON-RPC 2.0 on HTTP. Although A2A can use multiple transport protocols, this implementation is limited to JSON-RPC 2.0.Import external agents from a URL
Use the discovery command to retrieve and import an external agent by using a URL that hosts an agent card. This approach removes the need to manually define the full agent configuration when the external agent already exposes its metadata. External agents that follow the A2A protocol typically publish an agent card at a well-known endpoint. The default location is.well-known/agent-card.json. The discovery command uses this endpoint unless a custom endpoint is provided.
After the agent is discovered, the configuration is retrieved and the agent can be exported and saved locally. The exported agent can then be imported and used like other external agents.
Discover an agent by using the default endpoint
BASH
Discover an agent by using a custom endpoint
Use a custom endpoint when the agent card is not located at the default path.BASH
Discover an agent by using a connection for authentication
Some external agents require authentication. Provide a connection to retrieve the agent configuration.BASH
Discover an agent by using a custom name
Override the agent name defined in the agent card.BASH
Command behavior
- Retrieves agent configuration from a URL that hosts an agent card.
- Uses .well-known/agent-card.json as the default endpoint.
- Supports custom endpoints for environments that expose multiple agents or non-standard paths.
- Supports authenticated access through a configured connection.
- Allows overriding the agent name during discovery.
- Enables exporting the discovered agent for local use and later import into an environment.
watsonx AI Agent Builder
You can also integrate with agents built using watsonx.ai’s agent builder platform. For more information, see Registering agents from watsonx.ai. Instead of using the API, complete the following YAML file and import your agent. Provide well-crafted descriptions for your agents. These descriptions are used by supervisor agents to determine how to route user requests. For more information, see Writing descriptions for agents.Salesforce AgentForce
To register an agent that is built within Salesforce Agent Force as an external agent:- Follow the Getting Started Guide for the Agent API. For more information, see the Getting Started Guide.

-
On the Create a token page, the following information applies to all Salesforce agents within the instance:
api_url: Always set tohttps://api.salesforce.com/einstein/ai-agent/v1.auth_config.token: Use theCONSUMER_SECRETprovided in the guide.chat_params:client_id: Use theCONSUMER_KEY.domain_url: Use theDOMAIN_URL.- Optionally, specify a list of display types to pass to Orchestrate as a comma-separated string.
- Provide well-crafted descriptions for your agents. These descriptions are used by supervisor agents to determine how to route user requests. For more information, see Writing descriptions for agents.
-
Lastly, under
chat_paramsyou need to specify youragent_id. This can be found by hovering over one of your agents and either right-clicking and copying the URL, or by manually writing it based on hover text. In the following example, the agent_id is0XxfJ0000001d8zSAA.

LangGraph agent
You can import LangGraph agents directly into watsonx Orchestrate. During the upload process, Orchestrate applies the Agent to Agent protocol behind the scenes to make the agent compatible with the platform. You use the same streamlined experience that you use for Python agents or MCP agents. A2A‑enabled LangGraph agents support lifecycle tasks such as update, delete, and export. For a detailed description of how to import LangGraph agents, see Importing LangGraph agents. Limitations:- Supported for Python implementations only.
- Agents that are run inside the watsonx Orchestrate environment with the required isolation.
- Supports only
messagesin the agent graph between turns, so complex custom state objects get lost between turns.
PYTHON
This capability is supported through the A2A protocol.
Configuring checkpointers
Checkpointers persist agent state so you can resume execution and maintain context. Choose the checkpointer that fits your environment and persistence needs, then add its configuration to the checkpointer section of the agent YAML file.- Memory (development or testing)
- SQLite
- PostgreSQL (production)
- No checkpointer (stateless)
Use in-memory storage to persist state during execution. State resets when the process restarts.Example:
YAML
Notes:
- The
connection_string_keymaps to a credential entry that stores the database connection string. Choose API key as the connection type and enter the connection string as the value. - For SQLite and PostgreSQL, the system manages database connections and schema setup automatically.
- The memory checkpointer requires no credentials or additional configuration.
External watsonx Assistants
To register assistants from watsonx Assistant, you must obtain the following information:service_instance_urlapi_keyassistant_idenvironment_id
Note: The location of the
service_instance_url and api_key varies depending on whether the assistant is imported to IBM Cloud or AWS.- Navigate to the settings on the actions page and open the settings.

- On the farthest right tab, select Upload/Download, and click the Download button.

- Locate your
environment_idandassistant_idin the output JSON.

IBM Cloud
On IBM Cloud, yourservice_instance_url and api_key can be found on the page where you launch your assistant’s tooling UI.

AWS
Provide well-crafted descriptions for your agents. These descriptions are used by supervisor agents to determine how to route user requests. For more information, see Writing descriptions for agents.Additional features of external agents
Providing access to context variables
Context variables enable builders to incorporate user-specific identifiers—such as username, user ID, or tenant ID—from upstream systems into an agent. For a full explanation of how context variables work, including delivery methods, precedence, scope, persistence strategies, and channel limitations, see Context variables. By default, agents invoked during a run do not have access to context. To enable access, set thecontext_access_enabled field to true and provide a list of context_variables to expose to the agent.
Context variables are passed to the agent in the following ways:
- Runs API: Use the context field at the root of the request.
- Chat Completions API: Use the context field at the root of the request.
- Streaming variant: Each SSE event sent to the agent includes the context object.
- For external A2A agents, the context variables defined are accessible in the metadata of the
messageobject.
System and custom variables
Context variables are either system variables or custom variables. System variables use the reservedwxo_ prefix and are populated automatically by the platform on every run. Custom variables are defined and supplied by your application. For details, see Types of context variables.


