Agent-to-agent vs chatbots: a conversation for people, a contract for software

A chatbot is for holding a conversation with a person in a chat channel, such as a website widget or a messaging app, and resolving what it can inside that conversation. Agent-to-agent communication, as defined by the A2A (Agent2Agent) protocol, is for letting one software agent hand a task to another through structured messages, declared skills, authentication and a tracked lifecycle.

A chatbot’s counterpart is a human. An A2A agent’s counterpart is another program. That difference decides how each one is discovered, secured and recorded, even when the same language model sits behind both.

Status as of September 26, 2026. Chatbots have no shared protocol. Each platform defines its own model and APIs; Google’s Dialogflow CX, for example, documents agents built from flows, pages, intents and webhooks. Platforms also come and go: Microsoft stopped servicing support tickets for its Bot Framework SDK on December 31, 2025, archived the .NET repository on January 5, 2026, and points developers to the Microsoft 365 Agents SDK. A2A is a Linux Foundation project at protocol version 1.0; its latest release, v1.0.1, shipped on May 28, 2026.

What chatbots are for

A chatbot turns a person’s messages into actions and replies. Dialogflow CX shows the classic design. An agent contains flows for topics of conversation. Each flow has pages, which the documentation describes as states in a state machine. Intents, trained on example phrases, classify each turn, parameters capture values such as an order number, and webhooks call back-end services. Integrations connect the agent to channels where people chat.

Newer bots use a language model to understand and respond, but the frame is the same. The bot talks to a person, in the person’s language, inside a channel built for people. It has no published contract for other software. Its security assumes a human: a logged-in web session, a verification question, and often bot defenses in front of the widget.

What agent-to-agent is for

A2A assumes both sides are software. A business publishes an Agent Card, usually at /.well-known/agent-card.json, stating its skills, endpoints and required authentication. A client agent sends a message with text and data parts. The business’s agent creates a task that can complete, fail, be refused, or pause for more input (TASK_STATE_INPUT_REQUIRED) or authorization (TASK_STATE_AUTH_REQUIRED). Clients can poll the task, stream updates or receive push notifications, and results come back as artifacts.

The same exchange both ways

Illustrative: a person’s agent tries to cancel a subscription.

Through the chat widget, the agent drives a browser, types, and reads replies meant for a person:

Agent:   I'd like to cancel my subscription.
Bot:     I'm sorry to hear that! Before you go, can I offer you 50% off for 3 months?
Agent:   No thanks, please cancel.
Bot:     Okay. What's the email address on your account?
Agent:   docs-example@example.com
Bot:     Thanks! I've sent a verification code to that email. Please enter it here.

Every turn is prose the agent must interpret. The widget can change its wording or layout at any time, and the business has no idea which company’s agent is typing or whether the account holder authorized it.

Over A2A, the same pause for information is a task state with a machine-readable status. Illustrative response from the business’s agent over the JSON-RPC binding:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "task": {
      "id": "task-31c8",
      "contextId": "ctx-5d02",
      "status": {
        "state": "TASK_STATE_INPUT_REQUIRED",
        "message": {
          "messageId": "c4e1a9b2-7d3f-4b8e-a6c5-1f2e3d4c5b6a",
          "role": "ROLE_AGENT",
          "parts": [
            { "text": "Which account should be canceled? Send the account email as accountEmail." }
          ]
        },
        "timestamp": "2026-09-26T16:20:00.000Z"
      }
    }
  }
}

The client answers with a message carrying the same taskId and a data part. If the business needs proof that the account holder approved the cancellation, the task can move to TASK_STATE_AUTH_REQUIRED instead of relying on a code typed into a chat box.

Side by side

	Chatbot	Agent-to-agent (A2A)
Purpose	Converse with a person and resolve their request in a channel	Let one agent delegate a task to another and track it
Layer	Conversational application on a vendor platform	Open application protocol
Who talks to whom	A person and a business’s bot	A client agent and a remote agent
Transport	Chat widgets and messaging channels through platform integrations	JSON-RPC 2.0, gRPC or HTTP+JSON; streaming and webhook push
Discovery	A widget on a web page or a contact in a messaging app	Agent Card at /.well-known/agent-card.json, registries or direct configuration
Auth	Built for people: web sessions, verification codes, bot defenses	Security schemes declared in the Agent Card; in-task authorization through TASK_STATE_AUTH_REQUIRED
State	A conversation session in the platform	Tasks with a lifecycle; contextId groups related tasks
Governance and status	Vendor platforms with no common standard	Linux Foundation project; version 1.0 (v1.0.1, May 28, 2026)

When to use each

Use a chatbot for people. Customers who want to type rather than call, ask a quick question, or be routed to a human are well served by a good chat experience. The bot’s tone, retention offers and escalation rules are all designed for a human reader.

Use agent-to-agent for callers that are software. When a customer’s agent wants an order status, a refund or a cancellation, a structured task avoids interpreting prose, gives the business a place to authenticate the caller, and leaves both sides with task IDs, states and artifacts they can check later.

Using both

The two channels can share almost everything behind the front. The same AI service agent, policies and back-end integrations can answer the chat widget for people and A2A tasks for agents. What the A2A side adds is the entrance: an Agent Card, caller authentication, and task handling. Emissar’s Front Door is a hosted version of that entrance in front of a business’s existing service agent; its status is Open to design partners.

Some chatbot platforms now reach out over A2A as clients. Microsoft Copilot Studio, for example, documents connecting one of its agents to an external agent over A2A, with no authentication, an API key or OAuth 2.0.

Common misconceptions

“An LLM chatbot is already an agent-to-agent endpoint.” It understands language, but it has no Agent Card, no task lifecycle and no authentication designed for software callers. Another agent can only reach it by pretending to be a person.

“Agents can just use the chat widget.” They can, and some do. The path is fragile: wording and layout change, bot defenses may block the session, and nothing identifies the agent or the person it represents.

“A2A agents are chatbots with an API.” An A2A task can run for days, ask for authorization, send push notifications and return structured artifacts. The protocol also treats each agent as opaque, so the client never sees the other side’s prompts, tools or data model.

“Chatbot platforms share a protocol.” Each platform defines its own model and APIs, which is why A2A exists as a common layer between agents.