> This page is for Tools. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.moveworks.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server. # Connect an A2A Agent > **Agentic Orchestrator only** > > Native A2A support, where Moveworks calls a remote agent through its Agent Card, is available only on the Agentic Orchestrator. The Agentic Orchestrator is in Controlled Availability and comes to your Enterprise Assistant as an upgrade in Q1 2027. Capabilities, limits, and interface labels described here may change before general availability. To request access, contact your Moveworks account team. This page registers one remote agent so that assistants can hold conversations with it. For what an A2A agent is and how the Agentic Orchestrator uses one, read [A2A Agents](/tool-studio/a2a) first. ## Before You Start * Registering agents is a Tool Studio admin task. Adding an agent to an assistant is done by the assistant's builder in Assistant Builder. * The remote agent must publish an **Agent Card** and accept messages over the A2A protocol's JSON-RPC or HTTP+JSON binding. An agent that only offers gRPC, or that publishes no card, cannot be registered. Connect it through a plugin instead; see [A2A in the Agentic Reasoning Engine](/tool-studio/a2a/connect-to-other-ai-agents). * You need the agent's base URL and a way to authenticate to it. The authentication method determines whose permissions apply: per-user authorization uses the employee's identity, and application credentials use the application's. See [Choose Authentication](#choose-authentication). * The base URL must use HTTPS. The exception is a connector that routes through the Moveworks Agent to an agent inside your network, which may use HTTP within the tunnel. > **Use trusted agents only** > > Moveworks does not review or vet remote agents. A remote agent decides what it does with each message, including which of its own tools it runs. Register only agents you control or trust, and use the agent's **Launch Configuration** tab to limit who can reach it while you test. ## Choose Authentication | Access needed | Authentication | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Each employee uses their own permissions | Create an [OAuth 2.0 Authorization Code](/tool-studio/connectors/http-connectors/oauth-20-authorization-code) HTTP connector with **PKCE using SHA256 code challenge**. The first time a user's request needs the agent, the assistant prompts them to sign in within the conversation; later requests use that connection. | | The agent uses application-level access | Create an HTTP connector with application credentials, such as [OAuth 2.0 Client Credentials](/tool-studio/connectors/http-connectors/oauth-20-client-credentials), a [bearer token](/tool-studio/connectors/http-connectors/bearer-token-auth), an [API key](/tool-studio/connectors/http-connectors/api-key-auth), or [basic authentication](/tool-studio/connectors/http-connectors/basic-auth). The credentials identify the application, not the employee. | Authorization Code supports token refresh when the provider issues a valid refresh token. If the refresh token expires or is revoked, the user must sign in again. Application credentials do not send the employee's identity. If the remote agent needs to know who is asking, pass the requester's email or other attributes through [outbound metadata](/tool-studio/a2a/outbound-metadata). Do not treat a caller-supplied email as proof of delegated authorization. For agents inside your network, a connector that routes through the Moveworks Agent is supported. ## Create the Connector Create an [HTTP connector](/tool-studio/connectors/http-connectors) whose base URL is the root the agent serves its card from, using the authentication you chose above. If you already have a connector for the system that hosts the agent, you can reuse it. The connector supplies the base URL for fetching the Agent Card and the authentication for every message. Messages themselves go to the endpoint the fetched card advertises, which may differ from the connector's base URL. ## Register the Agent #### Create the A2A agent In Tool Studio, open **A2A Agents** and create a new agent. #### Name and describe the agent Enter a **Name** and a **Description**. Both are required. The name is how the assistant and the user refer to the agent, so use the name people would use in a request. The description is the only thing the model knows about the agent's capabilities. State what the agent does, what it should not be asked, and the kinds of requests that fit. Keep it under 4,096 characters, which is the longest description the model sees. #### Select the connector Under **Configuration**, select the **Connector** you created. Its base URL appears read-only next to the agent card path. #### Set the agent card path Enter the **Agent card path** where the remote agent serves its card, relative to the connector base URL. Leave it empty to use the protocol default, `/.well-known/agent-card.json`, or enter `/` if the base URL itself returns the card. The path must start with a slash and contain no query string. #### Fetch the agent card Select **Fetch Agent Card**. Moveworks requests the card through the connector, using the administrator's connection for a per-user connector, and shows the returned JSON. Review it: the `url` and interface entries show where messages will be sent, and the capabilities section shows whether the agent supports push notifications or streaming. The card is stored with the configuration when you save; it is not refetched at runtime. If the fetch fails, the status line shows the reason. Common causes are a wrong path, a base URL that is not HTTPS, credentials the agent rejected, a redirect, or a card that is not a valid Agent Card. See [Limitations and Troubleshooting](/tool-studio/a2a/limitations-and-troubleshooting#troubleshooting). #### Configure outbound metadata (optional) If the remote agent needs identifiers with each message, such as a tenant ID or the requester's email, fill in the **Outbound metadata** section. See [Outbound Metadata](/tool-studio/a2a/outbound-metadata). Leave both fields empty to send messages without metadata. #### Set who can reach the agent Open the **Launch Configuration** tab and choose the users the remote agent is available to. This uses the same model as plugin [launch configuration](/platform-management/access-control/end-user-access-control/launch-configuration). While testing, limit the audience to yourself or a small group. #### Enable and publish Set the toggle to **Enabled**, then save and publish the agent. A disabled agent is saved but not offered to any assistant, which is useful for taking an agent out of service without deleting it. Only published agents appear in Assistant Builder. Saving validates the configuration: the connector must exist and have a base URL and a supported authentication type, the path must match the rule above, and any outbound metadata expression and schema must be well formed. Errors appear next to the field. ## Add the Agent to an Assistant Assistants on the Agentic Orchestrator get A2A agents the same way they get MCP servers: a builder selects them in Assistant Builder. 1. In Assistant Builder, open the assistant and go to the apps section. Published A2A agents appear alongside MCP servers and enterprise search systems, labeled **A2A**. 2. Add the agent. An assistant can have up to 50 A2A agents; an empty selection means the assistant has no A2A tools. 3. Save the assistant. See [Create a Productivity Assistant](/ai-assistant/productivity-assistants/create-a-productivity-assistant#create-the-assistant) for the rest of the assistant settings. ## Verify 1. As a user in the agent's launch audience, open the assistant and send a request the agent should handle. With a per-user connector, expect a prompt to sign in the first time; complete it and repeat the request. 2. Confirm the assistant shows a step that reads "Talking to *Agent name*", then explains the agent's reply in its own words. 3. If the agent asked a question, answer it and confirm the follow-up goes to the same agent rather than starting over. 4. Send a request the agent should not handle and confirm the assistant does not call it. 5. In the **Logs** app, confirm a dispatch entry and a result entry for each turn. See [View A2A Logs](/tool-studio/a2a/limitations-and-troubleshooting#view-a2a-logs). ## Change or Retire an Agent * **Rename or redescribe.** Tool names follow the agent's configuration ID, not its display name, so renaming does not break open conversations. A changed description takes effect the next time an assistant loads its tools. * **Change the connector or path.** Fetch the card again and save. Conversations already open continue against the stored card until they end. * **Take out of service.** Set the toggle to **Disabled** and save. New messages to the agent are refused immediately; assistants that list it keep their configuration so you can re-enable it later. * **Remove from an assistant.** Edit the assistant in Assistant Builder and remove the agent. The change applies to new sessions of that assistant.