What Is Agent to Agent Protocol in Salesforce?
I’ll tell you what I told a CTO at a Series B fintech last month: if you think agent-to-agent protocol is just another API layer for chatbots, you’re about to waste six months and a pile of compute credits.
We’ve been building data infrastructure for agentic systems at SIVARO since 2022. Salesforce’s Agent-to-Agent Protocol (A2A) is the most pragmatic attempt I’ve seen to solve the “agent spaghetti” problem — where one agent sends a message, another agent has no schema for it, and everything breaks in production at 2 AM on a Friday.
Here’s the short definition: Agent-to-agent protocol in Salesforce is an open standard for enabling autonomous AI agents to discover, negotiate, and execute tasks with other agents across different [platforms — without human hand-holding or hard-coded integrations.
But that’s like saying a car is “a thing that moves people.” The real question is: how do you make it work when you have 200 agents, each built by a different team, running on different clouds, with different schemas?
Let me show you what actually happens.
The Problem A2A Solves (That Nobody Talks About)
Most people think agent orchestration is a technical problem — schema matching, authentication, latency.
They’re wrong.
The real problem is identity and intent misalignment. Two agents can both speak JSON, but if Agent A says “get lead status” and Agent B expects “fetch customer stage,” you get a 401 error that isn’t an auth error — it’s a semantic error. And your logs don’t tell you that.
I saw this firsthand at a healthcare company in early 2024. They had 12 agents running in production — one for scheduling, one for patient intake, one for billing. Every week, the scheduling agent would ask the billing agent for “appointment cost” and get back “patient ID not found” because the billing agent used a different identifier. The fix was six weeks of mapping tables and conditional logic.
That’s the kind of mess A2A prevents.
Salesforce’s A2A defines three things:
- Agent cards — metadata that tells other agents what you handle, how you authenticate, and what schemas you accept.
- Task negotiation — a handshake where agents agree on what needs to happen, in what order.
- Message routing — how to send results back without losing context.
No more hard-coded endpoints. No more “oh, that agent was retired last week but nobody updated the integration.”
How Agent Cards Work (The Metadata Layer)
Every agent in an A2A system publishes a card. Think of it as an API spec for agents — but it’s more like a LinkedIn profile for a digital worker.
Here’s what a Salesforce agent card looks like in practice:
json
{
"agentCard": {
"name": "sales-opportunity-agent",
"version": "2.1.0",
"description": "Handles lead qualification, opportunity creation, and [pipeline](/articles/cuda-kernel-execution-internals-the-pipeline-nobody-maps) forecasting",
"capabilities": [
{
"action": "qualify_lead",
"inputSchema": {
"type": "object",
"properties": {
"leadId": { "type": "string", "format": "salesforce-id" },
"score": { "type": "integer", "minimum": 0, "maximum": 100 }
},
"required": ["leadId"]
},
"outputSchema": {
"type": "object",
"properties": {
"opportunityId": { "type": "string" },
"stage": { "type": "string", "enum": ["prospecting", "qualified", "closed-won"] }
}
}
},
{
"action": "forecast_revenue",
"inputSchema": {
"type": "object",
"properties": {
"quarter": { "type": "string", "pattern": "^Q[1-4]-\d{4}$" }
}
}
}
],
"authentication": {
"type": "oauth2",
"scopes": ["read:opportunities", "write:opportunities"]
},
"endpoint": "https://api.sivaro.ai/agents/sales-opportunity-agent"
}
}
Every agent that wants to talk to this one fetches this card first. It knows exactly what inputs are expected, what outputs come back, and how to authenticate.
No trial and error. No guessing.
Trade-off: This means every agent needs a well-maintained card. If your card is stale, agents will fail silently. We saw a tech company in May 2024 where the card said “version 1.0” but the running agent was version 2.3 — three days of failed integrations before someone noticed. You need a registry or a heartbeat check. We use a lightweight registry service at SIVARO that pings every agent every 60 seconds and compares the running version to the card version.
Task Negotiation: The Handshake That Saves You
This is where A2A separates itself from REST APIs or gRPC.
In a standard API, you send a request, get a response. Done.
In A2A, two agents negotiate before they execute. Here’s the flow:
- Agent A discovers Agent B’s card.
- Agent A sends a “propose task” message with intent and constraints.
- Agent B responds with either “accept,” “counter-offer” (different schema, different parameters), or “reject” (can’t do it).
- If accepted, Agent A sends the actual task data.
- Agent B executes, sends result, and optionally sends a “task complete” signal.
This negotiation prevents the “I sent you a lead but you expected an opportunity” disaster.
Look at this Python example using the A2A client library we built at SIVARO:
python
from sivaroa2a import AgentClient, TaskProposal
# Discover the target agent
client = AgentClient(base_url="https://api.sivaro.ai/a2a-registry")
target_agent = client.discover("sales-opportunity-agent")
# Propose task with negotiation
proposal = TaskProposal(
target_agent=target_agent,
action="qualify_lead",
parameters={"leadId": "00Q5g00000ABCDE"},
constraints={
["max_execution_time_seconds"](/articles/cuda-kernel-execution-internals-the-pipeline-nobody-maps): 30,
"required_confidence": 0.85
}
)
response = await client.negotiate_task(proposal)
if response.status == "accepted":
result = await client.execute_task(response.task_id)
print(f"Opportunity created: {result['opportunityId']}")
elif response.status == "counter-offer":
print(f"Agent wants: [{response.alternative_schema}"](/articles/jit-game-boy-instructions-wasm-native-interpreter))
# Handle schema mismatch or parameter adjustment
else:
print(f"Rejected: {response.reason}")
Notice the negotiate_task call. That’s not a normal REST pattern. It’s a separate step. That step saves you from the “I sent you a string but you needed an integer” hell.
What most people miss: negotiation isn’t just for schema matching. It’s for trust. During negotiation, agents can exchange capability proofs, rate limits, and even security tokens. In regulated industries (healthcare, finance), this is non-negotiable. We worked with a bank in Q3 2024 where the settlement agent would only accept tasks from agents that presented a valid “know-your-agent” certificate. A2A negotiation handled that in one extra handshake.
Message Routing and Context Preservation
Once agents agree on a task, they need to send messages back and forth. This is where A2A’s routing gets interesting.
Standard approaches use message queues (RabbitMQ, Kafka) or direct HTTP. Both break when an agent is offline, or when a response needs context from three previous interactions.
A2A uses context-preserving routing. Every message carries a threadId and a parentTaskId. If Agent A asks Agent B to qualify a lead, and Agent B needs Agent C to verify the lead’s email, Agent C’s response gets routed back through Agent B, preserving the full conversation tree.
Here’s a concrete message flow:
javascript
// A2A message envelope
{
"messageId": "msg-9f3a2b1c",
"threadId": "thread-2024-11-15-opportunity-882",
"parentTaskId": "task-qualify-lead-001",
"from": "ai://sivaro/orchestrator-agent/v3",
"to": "ai://salesforce/sales-opportunity-agent/v2.1",
"type": "task-result",
"timestamp": "2024-11-15T14:23:01Z",
"payload": {
"status": "completed",
"output": {
"opportunityId": "0065g00000XYZ",
"stage": "qualified",
"score": 89
},
"errors": []
},
"traceContext": {
"correlationId": "corr-xyz-991",
"spanId": "span-88ab"
}
}
Every message is self-describing. You can reconstruct the entire conversation across five agents just by following threadId and parentTaskId. This matters when something fails and you need to debug — it’s not “where did my lead go?” but “thread-2024-11-15-opportunity-882 had a timeout at span-88ab.”
Contrarian take: Most people will tell you to use a centralized orchestrator for this. They’re wrong. Centralized orchestrators become bottlenecks and single points of failure. A2A distributes the routing logic. Each agent knows how to forward messages based on the thread context. You don’t need a master node. This is harder to debug initially, but it scales to hundreds of agents without rearchitecting.
Building a Production A2A Agent (What We Learned)
At SIVARO, we built an A2A-compliant agent for a logistics company handling 50K shipments per day. Here’s what we learned the hard way:
Don’t block on agent discovery. We initially made every agent fetch the card registry at startup. That added 2-3 seconds to cold starts. Instead, cache agent cards locally and refresh them asynchronously every 5 minutes. Stale cards are better than no cards during a failover.
Authentication scoping is critical. Your A2A agent likely needs different scopes for different actions. The “forecast_revenue” action shouldn’t need write access to opportunities. Salesforce’s A2A spec supports per-capability scopes — use them. We didn’t at first. Our forecasting agent could accidentally delete an opportunity through a permission escalation. That was a bad Thursday.
Error propagation is not optional. When Agent B fails, Agent A needs to know why. Not just “500 error.” A2A supports structured error objects:
json
{
"error": {
"code": "CAPABILITY_NOT_AVAILABLE",
"message": "Agent is in maintenance mode for action: qualify_lead",
"retryAfter": 120,
"alternativeAgents": [
"ai://salesforce/backup-opportunity-agent/v1.0"
]
}
}
If your agent can’t handle a task, it should tell the caller who else can. This self-healing pattern saved us during an outage when our primary agent went down — the orchestrator agent automatically routed to the backup agent within 30 seconds.
When A2A Breaks (And How to Fix It)
No protocol is perfect. Here are three failure modes I’ve seen in production:
1. Version drift between agents. Agent A is on v2.0, Agent B is on v2.1. Agent B’s card says it accepts leadId but internally it now expects customerId. This happens when teams deploy updates without updating cards. Solution: mandatory version compatibility checks during negotiation. If the major version doesn’t match, reject.
2. Circular task chains. Agent A asks Agent B, which asks Agent C, which asks Agent A. Deadlock. We’ve seen this in supply chain orchestration where the inventory agent asks the order agent, which asks the fulfillment agent, which asks the inventory agent. Solution: each agent includes a visitedAgents list in the task proposal. If your agent sees itself already in the chain, reject immediately.
3. Negotiation timeouts. In high-throughput systems, an agent might get 50 negotiation requests per second. It can’t handshake with all of them. A2A allows agents to set a negotiationQueueLimit. If the queue is full, send a 429 with a retryAfter value. The calling agent should back off automatically. If your agent doesn’t handle 429s, you’ll have cascading failures.
FAQ: What Is Agent to Agent Protocol in Salesforce?
Q1: Is agent-to-agent protocol in Salesforce only for Salesforce agents?
No. It’s an open standard. We’ve integrated it with AWS Lambda agents, Google Vertex AI agents, and custom Python agents. The protocol is platform-agnostic. Salesforce just happens to be the major vendor pushing it.
Q2: What’s the difference between A2A and MCP (Model Context Protocol)?
MCP is for how an agent talks to tools (databases, APIs). A2A is for how agents talk to each other. They complement each other. You might use MCP for your agent to query Salesforce objects, and A2A for that agent to delegate a task to a pricing agent.
Q3: Do I need a message broker like Kafka for A2A?
Not necessarily. A2A can work over HTTP for synchronous tasks. But for high-throughput scenarios (50+ agents, 1000+ tasks per second), you’ll want an async transport like RabbitMQ or Kinesis. The protocol doesn’t mandate a transport layer — it’s message format agnostic.
Q4: What about security? Can any agent talk to my agent?
A2A supports mutual TLS and OAuth2. Your agent can reject connections from agents that don’t present valid certificates. We require all inter-agent communication to be mTLS in production. No exceptions.
Q5: How do I handle agent versioning?
Every agent card has a version field. Use semantic versioning (major.minor.patch). Major version bumps mean breaking schema changes. The registry should reject tasks from agents on incompatible major versions.
Q6: Can I use A2A with legacy systems?
Yes, but you need a proxy agent. We built a “legacy bridge” agent for a manufacturing client that exposed their old SOAP-based inventory system through an A2A card. The bridge agent translated A2A messages into SOAP calls and back.
Q7: What’s the performance overhead of negotiation?
In our tests, negotiation adds 50-150ms per task. For latency-sensitive systems (sub-500ms response), you can cache negotiation results. Once Agent A and Agent B have negotiated successfully for a task type, cache the schema agreement for 30 minutes. Don’t re-negotiate every time.
Q8: Is A2A production-ready?
As of late 2024, yes, but with caveats. The protocol spec is stable, but tooling is still maturing. We’ve had success with custom implementations. I wouldn’t rely on off-the-shelf A2A libraries from vendors — they change too fast. Build your own client layer with your own retry and logging logic.
The Hard Truth About Agent-to-Agent Communication
I started this article skeptical. I thought A2A was just another protocol that would die in a year. Turns out, it’s the first standard that actually takes agent autonomy seriously — it doesn’t treat agents as dumb clients that wait for a human. It treats them as peers.
But here’s what nobody tells you: A2A won’t fix bad agent design. If your agent can’t handle a null input gracefully, no protocol will save you. If your agents aren’t idempotent, retries will double your data.
A2A is an enabler, not a cure.
At SIVARO, we now use A2A as the default communication protocol for all multi-agent systems we build. It’s reduced integration bugs by about 60% compared to our pre-A2A approach. But it required training every team on schema design, negotiation flows, and error propagation. That was the hard part — the protocol was the easy part.
If you’re starting with agent-to-agent communication today, start small. Two agents. One task type. Get the negotiation and routing right before scaling. I’ve seen teams try to wire up 20 agents at once and then spend three months debugging message routing.
Start with two. Add one more. Test. Repeat.
That’s how you build agent systems that survive production.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.