A2A Protocol Support within Lemonade - lemonade-a2a

Community Corner Showcase
, , ,
1

Introducing Lemonade-A2A: Bringing Agent-to-Agent Communication to AMD Lemonade :rocket:

Hi AMD Developer Community! :waving_hand:

I’m excited to introduce Lemonade-A2A, an open-source project exploring how we can extend AMD Lemonade with standardized Agent-to-Agent (A2A) communication.

AMD Lemonade makes it easier to run local AI models on AMD hardware. But what if those locally hosted models could also participate in a broader ecosystem of autonomous AI agents?

That’s the idea behind Lemonade-A2A.

:light_bulb: What is Lemonade-A2A?

Lemonade-A2A aims to bridge AMD Lemonade’s local model-serving capabilities with the open Agent2Agent (A2A) protocol, enabling AI agents to discover, communicate, and collaborate across applications and environments.

The goal is to make locally hosted AI models more than just inference endpoints — turning them into building blocks for interoperable agentic workflows.

:bullseye: Project Goals

  • A2A Protocol Integration: Bring standards-based agent communication to the Lemonade ecosystem.

  • Local-First AI: Enable agent workflows powered by models running locally on AMD hardware.

  • Model Agnostic: Support different open models through Lemonade without coupling agent communication to a particular LLM.

  • Lightweight Architecture: Minimize resource overhead so agent communication doesn’t compete unnecessarily with local inference.

  • Interoperability: Enable collaboration between local Lemonade-powered agents and other A2A-compatible systems.

  • Open Source: Encourage community contributions, experimentation, and integration.

:telescope: Why This Matters

As AI moves from single-model interactions toward multi-agent systems, interoperability will become increasingly important.

I believe local AI infrastructure should support not only efficient inference but also standardized agent discovery, delegation, and collaboration.

With Lemonade-A2A, I want to explore how AMD-powered local inference can become part of an open, distributed agent ecosystem — without requiring every agent to depend on proprietary cloud infrastructure.

:hammer_and_wrench: What’s Next?

I’m exploring lightweight protocol adapters, agent discovery, task lifecycle management, and integrations that allow existing agent frameworks to interact with Lemonade-hosted models.

This is an evolving open-source initiative, and I’d love feedback from developers working with AMD Lemonade, local LLMs, and agentic AI systems.

:handshake: Join the Project

GitHub: swamx (D Swami) · GitHub

I’d especially welcome thoughts on:

  • Making A2A a reusable integration layer for Lemonade

  • Keeping the implementation lightweight and developer-friendly

  • Supporting interoperability with frameworks such as LangGraph and other A2A-compatible agents

If you’re interested in local AI, open protocols, or multi-agent orchestration, I’d love to collaborate!

Let’s make AMD-powered local AI more connected, interoperable, and agent-ready. :rocket:

amd #AMDDeveloper lemonade #LemonadeA2A #Agent2Agent #A2A #LocalAI #OpenSource #AgenticAI

2

Hey, the repo is easy to miss, since the post links your profile and Lemonade-A2A isn’t pinned there. But I found it anyways : )

Your README shows the official A2A TCK passing, with ROCm and NPU backends still untested for lack of hardware, and two AMD routes could close that gap. The AUP Learning Cloud gives access to Ryzen AI and Radeon systems on request AUP Learning Cloud

Radeon Test Drive gives remote access to a Radeon workstation GPU for up to 14 days of non-commercial testing, and AMD’s access programs page lists it with the other options AI & HPC Cloud Access

3

Thank you. That is very helpful. Good point I will pin the github to my profile. New hear still getting around.

4

Yes you can pin and also update this post here, because it points to your profile rather than the project repo. You’re welcome : )

5

One small benchmarking improvement for keeping the adapter lightweight: distinguish transport chunks/s from model output tokens/s. Your benchmark notes explicitly describe chunks/s as a proxy. Splitting Hello world into one event versus two changes that number without changing the generated text; SSE/A2A event boundaries can therefore confound a direct-versus-adapter comparison.

I would keep chunks/s as a transport metric and count the completed output with the same model tokenizer for both paths. For the reasoning-model cells, record first reasoning output and first user-visible answer separately: your notes already identify reasoning_content consuming the output budget. Counting those events as answer tokens would obscure the issue rather than fix it.

A cheap regression fixture would send identical text once as one delta and once as several deltas, then assert identical assembled output and token count. Lemonade’s API reference documents streaming deltas. This can be checked with your mock before spending AMD inference time. I haven’t run your adapter on ROCm/NPU hardware; this is a measurement suggestion based on the published docs.

6

Thank you Yusuf, I have incorporated the changes recommended in latest release. I should be merging it soon. Let me know if you have other feedback.

7

Thanks, Devang — the assembled-token count is now independent of chunk boundaries. I ran one small reporting fixture against benchmarks/stream_metrics.py in swamx/lemonade-a2a, revision f34af3967f7c30a956574a566675ef93fcdca985.

With identical Hello world, first answer at 100 ms and end at 200 ms, both layouts count 2 output tokens. One event reports 0 tokens/s; two events report 10 tokens/s. This is a deterministic transport/tokeniser fixture, not a model-speed measurement:

from stream_metrics import StreamTally

for parts in [("Hello world",), ("Hello", " world")]:
    tally = StreamTally(start=0.0)
    for i, part in enumerate(parts):
        tally.add("answer", part, now=0.1 + 0.05 * i)
    result = tally.result(end=0.2)
    print(result["output_tokens"], result["tokens_per_s"])
# 2 0.0
# 2 10.0

The remaining rate is a post-first-event rate: it subtracts the first event’s token count and returns zero unless there are multiple events. A buffered single-event reply can therefore look like zero-speed generation.

A small reporting improvement would be to label that estimator explicitly, return an unavailable value for single-event streams, and exclude unavailable rates from percentile summaries. The assembled output count can stay as it is. This would make direct-versus-adapter comparisons easier to interpret without another AMD inference run.

8

Thank you, thats a good catch. I was able to fix it and make a release, changes are merged in main.

9

I dont think I have edit permission for now.