MCP vs A2A vs ACP: How AI Agents Actually Talk to Each Other

Your AI agent has a blind spot (Sponsored)

As AI agents take on decision-making, they need awareness of real-world conditions.

A weather delay can reroute deliveries. Lightning can pause field operations. Road conditions can affect autonomous vehicles. These signals shape decisions, yet most AI systems can’t observe them.

But context is only as valuable as the data behind it. Enterprise applications need trusted, real-time weather intelligence—not just generic forecasts. Signals like lightning activity, road conditions, hail risk, and weather impacts often matter more than temperature alone.

Xweather’s MCP-ready weather API gives AI agents access to trusted weather intelligence and the real-world context behind weather-driven decisions. Learn how it works in this technical guide.

---

This week’s system design refresher:

• MCP vs A2A vs ACP: How AI Agents Actually Talk to Each Other

• 8 Frontier Open Models I’m Most Excited About

• LLM vs RAG vs Agent evals

• How Distributed Tracing Works at the High Level?

• The Life of a Redis Query

---

MCP vs A2A vs ACP: How AI Agents Actually Talk to Each Other

Agents are capable on their own. Combined with tools and other agents, their capabilities compound. But how should they communicate?

1. MCP: agent to tool communication.
   The host app receives the user request, its embedded MCP client formats and routes it to the right MCP server, the server executes the tool call and returns a structured response. The agent uses the result to continue reasoning.

2. A2A: agent to agent communication.
   An agent that can't complete a task alone discovers a capable peer via its Agent Card (published at a well-known URL), delegates the task, and receives a structured result back. If the second agent needs more input mid-task, it pauses in the input-required state and loops back to the first.

3. ACP: agent to agent communication over REST (merged into A2A).
   ACP took a REST-first approach. Peers were discovered through an Agent Manifest, called directly over HTTP, and responded to sync for low-latency tasks or via async SSE stream.

In production, MCP and A2A are complementary. MCP handles tool access, A2A handles agent communication.

Are you running MCP and A2A together in your agent stack?

---

Introducing Attio: the agentic CRM. (Sponsored)

Attio, the agentic CRM, makes it incredibly easy for anyone to run workflows for any GTM play they need.

Describe what you want, and Attio builds it. I just built a workflow that runs every morning, surfaces the deals that need my attention today, like anything with a stage change or a new signal in the last 24 hours.

Hundreds of thousands of automations already run on Attio every day. Ready to try now?

---

LLM vs RAG vs Agent evals

LLMs, RAG pipelines, and agents are different systems, but the recipe for evaluating them is the same: pick a task, collect eval data, develop a grader.

The diagram below breaks it down across four popular AI systems.

1. LLMs: Input is a prompt, output is text. Tasks focus on what a raw model can do on its own: safety, code, instruction-following. Grader is often LLM-as-judge on the final answer.

2. RAG: Adds a retriever before the LLM. So you grade two things: retrieval (right docs?) and generation (faithful answer?).

3. Coding Agents: The LLM gets tools and a loop. Tasks become end-to-end like bug fixing and long-horizon planning. Grading is mostly code-based: run unit tests on the final patch.

4. Multi-Agent Systems: Multiple agents coordinating through an orchestrator. Tasks shift to coordination and role adherence. Grading blends code tests, LLM-as-judge, and human review.

Every new component in the pipeline is a new place for things to go wrong, and a new thing your evals need to catch.

Over to you: What's your go-to evaluation metric for multi-agent systems?

---

8 Frontier Open Models I’m Most Excited About

• Inkling (Thinking Machines): released this week, now the strongest American open model. Text, image, and audio input.

• Nemotron 3 Ultra (NVIDIA): a solid choice for long-running agents. The Mamba hybrid keeps long-context inference cheap.

• GLM-5.2 (Z.ai): currently the best open model for coding.

• Kimi K2.6 (Moonshot): strong on long agent tasks. Holds up over hundreds of tool calls.

• DeepSeek-V4 Pro: a very cheap way to get frontier-level quality over an API.

• Qwen3.6-35B (Alibaba): the best model to run on your own machine. A single 24 GB GPU is enough.

• Gemma 4 31B (Google): the best choice for on-device multimodal. Takes image and audio input on a gaming GPU.

• MiniMax M3: the only open model with native video input.

Over to you: Which open model are you most excited about?

---

How Distributed Tracing Works at the High Level?

1. Services generate telemetry data (traces, logs, metrics) as they handle requests.

2. The OpenTelemetry Collector receives this data from all services in a unified format.

3. The collector splits the data into three streams: traces, logs, and metrics.

4. Each stream is sent to a Receive & Process unit that prepares it for storage and analysis.

5. Processed data is stored in a Log Database for querying and long-term access.

6. Data from the database is visualized through a Visualization dashboard for monitoring and debugging.

Over to you: What else will you add to better understand distributed tracing?

---

The Life of a Redis Query

Redis is an in-memory database, which means all data lives in RAM for speed. However, if the server crashes or restarts, data could be lost.

To solve this problem, Redis provides two persistence mechanisms to write data to disk:

1. AOF (Append-Only File)

   When a client sends a command, Redis first executes it in memory (RAM). After that, Redis logs the command by appending it to an AOF file on disk. This ensures every operation can be replayed later to rebuild the dataset. Since the command is executed first and logged afterward, writes are non-blocking. The recovery process uses the event log to replay the recorded commands.

2. RDB (Redis Database)

   Instead of writing every command, Redis can periodically take snapshots of the entire dataset.

   The main thread forks a subprocess (bgsave) that shares all the in-memory data of the main thread. The bgsave subprocess reads the data from the main thread and writes it to the RDB file.

   Redis uses copy-on-write. When the main thread modifies data, a copy of the data is created, and the process works on that so that writes don’t get blocked. The snapshot is then written as an RDB file on disk, allowing Redis to quickly reload the snapshot into memory when needed.

3. Mixed Approach

   In production, Redis often uses both AOF and RDB. RDB provides fast reloads with compact snapshots. AOF guarantees durability by recording every operation since the last snapshot.

Over to you: Have you used Redis in your project?