Multi-Agent A2A with the Agent Development Kit(ADK), Azure Fabric, and Gemini CLI

DEV Community

Multi Agent Design

The multi-agent deployment consists of 5 agents:

Researcher
Judge
Orchestrator
Content Builder
Course Builder

An overview of the multi-agent system can be found here:

Multi-Agent A2A with the Agent Development Kit(ADK), Cloud Run, Agent Skills, and Gemini CLI

Running/Testing/Debugging Locally

The main Makefile has been extended with extensive targets for managing the agents on the local development environment.

The key targets include:

✦ Here is the output of make help with the warnings resolved:
 1 Available commands:
 2 install - Install all dependencies for root, agents, and app
 3 install-fabric-cli - Install Microsoft Fabric CLI and Azure extension
 4 start - Start all services locally (alias for start-local)
 5 stop - Stop all local services (alias for stop-local)
 6 run - Start all services locally (alias for start-local)
 7 local - Show local service URLs
 8 status - Show status of local services and Fabric deployment
 9 start-local - Start all local services in background
 10 stop-local - Stop all local processes
 11 test - Run all tests (pytest)
 12 test-researcher - Test the Researcher agent directly
 13 test-judge - Test the Judge agent directly
 14 test-orchestrator - Test the Orchestrator logic
 15 lint - Run linting checks (ruff)
 16 deploy - Deploy stacked agents to Azure Container Apps & Fabric
 17 destroy - Delete Azure Resource Group and all resources
 18 endpoint - Show public service endpoint
 19 clean - Remove caches and logs

First check for local running agents:

xbill@penguin:~/gemini-cli-azure/multi-fabric$make status
make[1]: Entering directory '/home/xbill/gemini-cli-azure/multi-fabric'
Checking status of locally running servers...
--- Network Status ---
No services listening on expected ports (8080, 5173).
--- Process Status ---

Then all the agents can be started together:

xbill@penguin:~/gemini-cli-azure/multi-fabric$make start
Stopping any existing server processes...
Starting Unified App Backend in background...
Starting Frontend dev server in background...
All services started. Logs: backend.log, frontend.log
Frontend: http://localhost:5173
Backend: http://localhost:8080
make status
xbill@penguin:~/gemini-cli-azure/multi-fabric$make status
make[1]: Entering directory '/home/xbill/gemini-cli-azure/multi-fabric'
Checking status of locally running servers...
--- Network Status ---
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 19549/python3 
--- Process Status ---
xbill 19549 10.1 2.2 251904 147036 pts/1 S 22:34 0:05 /home/xbill/.pyenv/versions/3.13.13/bin/python3 -m unified_app.app

The entire project can be linted and tested as unit:

✦ I have completed the linting and formatting task for the project.
 Summary of Actions:
 - Initial Check: Ran ruff check . and identified 10 errors, including unused imports, unsorted imports, formatting
 issues, and multiple statements on one line.
 - Automated Fix: Executed ruff check . --fix, which automatically resolved 7 of the 10 errors.
 - Manual Fix: Manually corrected the remaining 3 E701 errors in unified_app/app.py by splitting multiple statements
 onto separate lines.
 - Verification: Verified all checks pass with a final ruff check . execution.
 All Python files are now compliant with the project's linting standards.
> make test
✦ I have executed make test for the project.
 Summary of Results:
 - Total Tests Collected: 29
 - Test Modules Run:
 - agents/content_builder/tests/test_agent.py (2 passed)
 - agents/judge/tests/test_agent.py (3 passed)
 - agents/orchestrator/test_orchestrator.py (5 passed)
 - agents/orchestrator/test_state_capturer.py (4 passed)
 - agents/researcher/tests/test_agent.py (2 passed)
 - app/tests/test_a2a_utils.py (2 passed)
 - app/tests/test_api.py (3 passed)
 - app/tests/test_auth.py (3 passed)
 - app/tests/test_logging_config.py (2 passed)
 - app/tests/test_utils.py (3 passed)
 Outcome: All 29 tests passed successfully. There were a couple of minor warnings related to deprecated modules inside
 third-party dependencies (authlib and google.adk), which are expected and do not affect the tests.

And end to end tested:

✦ I have successfully completed the linting and testing suite for the project.
 Results Overview:
 1. Linting (make lint): 
 - Resolved 10 issues using ruff. 
 - Automatically fixed 7 errors (imports/formatting).
 - Manually fixed 3 E701 errors in unified_app/app.py by splitting multiple statements into separate lines.
 - Final check: Passed.
 2. Unit & Integration Tests (make test):
 - Executed 29 tests across all microservices and the main application.
 - Result: All 29 tests passed.
 3. End-to-End Tests (make e2e-test):
 - Started the local unified backend and frontend servers.
 - Successfully executed the E2E pipeline for the topic: "Create a short course about the history of the internet".
 - The system correctly orchestrated the Researcher (gathering info), Judge (evaluating findings), and Content
 Builder (writing Markdown modules).
 - Result: Successfully generated a 5-module course.
 The local services have been stopped to clean up the environment. The codebase is now lint-free and verified as
 functionally correct.

And the entire agent system will run in the local environment:

Local Logging / Debugging

Gemini CLI has full access to the local agent logs for debugging and troubleshooting:

✦ The end-to-end test completed successfully! 
 The system ran the course creation pipeline ("Create a short course about the history of the internet"), executing the
 researcher, judge, and content builder agents, and successfully generated the final output without errors.

Deploying to Azure Fabric

The project level Makefile has targets for managing the Agent deployment to serverless endpoints:

A utility script check the deployment to Azure Fabric:

xbill@penguin:~/gemini-cli-azure/multi-fabric$make status
make[1]: Entering directory '/home/xbill/gemini-cli-azure/multi-fabric'
Checking status of locally running servers...
--- Network Status ---
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 20808/python3 
--- Process Status ---
xbill 20808 4.6 2.4 631760 160836 ? Sl 22:43 0:09 /home/xbill/.pyenv/versions/3.13.13/bin/python3 -m unified_app.app
make[1]: Leaving directory '/home/xbill/gemini-cli-azure/multi-fabric'
--- Azure Fabric / ACA Status ---
Checking Azure Container Apps status in adk-rg-fabric...
(ResourceGroupNotFound) Resource group 'adk-rg-fabric' could not be found.
make: *** [Makefile:124: status] Error 1

You can then deploy the services:

✓ Shell az account show -o table || echo "Not logged in to Azure" │
│ │
│ EnvironmentName HomeTenantId IsDefault Name State TenantDefaul │
│ tDomain TenantDisplayName TenantId │
│ ----------------- ------------------------------------ ----------- -------------------- ------- ------------ │
│ ------------------- ------------------- ------------------------------------ │
│ AzureCloud 40482c55-d00d-4c6d-8903-643d76a74b9c True Azure subscription 1 Enabled xbillglitnir │
│ com.onmicrosoft.com Default Directory 40482c55-d00d-4c6d-8903-643d76a74b9c │
✦ The deployment to Azure Container Apps (ACA) was successful!
 Deployment Summary:
 - Resource Group: adk-rg-fabric
 - Location: westus2
 - Container Registry: adkacrpenguin.azurecr.io
 - Public URL: https://course-creator.icysky-8598b612.westus2.azurecontainerapps.io
 (https://course-creator.icysky-8598b612.westus2.azurecontainerapps.io)
 Verification:
 I have verified that the remote service is healthy and the multi-agent pipeline is responding correctly. You can now
 use the public URL to access your AI Course Creator.
 Microsoft Fabric Integration:
 A WorkloadManifest.xml has been generated in the fabric/ directory. 
 To complete the Fabric integration:
 1. Register your backend App in Microsoft Entra ID.
 2. Add the Fabric.Extend scope.
 3. Upload fabric/WorkloadManifest.xml to the Fabric Admin Portal.
 Your system is now fully operational in the cloud!

Once the containers are deployed- you can then get the endpoint:

> make status
✦ Here is the current status of your environments:
 Local Services
 - Backend (unified_app): Running in the background (PID 20808) and listening on port 8080.
 - Frontend: Not currently running locally (you can start it with make start-local or make frontend-local).
 Azure Container Apps (Cloud Deployment)
 - Status: Succeeded (Running smoothly)
 - App FQDN: course-creator.icysky-8598b612.westus2.azurecontainerapps.io
 (https://course-creator.icysky-8598b612.westus2.azurecontainerapps.io)
 Both your local backend and your Azure cloud deployment are currently active and healthy.

And check the endpoint:

> make endpoint
✦ Here is your public Azure Container Apps endpoint:
 https://course-creator.icysky-8598b612.westus2.azurecontainerapps.io
 (https://course-creator.icysky-8598b612.westus2.azurecontainerapps.io)
 You can use this URL to access your deployed AI Course Creator.

The service will be visible in the Azure console:

Test End to End in Azure

The entire agent system is tested on the remote Azure endpoint:

✦ The E2E test against the cloud-deployed Azure Container Apps endpoint was successful!
 I have verified that your public cloud environment is fully functional and correctly orchestrating the multi-agent
 course creation pipeline.

Running the Web Interface

Start a connection to the Cloud Run deployed app:

https://course-creator.icysky-8598b612.westus2.azurecontainerapps.io

Then connect to the app :

Then use online course generator:

Final Gemini CLI Code Review

As a final step — Gemini CLI was used for a full code review of the project:

Overall Code Review Summary
After reviewing the app and agents directories, I can say this is an exceptionally well-engineered multi-agent system.
High-Level Architecture:
 The architecture is sophisticated and effective. The use of a main orchestrator to manage a pipeline of specialized agents (researcher, judge,
 content_builder) is a strong and scalable pattern. The inclusion of a research-and-refine loop with the judge agent is a standout feature that
 significantly enhances the quality of the final output.
Key Strengths:
 1. Expert ADK Usage: The project demonstrates a deep understanding of the Google ADK, using advanced features like SequentialAgent, LoopAgent,
 RemoteA2aAgent, structured Pydantic outputs, and agent callbacks to their full potential.
 2. Excellent Prompt Engineering: The instruction prompts for all agents are clear, specific, and well-crafted. This is the foundation of the
 system's success.
 3. Robust State Management: The custom StateCapturer agent is a brilliant, reusable utility that cleanly handles the flow of information between
 agents.
 4. Production-Ready Features: The system includes production-grade features like environment-aware authentication for service-to-service calls,
 robust error handling, and detailed logging.

Summary

The Agent Development Kit (ADK) was used to build a multi-agent system with A2A support using the Gemini Flash LLM Model. This application was tested locally with Gemini CLI and then deployed to Azure Fabric. Several key take-aways and lessons learned were summarized from debugging and testing the multi-agent system- including deep log reviews. Finally, Gemini CLI was used for a complete project code review.

Top comments (1)

peacebinflow profile image

PEACEBINFLOW

Founder of SAGEWORKS AI — building the Web4 layer where AI, blockchain & time flow as one. Creator of Mind’s Eye and BinFlow. Engineering the future of temporal, network-native intelligence.

Email

peacethabibinflow@proton.me
Location

BOTSWANA MAUN
Pronouns

he
Work

Founder & System Architect at SAGEWORKS AI
Joined

Oct 31, 2025

• May 4

The detail that stuck with me is the use of Gemini CLI not just as a coding assistant but as a full project reviewer at the end — linting, running the test suite, executing end-to-end tests, and producing a structured summary. It's a small shift in role but a meaningful one: the AI moves from being the thing that writes the code to being the thing that verifies it, sometimes in the same session.

That dual role creates an interesting tension. The same model that generated a function is later asked to judge whether the codebase is well-engineered. There's no external perspective — no fresh set of eyes that hasn't already been shaped by the same training distribution. In a human team, you wouldn't have the same person write the code and do the final review, because they'd carry the same blind spots into both tasks. But with an LLM, the review output sounds authoritative regardless, and the structure of the summary — "exceptionally well-engineered," "standout feature" — reads like a third-party assessment even though it isn't one.

I'm not suggesting the review was wrong or that the code isn't solid. But I do wonder whether the practice of using the same model for creation and verification will quietly erode the value of these reviews over time, or whether the structured nature of linting and test execution provides enough grounding to keep the review honest. Curious if you've tried running the same review prompt through a different model — Claude or GPT — and compared the assessments. That cross-model check might surface things a self-review never would.