A2A Agents

An A2A agent is a remote agent that your assistant can hand work to over the Agent2Agent (A2A) protocol. You register the agent once in Tool Studio, select it for an assistant, and the Agentic Orchestrator opens a conversation with it when a request calls for it. The remote agent does its own reasoning and uses its own tools; the assistant sends it messages, answers its questions, and explains the result to the user.

This is Moveworks calling another agent. For the reverse direction, where another agent calls Moveworks, use the Conversations API. For the trade-offs between A2A, MCP, and plugins, see Choosing the Right Tool Framework. If your assistant runs on the Agentic Reasoning Engine, or the remote agent does not publish an Agent Card, connect it through a plugin instead; see A2A in the Agentic Reasoning Engine.

How It Works

1. Registration. A Tool Studio admin creates the A2A agent, selects the connector that supplies its base URL and credentials, and fetches its Agent Card. The card is stored with the configuration and tells Moveworks where to send messages. See Connect an A2A Agent.
2. Selection. A builder adds the agent to an assistant in Assistant Builder. An assistant with no A2A agents selected has no A2A tools.
3. Conversation. When a request matches the agent’s description, the Orchestrator starts a conversation with it. Each message is one turn. The remote agent can complete the turn, fail it, or ask for more information. The conversation stays open afterward, so follow-up questions go to the same agent with its memory of the earlier turns intact.
4. Result. Each turn’s result comes back to the Orchestrator as an ordinary tool result. The Orchestrator reads it, decides what to do next, and writes the reply the user sees. The remote agent’s text is never shown to the user unprocessed and is never treated as an instruction.

What the Assistant Sees

Each A2A agent appears to the model as two tools, named after the agent:

Both tools carry the agent’s Description as its capabilities, which is how the model decides whether the agent fits a request. Write the description as you would for an MCP server or plugin: what the agent does, what it does not do, and the kinds of requests it should receive. If the agent is configured with an outbound metadata schema, both tools also take a metadata object that the model fills from the conversation.

Like other tools in the Orchestrator, the model always sees the tool names and fetches the full schema only when it picks one. A2A tools run in the reasoning loop directly; they cannot be scheduled as a step in a plan. The user sees a step that reads “Talking to Agent name” while a turn is in progress.

Conversations are bound to the agent they started with. Renaming an agent does not change its tools or break open conversations, and a conversation cannot be redirected to a different agent.

Conversation States

The Orchestrator tracks each A2A conversation as a side conversation of the user’s session. Its state changes with each turn result:

Only one message can be in progress per conversation. If the assistant tries to send another message while the remote agent is still working on the previous one, that send is rejected with an explicit error and is not queued. The conversation’s memory on the remote side is preserved even when a turn times out: the next message continues the same context as a new task.

Who Can Reach an Agent

Three independent controls decide whether a given user’s request can reach a given agent:

• Assistant selection. Only assistants that list the agent can call it, up to 50 agents per assistant. Selecting an agent narrows what the assistant sees and never adds access.
• Agent enablement. A disabled agent is saved but not offered to any assistant, and any send to it is refused.
• Launch configuration. The agent’s Launch Configuration tab controls which users the remote agent is available to, using the same launch configuration model as plugins.

The Moveworks gateway checks enablement and the launch audience on every send, so changes take effect for new messages without republishing assistants.

Credentials and Data

• The connector decides whose permissions apply. An A2A agent authenticates through an HTTP connector, with the same choices as any other connected system. With per-user authorization, each employee signs in the first time the assistant needs the agent, and the remote agent sees that employee’s identity and permissions. With application credentials, such as OAuth 2.0 Client Credentials, a bearer token, or an API key, the agent sees your organization’s application, not the individual user; pass the requester’s identity through outbound metadata if the agent needs it.
• Transport. Messages go to the endpoint advertised in the stored Agent Card, over HTTPS. Connectors that route through the Moveworks Agent are supported for agents inside your network.
• Results are data. The remote agent’s replies enter the model’s context only as tool results. Text inside a reply cannot change the assistant’s instructions.
• Audit. Every turn produces log entries in the Logs app that record what was sent and what came back. Viewing them requires the elevated Logs permission. See Limitations and Troubleshooting.

Limits

Related

• Connect an A2A Agent: register an agent and add it to an assistant.
• Outbound Metadata: send tenant, requester, or record identifiers with every message.
• Limitations and Troubleshooting: what is not supported, how to read A2A logs, and how to fix common failures.
• Tool Orchestration: how A2A agents share the reasoning loop with plugins, MCP servers, and built-in tools.