Copied to Clipboard
Multi Agent Design
The multi-agent deployment consists of 5 agents:
- Researcher
- Judge
- Orchestrator
- Content Builder
- Course Builder
For a detailed analysis of the multi-agent architecture- this article provides the background information:
Multi-Agent A2A with the Agent Development Kit(ADK), Cloud Run, 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:
First check for local running agents:
xbill@penguin:~/gemini-cli-aws/multi-lambda$make status
Checking status of locally running agents and servers...
--- Network Status ---
No services listening on expected ports (8000-8004, 5173).
--- Process Status ---
No matching processes found.
Then all the agents can be started together:
✦ The frontend has been built and all local services (Researcher, Judge, Content Builder, Orchestrator, App Backend, and Frontend dev server) have
been started in the background.
- Frontend: [http://localhost:5173](http://localhost:5173) (http://localhost:5173)
- Backend: [http://localhost:8000](http://localhost:8000) (http://localhost:8000)
Logs for each service are available in the project root: researcher.log, judge.log, content_builder.log, orchestrator.log, backend.log, and
frontend.log.
Then connect to the front end locally:
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:
>review the local logs for the multi-agent run
✦ I will check run_local.sh and the project structure to determine where logs are stored or how they are generated.
This will verify the local operation of the code:
✦ The local logs confirm a successful multi-agent run for the topic "the history of the internet." Here is a summary of the execution flow:
* Orchestrator (orchestrator.log): Successfully managed the pipeline. It captured the topic, coordinated the Research-Judge loop, and escalated to
content generation after the first iteration.
* Researcher (researcher.log): Gathered approximately 9.2KB of research data using the google_search tool. It completed its task with a 200 OK
response.
* Judge (judge.log): Evaluated the findings and gave a "pass" status. The judge noted that the research was "comprehensive, accurate, and
well-structured," making it an "excellent foundation for educational content."
* Content Builder (content_builder.log): Successfully transformed the validated research into a structured Markdown course module and finished
execution.
* Backend & Frontend (backend.log, frontend.log): The FastAPI backend (port 8000) and Vite frontend (port 5173) are running and communicating with
the orchestrator as expected.
Notable Observation:
* A minor warning appeared in researcher.log: Researcher callback: 'response' not found or has no parts. However, this did not impact the
successful completion of the research or the overall pipeline.
All services are currently active and logged at the DEBUG level as specified in run_local.sh.
Deploying to Amazon Lambda
The project level Makefile has targets for managing the Agent deployment to serverless endpoints. You can submit the build for Lamba deployment:
xbill@penguin:~/gemini-cli-aws/multi-lambda$make deploy
chmod +x lambda/deploy-lambda.sh
./lambda/deploy-lambda.sh
Ensuring IAM role McpLambdaExecutionRole exists...
Logging in to Amazon ECR...
Once the containers are deployed- you can then get the endpoint:
xbill@penguin:~/gemini-cli-aws/multi-lambda$make endpoint
https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/
xbill@penguin:~/gemini-cli-aws/multi-lambda$make status
Course Creator Lambda Status:
-----------------------------------------------------
---------------------------------------------
| GetFunction |
+---------------------------------+---------+
| Name | Status |
+---------------------------------+---------+
| course-creator-course-builder | Active |
+---------------------------------+---------+
URL: https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/
-----------------------------------------------------
-------------------------------------------
| GetFunction |
+-------------------------------+---------+
| Name | Status |
+-------------------------------+---------+
| course-creator-orchestrator | Active |
+-------------------------------+---------+
URL: https://q5bciiujjktr6wris6tple6fra0yyrqc.lambda-url.us-east-1.on.aws/
-----------------------------------------------------
-----------------------------------------
| GetFunction |
+----------------------------+----------+
| Name | Status |
+----------------------------+----------+
| course-creator-researcher | Active |
+----------------------------+----------+
URL: https://gfhdoxhiiznflcz2cdhc65z2eq0cwimd.lambda-url.us-east-1.on.aws/
-----------------------------------------------------
------------------------------------
| GetFunction |
+-----------------------+----------+
| Name | Status |
+-----------------------+----------+
| course-creator-judge | Active |
+-----------------------+----------+
URL: https://kaen6rupkl5ph5kde2g6h7wgr40sirch.lambda-url.us-east-1.on.aws/
-----------------------------------------------------
----------------------------------------------
| GetFunction |
+----------------------------------+---------+
| Name | Status |
+----------------------------------+---------+
| course-creator-content-builder | Active |
+----------------------------------+---------+
URL: https://k5wt4o6vrdao3w4zjiabszdeue0kauxp.lambda-url.us-east-1.on.aws/
The service will be visible in the AWS console:
And the entire system can be tested:
xbill@penguin:~/gemini-cli-aws/multi-lambda$make e2e-test-lambda
Fetching Lambda endpoint...
make[1]: Entering directory '/home/xbill/gemini-cli-aws/multi-lambda'
Running end-to-end test against https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/...
Temporary JSON file content: {"message": "Create a short course about the history of the internet", "user_id": "e2e_test_user"}
Executing: curl -s -X POST https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/api/chat_stream -H "Content-Type: application/json" -d @/tmp/tmp.vmxl0Dsf88 --no-buffer
{"type": "progress", "text": "\ud83d\ude80 Connected to backend, starting research..."}
{"type": "progress", "text": "\ud83d\ude80 Starting the course creation pipeline..."}
{"type": "progress", "text": "\ud83d\udd0d Research is starting..."}
{"type": "progress", "text": "\ud83d\udd0d Researcher is gathering information..."}
{"type": "progress", "text": "\u2696\ufe0f Judge is evaluating findings..."}
{"type": "progress", "text": "\u2696\ufe0f Judge is evaluating findings..."}
{"type": "progress", "text": "\u270d\ufe0f Building the final course content..."}
Running the Web Interface
Start a connection to the deployed app:
https://wqv5reqmno6skv3xsqb64kgrsm0hletn.lambda-url.us-east-1.on.aws/
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:
✦ The multi-lambda project is a well-engineered, distributed multi-agent system that effectively leverages the
Google Agent Development Kit (ADK) and the A2A protocol within an AWS Lambda environment. The architecture is
modular, resilient, and optimized for streaming AI interactions.
Key Strengths
* Robust Orchestration: The use of SequentialAgent and LoopAgent in agents/orchestrator/agent.py creates a
sophisticated Research-Judge pipeline. Custom components like StateCapturer and EscalationChecker provide
fine-grained control over the agent loop and state persistence.
* Infrastructure-Aware A2A: The middleware in shared/a2a_utils.py dynamically rewrites agent card URLs based on
x-forwarded-* headers, a critical feature for services running behind proxies or as Lambda Function URLs.
* Intelligent Agent Callbacks: Each sub-agent (researcher, judge, content_builder) utilizes
before_agent_callback to sanitize inputs and recover topics/findings from session history. This makes the
agents highly resilient to the "noise" of accumulated conversation history.
* Unified Deployment: The project employs a single Docker image (using the aws-lambda-adapter) for all
services. The deploy-lambda.sh script automates the complex task of deploying five distinct services,
managing their Function URLs, and wiring them together via environment variables.
* Modern Python Stack: The use of Python 3.13 and uvicorn ensures high performance, while the gateway's
merge_strings logic gracefully handles the complexities of streaming deduplication.
Observations & Recommendations
* Session Persistence: Currently, the system appears to use ADK's default in-memory session storage. In a
Lambda environment, sessions may be lost across cold starts or scaling events. For production use,
integrating a persistent session store (e.g., DynamoDB or Redis) via the session_service_uri option is
recommended.
* Security: Inter-agent communication currently bypasses IAM authentication (using NONE auth type) and relies
on the authenticated_httpx.py bypass logic. While acceptable for a demo, production environments should
leverage AWS IAM or Google Identity Tokens for service-to-service authorization.
* State Management: The orchestrator's StateCapturer effectively "syncs" findings from the event stream into
the session state. This is a clever approach to distributed state management, ensuring the Orchestrator
remains the source of truth even when sub-agents are remote.
Overall, this is a sophisticated implementation that successfully bridges Google's AI agent framework with AWS's
serverless infrastructure.
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 AWS Lambda. Finally, Gemini CLI was used for a complete project code review.