A2A Protocol

A2A (Agent-to-Agent) is an open standard for cross-framework agent communication, originally developed by Google and now governed by the Linux Foundation. It gives AI agents a common language for interoperability, regardless of which framework or vendor built them. Lyzr supports A2A natively. You can call agents from LangGraph, CrewAI, Semantic Kernel, or any A2A-compliant platform as sub-agents inside a Lyzr Manager Agent, and you can expose Lyzr agents to external A2A clients. For the full protocol specification and SDKs, see the official A2A documentation.

How A2A relates to MCP

A2A and Model Context Protocol (MCP) serve different layers of an agentic system:

Protocol	Role
MCP	Agent-to-tool communication. Standardizes how an agent connects to APIs, databases, and resources.
A2A	Agent-to-agent communication. Standardizes how agents delegate tasks and exchange results with each other.

They are complementary. An agent can use MCP to call its tools and A2A to coordinate with peer agents.

What A2A enables in Lyzr

Call a LangChain or CrewAI agent as a sub-agent inside a Lyzr Manager Agent
Call a Lyzr agent from an external A2A client or orchestration layer
Build multi-framework pipelines where each agent is built and maintained independently

Agents communicate through A2A without sharing internal memory, tools, or proprietary logic. Each agent exposes only what it is asked to return.

How A2A works

The Lyzr Manager Agent sends a task request to an external agent via its A2A server URL.
The external agent processes the input using its own tools and logic.
The external agent returns a structured response.
Lyzr uses the response directly or passes it to the next step in the orchestration.

The external agent must conform to the A2A protocol specification and be accessible via a public URL.

Connecting an A2A agent in Studio

In a Manager Agent’s Build tab:

Scroll to the Managerial Agent section.
Select + A2A (next to + Agent).
Enter the A2A server URL of the external agent.
If the external agent requires authentication, choose an Authentication method and select or create a credential — see Authentication for A2A connections below.
Write a Managerial Context that tells the manager when to invoke this external agent.

For full setup instructions, see Manager Agent.

Import an A2A agent into the Registry

Alongside calling an external agent from a Manager Agent, you can import an A2A agent into the Agent Registry as a standalone agent. An imported agent behaves like any other agent in your workspace. To import an agent, open the Agent Registry, open the New menu in the top right, and select Import (A2A). Enter the A2A server URL of the external agent. If the agent is protected, choose an Authentication method and a credential (see Authentication for A2A connections) — otherwise leave it as No Auth. Lyzr reads the server and imports the agent into the Registry automatically, where it appears under the External tab.

The Agent Registry New menu with the Import (A2A) option alongside Agent, Voice Agent, SuperFlow, and Proxy Agent.

Once imported, the agent has the same capabilities as an agent you build in Studio:

The imported agent persists in the Registry until you delete it manually.
Full trace visibility and monitoring are available for the imported agent.
You can evaluate any two agents against each other, including an imported agent against a native one.
The agent is available through its API endpoint and as an A2A server out of the box, with no extra setup.

Authentication for A2A connections

Both connection points above — + A2A in a Manager Agent and Import (A2A) in the Registry — show the same Authentication dropdown. Lyzr stores only an auth_type and a credential_id on the agent; the actual secret lives in a separate, reusable credential record and is fetched fresh (and, for OAuth-based types, exchanged for a bearer token) on every discovery-card fetch and every inference call.

Authentication	Use for	Credential fields
No Auth	A publicly reachable A2A server with no authentication	none
API Key	A server that accepts a static key in a request header	`api_key`, `api_key_header` (defaults to `x-api-key`)
Microsoft OAuth	Agents hosted on Azure AI Foundry, authenticated with a Microsoft Entra ID service principal	`tenant_id`, `client_id`, `client_secret`, `azure_scope` (defaults to `https://ai.azure.com/.default`)
Databricks OAuth	Agents hosted on a Databricks App (`*.databricksapps.com`), authenticated with a Databricks service principal	`databricks_host`, `client_id`, `client_secret`, `databricks_scope` (defaults to `all-apis`)

Databricks Apps sit behind an OAuth-only front door. Personal access tokens and interactive user tokens are both rejected with 401 — Databricks OAuth using a service principal’s client-credentials is the only way to reach one non-interactively. See the walkthrough below if that’s what you’re connecting.

Creating a credential

Credentials are created once and reused across any number of A2A connections that share the same backing identity (e.g. one Databricks service principal used by several imported agents in the same workspace):

In the Authentication dropdown, pick the method the target agent needs.
In the Credential field below it, select Create new.
Name the credential and fill in the fields for that method (see the table above).
Save. The credential is now selectable on this connection and on any other A2A connection using the same Authentication method.

You can also create a credential directly via the API:

curl -X POST https://agent-prod.studio.lyzr.ai/v3/providers/credentials \
  -H "x-api-key: $LYZR_API_KEY" \
  -H "Content-Type: application/json" \
  --data-raw '{
    "name": "my-databricks-a2a-credential",
    "provider_id": "databricks_a2a",
    "type": "auth_provider",
    "credentials": {
      "databricks_host": "https://<workspace-id>.cloud.databricks.com",
      "client_id": "<service-principal-application-id>",
      "client_secret": "<service-principal-oauth-secret>"
    },
    "meta_data": {}
  }'

The response’s credential_id is what you pass as credential_id when creating the A2A agent through the API (see the next section).

provider_id values (databricks_a2a, azure_a2a, a2a_api_key) are platform-level definitions, not per-user config — a workspace admin creates each one once per Lyzr deployment. If POST /v3/providers/credentials for databricks_a2a returns a “provider not found”-style error, ask your platform admin to register the provider first.

Connecting a Databricks-hosted A2A agent end-to-end

This section walks through the full path for an A2A agent served from a Databricks App — the case that needs the most setup, because the app’s front door only accepts Databricks OAuth tokens.

1. Confirm the agent needs Databricks OAuth

If the agent’s discovery card URL (<base_url>/.well-known/agent-card.json) is on a Databricks Apps domain (*.databricksapps.com), it needs Databricks OAuth. A quick way to confirm: an unauthenticated request to that URL returns 401, and a Databricks personal access token (PAT) also returns 401 — only a Databricks OAuth bearer token is accepted.

2. Create a service principal

Databricks console — Settings → Identity and access → Service principals → Add service principal → name it (e.g. lyzr-a2a). Databricks CLI — equivalent:

databricks service-principals create --display-name lyzr-a2a -o json

The response’s applicationId is the client ID you’ll use in Lyzr. Keep the numeric id field too — the next step needs it, but it is not the client ID.

3. Generate a client secret

Console — open the service principal → Secrets tab → Generate secret. Copy the secret value immediately; it is shown once. CLI:

databricks service-principal-secrets-proxy create <numeric-service-principal-id> -o json

The response’s secret field is the client secret.

4. Grant the service principal access to the app

A valid OAuth token is not enough on its own — the service principal also needs permission on the specific Databricks App. Without this step you’ll still get 401 even with a correct token. Console — open the app in the Databricks workspace → Permissions → add the service principal with Can Use. CLI:

databricks apps update-permissions <app-name> --json '{
  "access_control_list": [
    {"service_principal_name": "<client-id-from-step-2>", "permission_level": "CAN_USE"}
  ]
}'

This call is additive — it does not remove existing grants on the app.

5. Create the credential in Lyzr

Using the Studio picker (see Creating a credential above) or the API, with:

Field	Value
`databricks_host`	The workspace URL, e.g. `https://dbc-xxxxxxxx-xxxx.cloud.databricks.com` — not the app URL
`client_id`	The service principal’s application ID (step 2)
`client_secret`	The secret generated in step 3
`databricks_scope`	Leave blank — defaults to `all-apis`

6. Connect the agent in Studio

Use either entry point:

Manager Agent — Build tab → Managerial Agent → + A2A → enter the app’s A2A base URL (e.g. https://<app>.aws.databricksapps.com/api) → Authentication: Databricks OAuth → select the credential from step 5.
Agent Registry — New → Import (A2A) → same base URL and Authentication choice.

Or via the API:

curl -X POST https://agent-prod.studio.lyzr.ai/v3/a2a/agents/ \
  -H "x-api-key: $LYZR_API_KEY" \
  -H "Content-Type: application/json" \
  --data-raw '{
    "name": "my-databricks-agent",
    "base_url": "https://<app>.aws.databricksapps.com/api",
    "auth_type": "databricks",
    "credential_id": "<credential_id from step 5>"
  }'

A 200 with an agent_id means Lyzr fetched the discovery card successfully — the connection is live. Verify it end-to-end with a test message:

curl -X POST https://agent-prod.studio.lyzr.ai/v3/a2a/agents/<agent_id>/infer \
  -H "x-api-key: $LYZR_API_KEY" \
  -H "Content-Type: application/json" \
  --data-raw '{"message": "hello"}'

Troubleshooting

Symptom	Cause	Fix
`Failed to fetch discovery card: HTTP 401` with Authentication set to No Auth	Databricks Apps reject unauthenticated requests	Switch Authentication to Databricks OAuth and attach a credential
Same `401` with a Databricks personal access token in an API Key credential	Databricks Apps’ front door does not accept PATs at all, by design	Use Databricks OAuth with a service principal, not a PAT
`Databricks OAuth failed: ... HTTP 401 ... invalid_client`	Wrong `client_id`/`client_secret`, or the secret was rotated/revoked	Re-check the credential’s `client_id`/`client_secret`, or generate a new secret (step 3) and update the credential
Token exchange succeeds but the discovery card fetch still `401`s	Service principal has no permission on the app	Grant Can Use on the app to the service principal (step 4)
`Databricks OAuth failed: ...` mentioning DNS or connection errors	`databricks_host` is the app URL instead of the workspace URL, or is missing the scheme	Use the workspace URL (`https://<id>.cloud.databricks.com`), not the app’s `*.databricksapps.com` URL

Models & LLM Providers

Tools

Data

Protocols

A2A Protocol

How A2A relates to MCP

What A2A enables in Lyzr

How A2A works

Connecting an A2A agent in Studio

Import an A2A agent into the Registry

Authentication for A2A connections

Creating a credential

Connecting a Databricks-hosted A2A agent end-to-end

1. Confirm the agent needs Databricks OAuth

2. Create a service principal

3. Generate a client secret

4. Grant the service principal access to the app

5. Create the credential in Lyzr

6. Connect the agent in Studio

Troubleshooting

Further reading

​How A2A relates to MCP

​What A2A enables in Lyzr

​How A2A works

​Connecting an A2A agent in Studio

​Import an A2A agent into the Registry

​Authentication for A2A connections

​Creating a credential

​Connecting a Databricks-hosted A2A agent end-to-end

​1. Confirm the agent needs Databricks OAuth

​2. Create a service principal

​3. Generate a client secret

​4. Grant the service principal access to the app

​5. Create the credential in Lyzr

​6. Connect the agent in Studio

​Troubleshooting

​Further reading

How A2A relates to MCP

What A2A enables in Lyzr

How A2A works

Connecting an A2A agent in Studio

Import an A2A agent into the Registry

Authentication for A2A connections

Creating a credential

Connecting a Databricks-hosted A2A agent end-to-end

1. Confirm the agent needs Databricks OAuth

2. Create a service principal

3. Generate a client secret

4. Grant the service principal access to the app

5. Create the credential in Lyzr

6. Connect the agent in Studio

Troubleshooting

Further reading