Build a loan-validation agent with Google ADK and expose it as an A2A server using the to_a2a() one-liner — the simplest A2A integration of any framework. Uses LiteLlm to run Azure-hosted Kimi-K2 without any Google Cloud dependency.
A2A with Google ADK · 7 minsTranscript9 entries
Instructor:Welcome back to LocalM Tuts, I am Nilay Parikh. This is lesson 9 of 16, A2A with Google ADK. Last time we build an orchestrator with Microsoft Agent Framework that routed tasks to remote A2A agents. If you are watching this as a standalone video, find the complete course playlist linked below in the description. Here is what you find. All the code for the lesson, the links of GitHub repository and the interactive page is in the description. Clone the repo, open the lesson folder and follow the loan
Instructor:validation agent using KAMI key 2 Thinking via the LiteLlm adapter. The magic is what method is called to_a2a(). It auto-generates the Agent Card, creates the executor and starts the server. One line replaces everything from lesson 6. Compare this to lesson 6 where you wrote the Agent Card, JSON, AgentExecutor class, and server startup manually. ADK does all 3 in a single function call. It also supports multi-agent patterns, sequential parallel and the loop agent natively. Let's see this in action.
Instructor:Install dependency, configure the credentials, start the server on port 10002. Run that line and watch how to_a2a() does everything: Agent Card, executor, server, just in one line. Pause the video and try it yourself. Lesson 9. Practical implementation for Google ADK. As we saw, is just a one method. Does all the magic. to_a2a() is a one liner that converts any ADK agent into the standard A2A server and this is what we are doing. We are just literally calling to_a2a(), to A and the same pattern as
Instructor:we discussed in the Microsoft Agent Framework orchestrator which does the orchestration, and we are using Google ADK components. And the same logic, same approach, but with the Google ADK. And the client. The client always uses A2A because I am. the key aspect that I want to prove is A2A interoperability works irrespective of server implementation. So the server and orchestrator implementation use the SDK, but the client implementation uses A2A. a. Of course you can do the client implementation using Google SDK as
Instructor:well. But it demonstrates like how interoperability is available with A2A as well. So lets see the same loan data, the same validation rule and we are in the same. Yes, src. So let's just go ahead and run the app. server, and let's see what happens. python client.py, and let's see if the server is up and running by now. Coming back home. There we go, it's up and running. Now some of the experimental warnings, I haven't suppressed it and now let's run the client.
Instructor:Again, I said some of the experimental conditions, some of the experimental flags I haven't turned off. But it is validating perfectly. See. It worked well. These warnings come from experimental features and I should have done slightly better, but yeah, it's not an error. It's not fake. And if we go back on lesson 9, it does generate the same approvals and rejections. See Just stopping
Instructor:everything here. And job done, it has dropped properly. Perfect. So now, let's wrap it up with a very simple cover. The orchestrator does the magic about how to orchestrate in different sessions agent, and it also uses LiteLlm. By the way, Google ADK may be hard to port on Azure or anything. It generally very good with the vertex AI or Google cloud dependency. But if you are using Azure any other? LLM endpoints then you might need a LiteLlm adapter, which is not a bad idea. It is a good thing it is available in
Instructor:Google ADK itself, and it helps you to port to any other model. And the client is simple: A2A client, and the server: simple Azure use, simple Google ADK to_a2a(). A. That's it. You have built the simplest A2A integration in the course: a fully compliant server in about 15 lines. The orchestrator from lesson 8 can already call this agent without any changes. Thanks for watching this lesson on LocalM Tuts. In the next lesson we will combine A2A
Instructor:along with LangGraph, building a ReAct agent that uses MCP tools, A2A for agent communication. You can find the next video link in the A2A Protocol playlist. In description, see you there.
Learning Objectives6
Build an LlmAgent using Google Agent Development Kit with custom FunctionTool wrappers
Configure LiteLlm to run Azure-hosted Kimi-K2 (no Vertex AI or Google Cloud required)
Expose the agent as an A2A server with the to_a2a() one-liner
Compare manual A2A wiring (Lesson 08) vs to_a2a() auto-configuration
Connect via a standard A2A client — discover, query, extract response
LiteLlm is a model-agnostic adapter that lets ADK agents work with any LLM provider (Azure, OpenAI, Anthropic) without Vertex AI or Google Cloud dependencies.
Q
What does to_a2a() generate automatically?
to_a2a() creates: Agent Card with metadata, Runner with session/artifact services, task store, A2aAgentExecutor, and a Starlette application with all routes wired.
Q
How does FunctionTool differ from Microsoft AF's @tool decorator?
Both wrap Python functions as agent-callable tools. ADK's FunctionTool reads type annotations at construction time. Microsoft AF's @tool uses Pydantic Field metadata. Functionally equivalent.
Q
Can ADK agents call other A2A servers?
Yes, via RemoteA2aAgent. You compose these into SequentialAgent or ParallelAgent pipelines, mixing local and remote agents seamlessly.
Q
Where does the loan validation data come from?
Shared data from _common/src/ — loan_data.py provides three synthetic applicant profiles. validation_rules.py defines the deterministic thresholds. This data is reused across all framework lessons (08-13).
