Build an OrchestratorAgent with Microsoft Agent Framework that uses Kimi-K2-Thinking to validate loan applications via hard rules and multi-step LLM reasoning, then expose it as an A2A server for cross-framework interoperability.
A2A with Microsoft Agent Framework · 9 minsTranscript12 entries
Instructor:Welcome back to LocalM Tuts, I am Nilay Parikh. This is lesson 8 of 16, A2A with Microsoft Agent Framework. In the last lesson we built the client side: discovering agents, sending tasks, handling both blocking and streaming responses. If you are watching this as a standalone video. Find the complete course playlist linked below in the description and follow along at tuts.localm.dev/a2a. Here is where you find all the code for the lesson. The GitHub repository link is in description as well as the interactive
Instructor:tutorial page. Link in description, clone the repo, open the lesson folder and follow along. Three files: orchestrator with the tool decorated functions, server that exposes A2A, and client to test it. The orchestrator uses A2A agent proxy objects to call the remote agents discovered via the Agent Cards. The A2A agent proxy is a key pattern. It wraps any remote A2A agent as a local callable. The orchestrator doesn't know what framework or provider. The remote agent uses, it just sees the Agent Card and sends
Instructor:the task. Let's see this in action. Install the dependencies, configure Azure credentials. Then start the server and client in separate terminals. Watch the orchestrator discover agents via their Agent Cards and route the tasks using LLM-based tool calling. Pause the video and try it yourself. Just a one quick note, you don't need Azure credentials or Azure AI Foundry to run this example. Microsoft Agent Framework is agnostic, you can use it with other OpenAI-compatible URLs as well, and
Instructor:you can discover many different methods and many different compatibility with their documentations. So please follow if something different you want to you would like to try with example, but we will keep it simple with our Azure Foundry AI. Welcome to lesson 8 Practical example A2A wrapping with the Orchestrator agent. In this we will validate the loan validator as we pass our various loan application and see what happens. The architecture is pretty simple from lesson 8 to lesson 13. They all tried to solve the
Instructor:same problem but using different stacks and they all try to adhere to the A2A protocol. So let's see the first Microsoft Agent framework. We have 3 components, the client which you connect, the orchestrator which you orchestrate, the agent and the server. Which will host the A2A connection and then the 2 common files which are shared across all the SDK examples: the loan data. Instead of creating a database I just created a simple Python file with the loan and the validation rule. So they
Instructor:have their own validation rules where they can accept or reject just to make sure we have result quality. Now once this example is run, it can also log the complete audit template, what it did, what happened, what the reasoning behind the rejection or acceptance and what it did. And if I go in alone data, then this is what we generally expect. We expect a couple to review, a couple to decline, and couple to approve. So now let's run everything. To run it, you go in the Microsoft Agent
Instructor:framework path, simply set up. I assume you have already set up your Python virtual environment or the environment that you are running and then simply python server.py. So I think we are in the wrong folder, cd src. Run python server.py there in the client as well as src, and I will just see if the server is open and running. Yep, server is up and running on 10008 and I will just run client.py. It will try to process the data. So we can see here it is processing data.
Instructor:And actually it is going to Azure. By now, so let me see if I can get Azure. While it is running. Let's see. And if you don't have access to this particular Visual Studio Code or or examples at the time you are watching this, you can actually use our interactive page where there is lot of information to read, understand and it explained in very detail. And if you are especially preparing for interviews and there are really interesting questions that you can go through and
Instructor:actually validate while running this thing. And also we have we have very very detailed run steps. So hopefully it should not be difficult for anyone to make this example run. But lets see whether the model does work. And yes, we see this. We suddenly see after its. This is the time I'm running. And we now have certain tokens going through, so it is connecting. Into Kimi-K2-Thinking. There you go, you are done. So it did, saying like it rejected Bob Kwan. As when declined it given a very
Instructor:good reasoning as well. why it has declined and this is again I am trying to mention that agents are not supposed to be deterministically rejecting or accepting Agent must do semantic and agent. Analysis and provide a proper reasoning and flag. So these slacks and risk flags. Reasoning is not generated deterministically; it is generated by the thinking model. And there is another conversation some other day we will do why thinking model and why thinking model do better than non thinking model. And
Instructor:for this particular application the thinking model is very useful and will talk in some other particular tutorial where we will discuss partly specifically this point that. Regular reasoning model versus reasoning thinking model and how to implement and benefit from thinking. So well. It did everything and none of these comes via. The hard deterministic coding, it all comes via the agent itself and the detail. verify log is here. As we can see it has stopped here as well, so that's good. So why have
Instructor:we actually did the Microsoft Agent Framework? It is. It's a simple, but really useful. And you can see VI using Agent framework here and it's really, really interesting. Thanks for watching this lesson on LocalM Tuts. In the next lesson Google ADK shows how simple A2A integration can be. Just one function call with to_a2a(). to a. You can find the next video in the A2A Protocol course playlist link in the description. See you there.
Learning Objectives6
Install and configure Microsoft Agent Framework with Azure AI Foundry
Create an Agent with tool-decorated functions using @tool decorator
Use AzureOpenAIChatClient with API-key credentials (no az login required)
Call Kimi-K2-Thinking to reason over structured evidence for edge-case validation
Wrap the orchestrator as an A2A server for cross-framework interop
Connect to the A2A server with a standard A2A client — proving framework-agnostic interop
Run the Lesson 08 Example
0/7
Clone and navigate
git clone https://github.com/nilayparikh/tuts-agentic-ai-examples.git
cd tuts-agentic-ai-examples/a2a
Why run the hard checks in Python rather than letting the LLM evaluate the rules?
Deterministic rules should be deterministic. Running them in pure Python guarantees identical results on every call, is auditable, orders of magnitude faster, and costs nothing in tokens. The LLM reasons about the interaction between rule results.
Q
What does the @tool decorator actually do?
It reads the function's type annotations and docstring to build a JSON schema for the model. When the model calls the tool, the framework validates arguments, invokes the function, and returns the result as a tool message.
Q
Why AzureKeyCredential instead of DefaultAzureCredential?
DefaultAzureCredential requires az login or managed identity. AzureKeyCredential uses a plain API key from the .env file, which works anywhere. For production, prefer managed identity.
Q
What happens if the QAAgent on port 10001 is not running?
The lookup_policy_notes tool catches the connection error and falls back to a local policy memo dictionary. All three applicants can be validated without starting the Lesson 06 server.
Q
What causes an application to receive NEEDS_REVIEW instead of APPROVED?
NEEDS_REVIEW is emitted when all hard-rule checks pass but one or more soft-rule conditions cannot be automatically confirmed — typically requiring a human underwriter to verify physical documents or external programme approvals.
Q
How is cross-framework interoperability achieved?
The OrchestratorAgent is wrapped in A2AStarletteApplication. From the outside it responds to the same JSON-RPC messages and advertises via an Agent Card. Any A2A client can call it without Microsoft AF code.
