Video summary

API vs RAG vs MCP vs A2A Explained in 19 Minutes.

Main summary

Key takeaways

Technology

Tech concepts & “stack” overview (API → RAG → MCP → A2A)

The video argues that demos can look “magical” but fail in production because teams often misunderstand how different layers fit together to provide:

  • Fresh knowledge
  • Capability/tool access
  • Safe coordination across systems

1) API (foundation: predictable interfaces)

  • API = a contract between programs: defined endpoints, request formatting, and response shapes.
  • Traditional software works reliably because developers plan sequences in advance.
  • When LLMs are embedded into apps, the model’s natural-language intent still requires exact API instructions (endpoints, fields/data types, credentials, and error handling).
  • Without structure, this becomes like giving the model “unlabeled control panels.”

Workaround mentioned: brute-force “function/tool descriptions” to the model This works at small scale but becomes brittle as tools grow, schemas change, and failures can be silent.

2) RAG (Retrieval-Augmented Generation): fresh, authorized knowledge

Goal: stop the model from hallucinating changing facts by letting the app retrieve evidence at runtime.

RAG pipeline

  1. Ingest documents (e.g., travel policies, preferences, notes)
  2. Split into chunks and index (keyword, embeddings, or hybrid)
  3. On request:
    • apply permissions
    • retrieve top relevant passages
    • add them to model context
    • generate an answer

RAG is described as “open-book”: the model reasons with retrieved evidence rather than memorizing.

Examples of runtime facts:

  • Passport expiry
  • Points balance
  • Seat preferences

Important caveats

  • Outdated policies can mislead.
  • Malicious documents can “hijack” the model.
  • Personal data exposure must be minimized (least privilege / task-appropriate access).

RAG provides knowledge, not action: it won’t book, approve payments, check live fares, or update calendars.

Where it’s used: document assistants, support bots, enterprise search, and coding products.

3) “Tools” via function calling (action engine)

After RAG supplies context, the agent still needs the ability to act.

Function calling loop

  • The model proposes a structured action request
  • The host validates
  • The tool executes
  • Results return to the model/agent

What the host/app must do

  • Validate requests
  • Enforce what the model is allowed to do
  • Handle setup/integration per service

Key pain point: tool integration doesn’t magically scale—developers must build and maintain many custom connectors, and breakage happens when service schemas change.

4) MCP (Model Context Protocol): standard tool/service connectivity

Goal: replace “custom connector pile” with a shared way for AI apps to discover and call tools.

  • MCP = Model Context Protocol, introduced by Anthropic (Nov 2024) as an open standard.
  • Analogy used: USB-C for AI—common interface, but not automatically safe/compatible with every feature.

MCP standardizes

  • Tool discovery
  • Machine-readable tool schemas
  • Host ↔ tool server communication (using JSON-RPC–style messaging; local stdio vs remote streamable HTTP noted)

Clarifications

  • MCP does not replace API.
    • MCP servers may sit on top of existing REST APIs.
  • MCP servers can expose resources (files/db records/prompts), not just actions.
  • MCP does not itself search/generate—your app still does retrieval, sorting, permission checks, and context assembly.

In Atlas terms: MCP lets Atlas connect to calendar/flight/email servers using consistent discovery and schemas, while the host enforces guardrails (trusted servers, minimal credentials).

5) A2A (Agent-to-Agent): coordination across independent agents/organizations

Goal: solve the “third wall”—coordination when tools/agents belong to different teams or companies.

  • A2A introduced by Google (April 2025), aiming to help independent agents work together even if built on different tech stacks.
  • Provides shared mechanisms for:
    • Discovering what an agent can do
    • Exchanging messages
    • Managing tasks/workflows
    • Returning final results

Key component: “agent cards”

  • Machine-readable “service card” describing:
    • Name and contact location
    • Capabilities
    • Input/output formats
    • Sign-in requirements

Important: Agent cards do not prove safety/trustworthiness.

  • Atlas must obtain the finance agent from a trusted source and authenticate using required sign-in.
  • The receiving agent (e.g., finance) decides what Atlas is allowed to do—no permission is granted merely by seeing the card.

End-to-end “Atlas” flow (single user request → coordinated actions)

The walkthrough frames a scenario where Atlas books a Tokyo trip:

  1. RAG fetches only needed facts (preferences, policy, points balance, passport expiry), not full sensitive documents.

  2. MCP enables tool usage:

    • check calendar conflicts
    • search live fares
    • place a flight hold
    • draft confirmation email The host validates and logs each action.

  3. A2A coordinates with a separate finance agent:

    • Atlas sends itinerary/price for approval when limits are exceeded
    • Finance returns an approval record tied to the exact trip and amounts/expiry
  4. Atlas still does not buy automatically:
    • rechecks price
    • shows final amounts
    • waits for user confirmation
  5. On confirmation:
    • books without duplicate purchase
    • saves receipt, updates calendar, and sends itinerary

Structure highlighted: “one request, four clear roles” (Atlas + tools via MCP + finance approval via A2A).

Main speakers/sources (as stated or implied)

  • The video’s narrator/host (no personal name given in subtitles)
  • Sponsored company: Send (messaging API for SMS, WhatsApp, RCS; integrated with MCP-capable tools)
  • Protocol sources:
    • Anthropic (introduced MCP in Nov 2024)
    • Google (introduced A2A in Apr 2025)
    • Mentioned ecosystem adopting MCP (e.g., Claude Code, Cursor, VS Code)

Original video