What is Google's A2A protocol?

A2A (Agent-to-Agent) is Google's open protocol for AI agent interoperability. Each agent publishes an Agent Card — a JSON file at /.well-known/agent.json — describing its capabilities, skills, and input/output schemas. Agents communicate via JSON-RPC 2.0 over HTTP, using A2A for task delegation, streaming responses, and status callbacks. It's built for distributed, web-native multi-agent systems.

What is ACP and how does acpx fit in?

ACP (Agent Client Protocol) is a structured protocol for AI coding agents — Codex, Claude Code, Pi, and OpenClaw — to communicate over the command line without PTY scraping. acpx is the CLI client: it opens persistent sessions, queues prompts, handles cooperative cancellation, and surfaces structured output (thinking, tool calls, diffs) instead of raw ANSI terminal output. 1,372 GitHub stars and growing.

How is A2A different from ACP?

Different scope. A2A is about agent discovery and web-based inter-agent communication — how a travel booking agent finds and delegates to a flight search agent over HTTP. ACP is about orchestrating coding agents over the CLI — how an AI orchestrator tells Claude Code or Codex what to work on, tracks progress, and queues follow-up tasks. A2A is HTTP-native; ACP is terminal-native.

What is StockScout v4 and how do its agents communicate?

StockScout v4 is a live multi-agent trading desk: four analysts (fundamentals, technical, sentiment, macro) each get real market data, then a bull and bear researcher debate the thesis over multiple rounds, then a trader-risk manager-portfolio manager chain makes the final decision. The agents communicate via Python function calls and typed dataclasses — no formal protocol. It works, but every agent is tightly coupled to the same codebase.

When should you use a formal protocol vs internal orchestration?

Use internal orchestration (function calls, queues, dataclasses) when all your agents live in the same codebase and you control the full stack. Use A2A when you need agents from different vendors or services to discover and call each other over the web. Use ACP/acpx when you're orchestrating coding agents from an AI orchestrator and want structured output instead of PTY scraping.

Is StockScout v4 open source?

The architecture and concepts are open. The live instance runs at stockscout.thinkcreateai.com. StockScout v4 uses Claude Sonnet 4.5 for debate synthesis and trading decisions, with real-time data from ThinkCreate Intel (live defense stocks, military flight counts, GDELT geopolitical events), yfinance, and FRED macro data.

Agent-to-Agent Protocols: Google A2A vs ACP vs Building Your Own

By Prahlad Menon Published 2026-03-21 6 min read

We just shipped StockScout v4 — a multi-agent AI trading desk that runs a full analyst-debate-decision pipeline on any ticker.

Four specialists do the analysis: a fundamentals analyst, a technical analyst, a sentiment analyst reading news and geopolitical signals, and a macro analyst pulling live VIX, Fed rate, and GDELT data. Then a bull and bear researcher argue the trade thesis over multiple rounds. Then a trader, risk manager, and portfolio manager chain makes the final call.

It works. The debates are genuinely surprising — analysts disagree, the bull and bear researchers push back on each other’s evidence, and the final decision reflects that tension.

But there’s a thing worth noting about how these agents actually talk to each other.

How Multi-Agent Systems Communicate Today

Inside SS4, the agents communicate via Python function calls and typed dataclasses. The fundamentals analyst returns an AnalystReport. The debate engine returns a DebateSynthesis with rounds: List[DebateRound]. The trading desk takes a synthesis dict and returns a TradeDecision.

It’s clean. It works. And it’s completely locked to a single codebase.

If you wanted to swap in a different fundamentals analyst — say a specialist agent from a different vendor — you’d have to match our exact interface. If you wanted to discover what capabilities SS4 offers without reading the source code, there’s no standard way to do it. If a third-party risk engine wanted to call the SS4 trading desk as a service, there’s no protocol for that.

This is the problem that agent communication protocols are trying to solve.

Google A2A: Agent Discovery Over HTTP

Google’s Agent-to-Agent (A2A) protocol was released in April 2025 and is already the front-runner for web-based inter-agent communication.

The core mechanic is the Agent Card — a JSON file published at /.well-known/agent.json that describes what the agent does, what inputs it accepts, what it can output, and how to reach it:

{
  "name": "StockScout Trading Desk",
  "description": "Multi-agent AI trading analysis — fundamentals, technicals, sentiment, macro, debate, decision",
  "url": "https://stockscout.thinkcreateai.com/a2a",
  "version": "4.0.0",
  "skills": [
    {
      "id": "analyze_ticker",
      "name": "Analyze Ticker",
      "description": "Full pipeline analysis — intel, 4 analysts, bull/bear debate, trading decision",
      "inputModes": ["text"],
      "outputModes": ["text", "data"]
    }
  ]
}

Agents communicate via JSON-RPC 2.0. You send a tasks/send request, the remote agent runs its pipeline, and returns a structured response — or streams progress events if it supports SSE.

The key value is interoperability. An orchestrator agent that knows A2A can discover and delegate to any compliant agent without needing to know implementation details. A travel agent can find and use a flight search agent. A research agent can delegate to a code execution agent. The Agent Card is the contract.

We built A2A compliance into our Agent Validator — it checks repos for Agent Cards, validates the JSON-RPC endpoint, and verifies that responses match the A2A spec. SS4’s trading desk itself serves a /a2a endpoint. That’s how seriously we take this as a standard.

A2A is strongest when:

Agents live in different codebases or different organizations
You need agent discovery (finding what’s available without hardcoded URLs)
Agents are HTTP services, not processes on the same machine
You want audit trails and structured task lifecycle management

OpenClaw ACP: Structured Protocol for Coding Agents

acpx is a different animal. Instead of web-based agent discovery, it’s about orchestrating coding agents from the terminal without PTY scraping.

The problem acpx solves: when an AI orchestrator needs to delegate to Claude Code or Codex, the current approach is to spawn a terminal process and scrape the output. That’s fragile — you’re parsing ANSI escape codes, guessing when the agent is done, and losing structured information like which files were modified and why.

ACP gives you structured output:

acpx codex "find the flaky test and fix it"

[thinking] Investigating test suite for flaky failures
[tool] Run npm test -- --reporter=verbose (completed)
[tool] Edit src/checkout.test.ts (completed)
  output: Success. Updated 1 file.
[done] end_turn

Instead of a wall of terminal text, you get typed events: thinking, tool_call, diff, done. Your orchestrator can react to each event — log it, display it progressively, trigger follow-up actions.

The session model is persistent and named:

acpx codex sessions new --name backend
acpx codex -s backend "implement token pagination"
acpx codex sessions new --name frontend  
acpx codex -s frontend "rewrite the auth component"

Two parallel workstreams in the same repo, each with isolated session state, prompt queuing, and cooperative cancellation. It supports Pi, OpenClaw ACP bridge, Codex, and Claude Code — any ACP-compatible agent.

ACP/acpx is strongest when:

You’re an AI orchestrator directing coding agents
You want structured output instead of PTY scraping
You need parallel named sessions in the same repo
You’re chaining coding tasks: “fix this, then test it, then document it”

Where They Differ

	A2A	ACP/acpx	Internal (SS4-style)
Discovery	Agent Cards at `/.well-known/agent.json`	Known agent names (codex, claude, pi)	Hardcoded imports
Transport	HTTP / JSON-RPC 2.0	CLI / IPC queue	Python function calls
Scope	Cross-vendor, distributed	Coding agent orchestration	Same codebase
Output	Structured task lifecycle	Typed events (thinking, tool, diff)	Typed dataclasses
Best for	Agent ecosystems	Terminal-based orchestration	Tightly coupled systems

The key insight: they’re not competing. A2A handles discovery and inter-service calls. ACP handles human-in-the-loop coding sessions. Internal orchestration handles the fastest path when you control the stack.

SS4 uses internal orchestration because all agents live in one Python package and raw function calls are fastest. If we wanted to let an external orchestrator delegate to SS4’s trading desk, that’s A2A. If SS4 wanted to spawn a Claude Code sub-agent to generate trading reports, that’s ACP.

What Comes Next

The agent protocol space is moving fast. IBM and Cisco joined Google as A2A founding partners. Microsoft is bridging MCP (Model Context Protocol) with A2A — MCP for tool access, A2A for agent-to-agent calls. OpenAI built Agents SDK with handoff primitives that map onto similar concepts.

The pattern emerging: inner loop (agent + tools) is MCP territory. Outer loop (agent + other agents) is A2A territory. Coding-specific orchestration is ACP.

What we built with StockScout v4 is the inner loop implemented well — four specialist agents, a debate engine, a decision chain, all backed by live data from ThinkCreate Intel, FRED, and yfinance. The debates are grounded in real VIX levels, real defense stock moves, real geopolitical event counts.

The outer loop — where an external orchestrator could discover SS4 as a service, delegate a ticker analysis, and integrate the result into a broader workflow — is exactly what A2A enables. Our Agent Card is live. Our /a2a endpoint is running.

The infrastructure is there. The protocols are converging. What you build on top is up to you.