A2A Servers

An A2A Server exposes workflows from your projects over the Agent2Agent (A2A) protocol so that external A2A clients - another agent or your own code - can discover them through an agent card and send them tasks. Where an MCP Server publishes your tools to an assistant, an A2A Server publishes an agent that other agents can delegate work to. Each exposed workflow becomes one skill of that agent.

Each server gives you a secret-key URL. The agent card lives at:

GET  https://<your-host>/api/automation/a2a/<secretKey>/.well-known/agent-card.json

and the JSON-RPC endpoint is:

POST https://<your-host>/api/automation/a2a/<secretKey>

The endpoint supports the message/send, message/stream, tasks/get and tasks/cancel methods.

Create an A2A server

1. In the Automation workspace, open A2A Servers from the sidebar.
2. Click New A2A Server (or Create A2A Server while the list is empty).
3. Give it a name and a description - both appear on the agent card that external clients read.
4. Choose whether to Require authentication (see Authentication below). It is on by default.

A new server is enabled straight away; switch it off or on with the toggle on its card. The server belongs to the environment selected in the application sidebar when you create it (Development, Staging, or Production), and keeps it - so you can expose a different agent per environment. The list shows the servers of the selected environment.

Creating, editing and deleting servers, and changing their skills, requires the ADMIN role. The secret key - and so the URLs on the server's Connect tab - is visible to tenant admins only.

A server exposes nothing until you add a project to it.

Expose workflows as skills

1. Expand the server's card, open the Workflow Skills tab and click Add Workflows.
2. On the Basic step, select a project and a published version, then click Next.
3. On the Workflows step, switch on the workflows to expose. Only workflows with a New Workflow Call trigger (workflow/v1/newWorkflowCall) are listed - that trigger is what lets the workflow be invoked as a skill. A workflow whose trigger input schema requires any input other than message is left out too: an A2A call only fills message, with the text of the caller's message, so the other inputs could never be supplied.
4. For each switched-on workflow, pick its Connections and fill in its Inputs, then click Add. Every required connection must be set; a connection must belong to the server's environment.

Adding a project does not touch your own deployments. The server deploys the selected workflows itself, in a deployment of its own in the server's environment that does not appear in the Deployments list. Each selected workflow becomes a skill on the agent card; the skill id is the workflow id.

A server can hold one version of a project: adding a project the server already has is rejected, whichever version you pick. To expose more of its workflows, edit the workflows of the project already on the server; to switch to another version, choose Change Project Version from the project's menu.

Each project on the Workflow Skills tab expands to list its exposed workflows. From the project's menu:

• Edit Workflows changes the selection, and the connections and inputs of every exposed workflow.
• Change Project Version moves the server's deployment of the project to another published version.
• Delete removes the project and its skills from the server.

Each workflow row has a Configure button, a toggle and a menu:

• Configure gives the skill a Skill Name and a Skill Description. Left blank, they fall back to the workflow's own label and description.
• The toggle switches the skill off without removing it. A disabled workflow is left out of the agent card and cannot be run; switch it back on to expose it again.
• Edit changes the connections and inputs of that workflow only; Remove takes the workflow off the server. Removing the last workflow of a project removes the project.

Tags and filters

Tag servers with the Tags control on each card. The sidebar filters the list by Projects - the projects exposed by any server in the selected environment - and by Tags; the active filter is shown above the list.

How a task runs

When a client sends message/send:

• The skill is picked from metadata.skillId on the request params, or on the message. A server with exactly one skill uses it when no skillId is given; a server with several skills rejects a message without a skillId, and an unknown skillId, with an invalid-params error listing the valid ids.
• The text parts of the message are joined and passed to the workflow's trigger as its message input. A message without text is rejected. Continuing an existing task with a new message is not supported.
• ByteChef starts the workflow and waits up to 300 seconds for it to finish. A finished run returns its response output, or the run's outputs, as a completed task; a failed run returns a failed task. A run that is still going returns a working task to poll with tasks/get.
• The reply text is the output itself when it is text, and the value when the output holds a single text value - such as the message of a Response to Workflow Call step. Any other output is sent as JSON.
• A run that pauses on an approval step returns an input-required task, with the approval form link when ByteChef's public URL is configured. Once the decision is made, poll tasks/get for the result.

The task id identifies the workflow run, so tasks/get works for any task of the server, not only recent ones. tasks/cancel does not stop a run: it answers that the task cannot be canceled.

The agent card

The server's Connect tab shows the agent card URL and the JSON-RPC endpoint, each with a copy button, and whether requests need an API key.

The card carries the server's name and description, protocol version 0.3.0, the JSON-RPC transport, text input and output, and one entry per skill. Its url is built from ByteChef's public URL when one is configured, and from the request URL otherwise.

Authentication

The secret key in the URL identifies the server and the tenant that owns it. On top of that:

• Require authentication on (default): every request - the agent card included - must present a ByteChef workspace API key as a Bearer token in the Authorization header. The key must be an Automation key whose environment matches the server's environment, and its user must be active. Other requests are rejected with 401.
• Require authentication off: the secret-key URL is sufficient and no API key is needed; an API key that is sent is ignored. Use this only for low-risk agents or short-lived testing.

A disabled server, or an unknown secret key, answers every request with 401.

Call an A2A agent from an AI Agent

The A2A component lets an AI Agent delegate tasks to a remote A2A agent - an A2A Server of this or another ByteChef, or an agent built on another framework.

1. Attach the A2A Agent Tool to the AI Agent's Tools slot.
2. Set Agent URL to the remote agent's address - for a ByteChef A2A Server, the endpoint URL from the server's Connect tab. Pasting the agent card URL also works.
3. When the agent requires authentication, pick an A2A connection - create one with the agent's Bearer Token, for a ByteChef A2A Server with Require authentication on a workspace API key. It is sent as an Authorization: Bearer header on the agent card request and on every message. The connection is optional: leave it out for an agent that accepts unauthenticated requests.

The model sees the tool as sendTaskToRemoteAgent with a generic description. Give each A2A Agent Tool its own Tool Name and Tool Description - for example askJavaReleaseExpert - so the model knows what the remote agent is for and can tell several remote agents apart. The tool reads the agent card from <Agent URL>/.well-known/agent-card.json, sends the task as an A2A message to the Agent URL, and returns the remote agent's text reply.

Deleting

• Deleting an A2A server removes its projects, their skills and the deployments the server created.
• Deleting a project from a server removes its skills and that project's deployment.
• Deleting a workflow removes the skill that exposed it.