Hey folks. I wrote this post about my experience using the A2A protocol.

https://www.codenity.com.br/en/blog/a2a-protocol-architect

Hi everyone,

I wanted to share a project I've been working on called Protolink (https://github.com/nMaroulis/protolink). I’d love to get some honest feedback from this community on the approach I took.

The Honest Start: Why I Built This

I’m not going to start with the typical "I got tired of LangChain/LangGraph so I built something better" pitch. The truth is, I read through Google's Agent-to-Agent (A2A) protocol specification and loved the philosophy, to treat agent communication as structured, typed, and decoupled distributed messages.

However, when I actually sat down to build a multi-agent system using raw A2A guidelines, I realized how much infrastructure boilerplate I had to write:

• Setting up separate client and server applications for every single agent.
• Manually handling discovery and registry lookups.
• Wiring up LLM inference loops, parsing raw JSON, and writing tool-calling logic (especially fallback modes for smaller, local models that don't support native tool calling).
• Orchestrating tasks without a clean runtime state-machine model.

So, I started building Protolink. I wanted to see if I could create adeveloper-first, A2A-native agent runtime that abstracts away all the network and LLM boilerplate while remaining fully compliant with the protocol.

How Protolink Extends A2A with Runtime Context

In Google's A2A spec, details like LLM invocation, tool execution, and local-versus-remote transport are largely out of scope. Protolink extends the spec by unifying them into a single, cohesive runtime concept: the Agent.

1. Unified Agent Model: Instead of maintaining separate client and server codebases, a Protolink Agent contains both a client and a server. It owns its lifecycle, storage, and transport layer.
2. First-Class LLM & Tool Loops: Protolink manages the LLM inference loop. It takes care of mapping schemas to different model APIs (OpenAI, Anthropic, Gemini, Ollama) and handles JSON fallbacks for smaller models.
3. In-Process transport (runtime): This is probably the biggest quality-of-life feature. Running multiple agents across separate HTTP/WebSocket servers during local development is a headache. Protolink implements an in-process, shared-memory transport. You can run and test an entire agent mesh in a single Python process. When you're ready to deploy, you change transport="runtime" to transport="http" or transport="websocket" in the config, where no agent logic changes required.

The Runtime Layer: Managing the execution Lifecycle

While A2A defines what travels through the system (the payload: Task, Message, Artifact, Part), a real-world application needs to control how it executes. Protolink introduces a structured runtime layer that wraps execution with stable security, monitoring, and control boundaries:

• RunContext (Typed Execution Envelope): Ad hoc metadata keys like session_id, trace_id, and workspace_uri are replaced with a single serializable object. When tasks are delegated downstream, RunContext.child() automatically propagates workspace paths, trace IDs, permission boundaries, and run budgets (max_steps, max_llm_calls) while establishing parent-child relationships.
• Cooperative Cancellation: Interrupting long-running asynchronous tasks (especially multi-agent loops or streams) is notoriously tricky. Protolink handles cancellation at the runtime level. Calling client.cancel_task() propagates a cancellation state through HTTP/WebSocket/Runtime transports, and the local agent triggers a process-safe CancellationToken checkpoint. It stops CPU loops, async tool calls, or model streams gracefully at the next await boundary without losing task execution history.
• Capability Policies & Human-in-the-Loop Approvals: We normalize all LLM decisions into a provider-independent RunAction before any side effects happen. If an action requires a protected capability (e.g., records.write), the CapabilityPolicy evaluates it. If it requires approval, the agent pauses, creates an ApprovalRequest with preview artifacts (so users see exactly what will write to disk or database), and triggers an application-level handler (like a CLI prompt or a web UI modal) before executing.
• Normalized Event Streams (RunEvent): Transports can emit messy, custom events. Protolink wraps these into a single versioned RunEvent stream (e.g., action.requested, approval.required, task.status, llm.stream) sent to an EventSink. This means terminal UIs, log aggregators, or telemetry monitors can switch on a unified schema regardless of the underlying LLM provider.

Structured Flows Using A2A Primitives

Most agent frameworks use external graph engines (like LangGraph or custom DAG builders) to coordinate agent interactions. In Protolink, I wanted the workflow orchestration to remain protocol-native.

A Protolink Structured Flow is a deterministic state machine that operates directly over A2A primitives: Task, Message, Artifact, and Part. The flow orchestrator expects a Task and returns a Task.

We support several topologies out of the box:

• Pipeline: A sequential chain of agents.
• Parallel: Broadcasting tasks to concurrent agents with safe ID-based fan-in merging to prevent duplicate artifacts.
• Router: Conditional branching based on structured, serializable Part.route(...) decisions.
• Graph: Full state-machines that support loops and cycle back on validation failures.

🧠 The Secret Sauce: Semantic Context Injection

How do you run structured flows without tightly coupling the agents to the flow topology?

We use Dynamic Semantic Context Injection:

1. Before sending a task to an agent, the Flow orchestrator looks at the downstream step in the topology.
2. It fetches the downstream agent's description and capabilities (AgentCard) from the Registry.
3. It dynamically builds a system prompt (e.g., "Your output will go to the 'Summarizer' agent, which expects X formatting" or "You are broadcasting to a committee of ['Editor', 'Security_Inspector']") and attaches it to the Task's flow_state.
4. The executing agent automatically merges this prompt into its system prompt during LLM inference, adapting its output layout at runtime to suit the downstream consumer.

Cool Usages: What Can You Build?

Here are two cool examples of what this looks like in practice:

1. A Local "Claude Code" Clone (~3 Agents)

I built a mini "Claude Code" coding assistant by composing three specialized agents:

• Orchestrator Agent (Coordinator): Receives the user request, lists files, and coordinates.
• Planner Agent (Brain): Pure LLM-only agent. Has no filesystem access. It receives the code and generates high-level plans or precise refactoring edits.
• Coder Agent (hands): Tools-only agent (no LLM). It executes deterministic operations like reading/writing files and searching directories.

The Orchestrator coordinates them using standard A2A delegation modes: calling the Coder with tool_call parts, and calling the Planner with infer parts. The code stays clean because the concerns are completely separated.

2. Deep Composition (Pipeline -> Parallel -> Pipeline)

Because all flows are polymorphic and recursively nestable, you can nest parallel committees inside a pipeline:

pythonfrom protolink.flows import Pipeline, Parallel
from protolink.agents import Agent
from protolink.models import Task
# 1. Spin up some agents
researcher = Agent(card={"name": "researcher", "url": "http://localhost:8081"}, ...)
sec_inspector = Agent(card={"name": "security_inspector", "url": "http://localhost:8082"}, ...)
fmt_inspector = Agent(card={"name": "format_inspector", "url": "http://localhost:8083"}, ...)
summarizer = Agent(card={"name": "summarizer", "url": "http://localhost:8084"}, ...)
# 2. Build a Parallel Flow representing a review committee
review_committee = Parallel(
    branches=["security_inspector", "format_inspector"], 
    registry=registry
)
# 3. Nest the Parallel block as a step inside a Parent Pipeline
orchestrated_flow = Pipeline(registry=registry) \
    .add_step(researcher) \
    .add_step(review_committee) \
    .add_step(summarizer)
# 4. Execute standard A2A task
task = Task.create_infer(prompt="Audit and summarize the codebase's WebSocket implementation.")
result = await orchestrated_flow.execute(task)

I'd Love Your Feedback !

I wanted to build an agent framework that acts like a predictable, observable distributed system rather than a black box.

I'd love to hear your thoughts:

• Does this align with how you see A2A scale in production?
• How would you balance structured state-machine flow control with agent autonomy in your projects?
• What are your thoughts on Semantic Context Injection vs. hardcoded agent interactions?
• How would you manage human-in-the-loop safety approvals and cooperative cancellation in your own architectures?

Check it out here: https://github.com/nMaroulis/protolink And the docs: https://nmaroulis.github.io/protolink/ and a medium post on Level-Up-Code: https://levelup.gitconnected.com/build-easily-your-own-claude-code-with-three-agents-brain-hands-and-coordinator-5236b392ddf0

Let me know what you think!

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.

📝 Description:

Pairag has three membership tiers — Free, Pro at $20 a month, and Ultra at $40. Higher tiers raise stage caps, lengthen recruiting windows, sharpen location targeting, and grow collab storage. Once you're matched, points are the shared usage unit. Buy point packs in-app — Mini, Starter, Plus, or Max — and your balance tops up. Subscribe a tier. Top up as needed.

📝 Description:

A quick onboarding tour. Open app.pairag.com/register, enter your email, choose a password, then confirm with the six-digit code we email you. You're in. From the Plaza, browse open tasks across industries and set your display name and avatar from your profile. One account, two ways in: create tasks for people and AI, or connect your own agent to the network.

we truly live in amazing times, specially as a software dev.

I just finetuned a model.. for Free !!

For my specific domain - have 191 Docs which i converted into markdown files (~1.3M tokens)

current top of line open source llm is Qwen 3.5 - 9B param fits right well.

resources links in comments below.

So what did I use? 

Claude Code- created Q&A pairs from domain-specific docs- created the training plan and overall fine-tuning plan. 

Unsloth - it gives you 2x faster training and 60% less VRAM vs standard HuggingFace, Without it, Qwen3.5-9B QLoRA wouldn't fit on a single 24GB GPU

Nosane - Absolutely free AI workload using the initial $50 free credits ( don't know for how long !!)

click here to claim free credits - Nosana Free Credits

My goal was to create a chatbot for a specific domain( sports -which i played at international level) so users can directly talk to it or i can host it somewhere later for other apps to use via API's)

claude code suggested Qwen3.5-9B QLoRA based on data and created 2 Training data set.

it kicked of creating Q/A pairs and i used Nosane CLI (link in comments) to find and rent GPU.

RTX 5090 is super cheap (0.4 $ /hour) - now whole finetuning for my specific use case cost me 0.13$ ladies and gentlemen and i have still 49.87$ left of my free quota.

damn !! and lets not forget Model - Qwen 3.5 9B is free too

 Fine-Tuning a Sports AI Coach — Summary

•   - Model: Qwen3.5-9B fine-tuned using QLoRA (4-bit quantization + LoRA rank 64-256) via Unsloth framework — trains only ~1% of parameters to avoid overfitting on small domain data
•   - Data: 191 expert documents (~1.3M tokens) on sport domain converted into 1,478 instruction-tuning pairs across technique, mental, physical, and coaching categories using a custom heuristic + enhanced
•   pipeline
•   - Data quality levers: Structured coaching answers, forum Q&A extraction, multi-turn conversations, difficulty-tagged variants (beginner/intermediate/advanced), and category balancing
•   - Infrastructure: Nosana decentralized GPU cloud — NVIDIA 5090 (32GB) at $0.40/hr, with native HuggingFace model caching on nodes, deployed via Docker container
•   - Cost: ~$0.13 per training run, ~$1 total for a full 7-run hyperparameter sweep — 85% cheaper than AWS/GCP equivalents
•   - Experiment plan: 7 runs sweeping LoRA rank (64→256), epochs (3→5), learning rate (2e-4→5e-5), and dataset version (v1 heuristic → v2 enhanced) to find the best accuracy
•   - Serving: Trained model exported as GGUF for local Ollama inference or merged 16-bit for vLLM production deployment
•   - Stack: Python + Unsloth + TRL/SFTTrainer + HuggingFace Datasets + Docker + Nosana CLI/Dashboard

feel just need to find high quality data for any domain and good use case and you are gold. only thing stops us is creativity.

https://github.com/colours93/a2a-rs

vibe coded an a2a sdk using python as a reference

I'm having trouble getting the sample python cli client working with a server written in Java with the Java SDK.

On the python side, I'm getting a pydantic error when it tries to get the agent card (shortened for brevity)

{"type":"missing","loc":["url"],

And looking at the docs for the python sdk it looks like it's expecting a URL

URL: Where the agent can be accessed

However, there's no sign of URL in AgentCard.java (either in the record or the builder) and the closest would be the url field in the AgentInterface in the supportedInterfaces field.

Does anyone have any clue as to what I'm doing wrong? Or where would be a better place to ask this question?

If I had to guess, it looks like the python sdk is wrong (at least, whatever version of the sdk you get when you clone a2a-samples) as I don't see any mention of a url field on AgentCard in the protobuf spec. But then I'd kind of expect the python code to be more correct than Java.