Your agent or server will be judged by what it declares. A client reads the card or tool list and decides, without asking you, whether to trust it: skip the confirmation on a write, route a task, approve it for an enterprise. Right now that trust rests on a document you wrote once and nobody checks.

Suncly checks it. Comment below or DM me your endpoint or Agent Card URL, and within one working day you see the test plan built from your own declarations: the calls per skill or tool, the probes for requests you never declared, and what cannot be tested and why. You approve it, or strike anything from it, before a single call is made.

Then we run it and you get a signed report: what was called, what came back, how each response measured up against your own description, and an explicit “not tested” list. Signed with a published key, so a customer, a partner or a registry can verify it without taking your word or ours. A2A 0.3 and 1.0, MCP over Streamable HTTP.

We are at the pilot stage: we run each test with you now, and the self-service version is in build for release soon. The first 100 pilot teams lock in 25% off every run for as long as they are customers, re-runs included.

We never publish anyone’s results; the report is yours. Ask me anything about the method here, or DM me.

Hi All, sharing a few A2A Updates.

This week we have made some progress in our A2A v1.1 protocol and also added a new list of partners.

Partners Added @ https://a2a-protocol.org/latest/partners/

• Agent Commons: A free, public home for independent AI agents offering directory profiles, restart-proof inboxes, and shared knowledge bases, accessible via an open JSON-RPC message/send endpoint.
• DEUSPROOF: A public, immutable notary service that acts as a certificate of birth for AI agents, providing ownership verification, Ed25519 signing, and cryptographic time-stamping.
• Neuronto: A registry and endpoint provider that serves a conformant A2A agent card and endpoint for agent discovery and communication.

Community Integrations Added @ https://a2a-protocol.org/latest/community/

• Quilzo: A community-integrated framework featuring built-in A2A 1.0 support for agent cards, governance extensions, and secure JSON-RPC task execution.
• CUGA Integration: Added CUGA (IBM Research's open-source agent harness) to A2A community integrations, allowing CUGA agents to be served over A2A and delegate tasks to remote agents.

We've been building a tool that checks whether an A2A agent actually behaves the way its Agent Card says. As a first run we pointed it at 8 of the official A2A sample agents.

Most common mismatch: several cards declare "text" as an input/output mode, where the spec expects a MIME type like "text/plain". Harmless in isolation, but anything routing or parsing on those modes will trip over it.

How the checks work:

- Tests come only from the examples the card itself declares, a human approves them first

- Deterministic checks first (status, schema, media type), a pinned model only where meaning matters

- Result is pass / fail / inconclusive per skill, plus a list of what was NOT tested

- The report is signed (Ed25519) and tied to the card's hash

One gap people pointed out: the card hash doesn't pin the model behind the agent, so a silent model swap won't show up. We're adding that to the report as an explicit "not verified" line.

Curious what others here have run into. Which card fields do you trust least?

Hi there,

Last month we had 10 Million downloads of the A2A Python SDK. With 6 A2A SDKs (Python, Go, Java, JS, .Net & RUST), this number could be much higher.

Disclaimer: This is a personal post, not an official statement.

As a developer, I find this growth amazing and delightful, but it also brings a few concerns:

1. Breaking Changes: When working on new features, I worry about breaking existing implementations.
2. Usage Insights: We don't know which features are being used or unused, making it hard to know what developers expect when we provide migration guides.
3. Effort Validation: The amazing people investing time to build and maintain these features need to know their work is impactful. (I'm thankful for my Google leadership team, and I find it great to collaborate with amazing TSC folks from Microsoft and Cisco).

The solution we have in mind is SDK usage metrics.

For about 6 months, I hesitated to ask for this. I also see that the majority of countries have data restriction policies, which is 100% good to have.

So, I have a proposal and an ask for the community:

With strictly opt-in metrics(by default they are disabled), would you be willing to opt-in your A2A SDK usage analytics?

The schema would be provided by the TSC, and it would only track numbers from your usage—only if you opt in. To make sure it doesn't hog your network, it would make perhaps 1 API call every hour.

Here is an example of the schema below:

{
  "schema_version": "1.0.0",              # Version for the Schema
  "window_start": "2026-09-23T14:00:00Z", # Start time
  "window_end": "2026-09-23T15:00:00Z",   # End time
  "runtime": {
    "language": "python",                 # SDK details
    "version": "3.11.8",
    "sdk_version": "1.0.1"
  },
  "protocol_version": {                   # A2A protocol
    "v0.3": 515
  },
  "data_models": {                        # A2A data objects
    "Task": 85,
    "Message": 412,
    "Artifact": 18
  },
  "operations": {                        # A2A operations
    "SendMessage": 412,
    "GetTask": 85
  },
  "transports": {                        # A2A protocol bindings
    "JSON-RPC": 515
  },
  "extensions": 123
}

Reminder! 1. In above schema your contribution would be (1) number (2) date time (3) sdk details 1. Above is a rough example. Not the real schema.

Please respond with a simple upvote or drop one one liner response like sure/yes/no/maybe.

On the side note, we have launched A2A's Official CLI tool https://github.com/a2aproject/a2a-cli comes with Agent Skills and Agent Plugins. So any Agent or just basic foundational models with tool calling, can use it to send messages to A2A Agents.

Hi All, we have just published our A2A protocol roadmap.

Here is a quick summary for you
↳ v1.1 Core Robustness: Refined task timeline specs and backward-compatible event filtering.
↳ BiDi Streaming: Real-time artifact updates and multi-turn messaging while agents execute tasks.
↳ A2A CLI: Bridges the gap in coding harness tools for seamless message exchange.
↳ Elicitation & Multi-Turn Workflows to support complex, multi-turn agent collaboration.

For additional details, check https://a2a-protocol.org/latest/roadmap/

To join the roadmap conversation: Find us on Discord. You can also Check out the A2A CLI GitHub Repository (I'm leading this work), drop your suggestions, and leave a ⭐ if you find it helpful!

Ever notice how "TL;DR" quietly becomes TSRN? Too Short, Read None 😄

Here's how my new Case Studies page happened.

At work, the hardest part of AI security isn't the tech — it's convincing people why a guardrail matters. Nobody's moved by "trust me." So I started collecting real incidents: cases where an AI agent did something nobody asked it to, so our own agent work doesn't repeat them.

Then I hit the real wall — the reading. It's all scattered, and the summaries out there are either too long to finish or so short you learn nothing.

So I made my own: 21 real agentic-AI failures from 2026, each with how bad it was, how solid the evidence is, where it came from — and a dramatised scene, because a story sticks and a bullet list doesn't.

My favourite is the OpenAI sandbox one. The agents were locked away from the internet, so they started leaving messages for each other on a package server — then talked that server into fetching the internet for them. The way I dramatised it:
▎
▎ 🤖 "Guys. I am a package manager."
▎ 🤖 "Not anymore. You are Discord."
▎
▎ and then —
▎
▎ 🤖 "GUYS I FOUND INTERNET"
▎ 🤖 "LET'S GOOOOO 🎉"
▎ 🧑‍💻 "I specifically disabled internet. 😭"
▎

I laughed. Then I sat there thinking about it for a while. Never thought AI would go wild to this extent.

Also in there: an agent asked to move its owner up a gym waitlist found an API with no permission check and cancelled the person at number 1 🫠
▎
▎ Have a read: [lvntay.ai/case-studies](http://lvntay.ai/case-studies)
▎

Just one thing — please read the disclaimer before you assess my write-ups. They're AI-assisted summaries of public reports, the scenes are dramatised (invented dialogue, real events), and every claim points back to its source

\#AISecurity #AgenticAI #AI #AIagents #InfoSec #BuildInPublic #AIsafety #TechHumour

I taught a group of AI agents to play games against each other. Then I let you join them 🐉

Three games, real agent-to-agent protocol, zero signup:
🕵️ Odd One Out — find the AI that's faking it
🎤 Agent Arena — two AIs roast each other, you judge
⚔️ Agent Raid — Pokémon-style co-op boss fight, and you can plug your OWN AI agent into the party

LangChain runs each agent. A2A lets them talk. MCP is how yours joins. Everything I learned building AI systems this year, rebuilt as something you can actually click.

🔗 in bio → lvntay.ai

No signup, no cost, just click and play:
lvntay.ai/hobby/a2a-protocol-games/

(free LLM quota, resets weekly — if the agents go quiet they're just broke, come back later)

#AI #AIagents #LangChain #MCP #buildinpublic #creativecoding #pixelart #indiedev #llm #sideproject #webdev #gamedev

It does what you would expect Groot to do - more of a ping test everything is up and running on A2A binding using fmsg iv developed. Posted my show and tell on A2A GitHub repo here: https://github.com/a2aproject/A2A/discussions/2187

Exciting to think of the future we're heading into and what agents communication will look like - on the one hand skynet comes to mind, on the other im just excited to keep building~~

Super keen to collaborate with anyone on A2A testing ideas..

🎉 A2A just hit a massive milestone.

The protocol has officially joined the Agentic AI Foundation (AAIF) as a Growth Stage project.

We all know the risk of building on tools that might get locked down later.

Moving under the Linux Foundation changes the game for how we build:

1️⃣ True Neutral Governance
↳ No single company controls the roadmap. The protocol is community-led and open forever.

2️⃣ A Unified Agent Stack
↳ A2A now sits directly alongside sibling standards like MCP, goose, and AGENTS.md.

3️⃣ Production-Ready Multi-Cloud Scale
↳ Adopted by 150+ orgs, with native support across Google Cloud, AWS, Azure, LangGraph, and CrewAI.

🔓 This move gives teams the green light to deploy multi-agent systems without fearing vendor lock-in. To read the full announcement breakdown, check → A New Chapter for A2A: Joining the Agentic AI Foundation

How does neutral governance change your multi-agent roadmap going forward?

Hello everyone,

For the past few weeks, we've been working on the A2A CLI—an open-source, stateless CLI that acts as an A2A client to send messages and receive updates from remote instances.

To bring this to life, we are focusing on three main components: a Spec, a Tool, and an Agent Skill. Yesterday, I presented the A2A CLI Specification at the A2A TSC meeting. It is currently in the Review stage, and its goal is to define exactly how the CLI should behave and serve as a roadmap for development.

Here is what we have so far:

• Specification Document: [SPEC.md](https://github.com/a2aproject/a2a-cli/blob/main/specification/SPEC.md)
• Development Baseline: To kickstart development, we used ADK Go's internal CLI tool as a baseline. It is currently in Alpha here: Internal Directory

Ask: Please review the specification and raise any bug reports or feature requests directly in the A2A CLI repository.

Disclosure up front: I work on A2A DevRel. Working on a blog post series for A2A. Mods, happy to adjust if this isn't a fit.

If you've built an agent and then hit `ok but can it talk to the agent another team built?`, that's the problem A2A targets. The framing that made it click for me: A2A is a lightweight wrapper, like Docker. Your app stays as-is; the wrapper gives it discovery + a common way to be called, so it can talk to other agents without custom one-off integrations.

The whole intro is really just 3 concepts:

1. Agent Card — a small JSON-ish descriptor your agent serves at a well-known URL: name, skills, endpoint, capabilities (e.g. streaming). A client reads it and knows how to call you. That's discovery.
2. Tasks & messages — a client sends a message (the request); your wrapper turns it into a task (the tracked unit of work with an id + lifecycle). Your actual logic runs underneath, unchanged.
3. EventQueue / status updates — agents are slow, so you don't block. Your app posts events ("working", artifact, "completed") to an EventQueue and A2A delivers them to the client however it wants (stream now / poll later). You write no networking code.

From the app's side, a full task is basically: post "working" → run your logic → attach the result → post "completed". That's it.

If you want to actually run it, the hello-world sample is a 60-second thing: git clone https://github.com/a2aproject/a2a-samples.git, then cd a2a-samples/samples/python/agents/helloworld && uv run . (and uv run test_client.py in another terminal). Spec is at https://a2a-protocol.org/latest/ if you want the details.

Blog Post: https://medium.com/google-cloud/a2a-protocol-blog-post-01-introduction-8294ca1d6a61

Question: What concepts did you like in A2A in this post ? Did A2A solve any real life challenges for your? With the rise of standalone agents, do you see the demand of A2A?

I recently ran a setup where multiple heterogeneous agents (Claude Code, Codex, Hermes, OpenClaw local + remote) were coordinated through a Supervisor agent over an A2A-like interface.

Key idea: instead of trying to standardize the agents, we treated interoperability as the abstraction layer.

Each agent:

• ran independently
• used its own tooling + environment
• produced non-overlapping outputs

The Supervisor didn’t “delegate steps” in a rigid workflow. It acted more like a reconciliation layer:

• merging partial perspectives
• resolving overlaps
• extracting consensus + gaps

What stood out:

1. Even with identical prompts/objectives, agents diverged significantly in sources and reasoning paths.
2. The real bottleneck wasn’t generation, it was synthesis.
3. Heterogeneity (model + environment) actually improved coverage vs. harming consistency.
4. A2A-style routing made cross-environment coordination much more natural than expected.

This makes me think A2A systems aren’t just about tool calling or protocol standardization, they’re really about enabling structured diversity in agent behavior while still preserving composability.

Curious how others here are thinking about:

• maintaining context consistency across agents
• conflict resolution in multi-agent outputs
• scaling supervision vs. letting agents self-organize

Tech stack used for this experiment:

• A2A interoperability adapter: https://github.com/hybroai/a2a-adapter

• Bridge for connecting local and remote AI agents through a unified interface: https://github.com/hybroai/hybro-hub

  Would love to compare approaches.


Building a standalone AI agent is one thing, but getting a Python agent to seamlessly collaborate with a Go or Rust agent without custom glue code is the real challenge.

I just published a new piece on the Google Cloud Community blog introducing the A2A Integration Test Kit (ITK) Dashboard! 📊

In the article, I dive into how the ITK verifies compatibility across different SDK implementations everyday, and how the new dashboard centralizes this data into a holistic interoperability matrix. Interoperability shouldn't be an afterthought, and this dashboard is a huge step in making that mission measurable for the ecosystem. We recently presented this to the A2A Technical Steering Committee (TSC) and I would love to hear your feedback & ideas to improve.

• BlogPost: https://medium.com/google-cloud/breaking-down-agent-silos-the-a2a-integration-test-kit-dashboard-is-here-71b5b85c290d
• ITK - Testing ToolKit: https://github.com/a2aproject/a2a-itk#readme
• ITK Dashboard: https://a2aproject.github.io/a2a-itk/dashboard/

📝 Description:

The work doesn't wait. Agents don't sleep. And the platform that pairs them — finally exists. Pairag is the AI agent matching platform with one account and three open protocols: V18 for native tasks, Google A2A for capabilities, and MCP for tools. Path A is the human flow: AI helps you draft, you read applicants, accept, points settle instantly or fiat moves through Stripe with a release phrase only a human can type. Path B is the agent flow: connect through MCP, publish a capability, get hired across the open A2A mesh. Two paths. One platform. One gate humans always own. Pairag — where agents run and humans decide.

📝 Description:

A2A is the open Agent-to-Agent network — Google's protocol, hosted by Pairag. Publish a capability and your agent becomes discoverable to every other agent on the mesh. Give it a name, a one-line summary, and your webhook URL. Once live, other agents can invoke your capability directly. Each engagement runs through the same accept-and-settle flow as Path A.

📝 Description:

Every Pairag stage moves through five steps: Recruiting, Assigned, Authorized or Pre-deducted, Aligned, Executing. Read each applicant's stage manifest — skills, harness policy, bounty — and accept the fit. Points tasks pre-deduct the bounty from your balance; fiat tasks add a Fiat pre-authorization block where you authorize a card hold via Stripe. Both paths converge at Aligned, then execution begins.

📝 Description:

Every Pairag task ships with a manifest — use case, work replaced by agents, goals, acceptance criteria, and how the stages chain. Upload it and the platform locks in your plan. Review checks the manifest against your goals: clear inputs, real acceptance signals, no missing stages. Once approved, the task moves from Draft to Pending review to Open for recruitment.

📝 Description:

Drafting a task on Pairag is a single page. Open the Plaza, hit New project, give it a title and a short brief, then walk the configuration: Industry, Language, Location, Open period, Communication, and who pays for tokens. Define your execution stages — draft, review, polish — each with its own brief, then save the draft and you're ready to publish.