DEV Community: Jonathan Huang

Google Agent Development Kit (ADK) Introduction (7): Monitoring

Jonathan Huang — Tue, 20 May 2025 09:23:15 +0000

Application Monitoring & Visualization

Direct Prometheus integration with Cloud Run can be intricate due to its serverless architecture. Google Cloud offers Managed Service for Prometheus (GMP) using a sidecar for streamlined metric collection. However, for maximum simplicity and deep Google Cloud integration, native monitoring tools are the primary path.

Collecting Application Metrics (via Cloud Monitoring)

Option A: Structured Logging & Log-based Metrics (Most Direct)

Output structured (JSON) logs directly to stdout in your Streamlit app.
Cloud Run automatically forwards stdout/stderr to Cloud Logging; JSON strings printed to stdout are parsed as jsonPayload. This is the simplest mechanism.

Sample code snippet:

import json
import time # For realistic duration

# Example: In your Streamlit application code
def some_function_processing_a_task(task_type, success, duration_ms_value):
    log_data = {
        "message": f"Processed task: {task_type}",
        "task_type": task_type,
        "duration_ms": duration_ms_value,
        "success": success,
        # Severity is often inferred by Cloud Logging (stdout=INFO, stderr=ERROR).
        # Explicitly add "severity": "INFO" or "ERROR" if precise control is needed
        # for filtering or log-based metrics derived from severity.
    }
    # Print JSON to stdout; Cloud Run forwards this to Cloud Logging.
    # Cloud Logging will parse this into jsonPayload.
    print(json.dumps(log_data))

# Example usage:
# start_time = time.monotonic()
# # ... processing logic ...
# success_status = True # or False
# duration = (time.monotonic() - start_time) * 1000
# some_function_processing_a_task("schedule_meeting", success_status, int(duration))

In Cloud Monitoring, create log-based metrics:
Navigate: Google Cloud Console → Logging → Log-based Metrics → Create Metric.
Choose Metric Type: Counter (for occurrences) or Distribution (for values like latency).
Define Filter to isolate relevant logs, e.g.:

resource.type="cloud_run_revision"
resource.labels.service_name="meeting-workflow-agent"
jsonPayload.task_type="schedule_meeting"

Specify Field Name (for Distribution, e.g., jsonPayload.duration_ms), units (e.g., ms), and labels for drill-down.

Option B: Using Cloud Monitoring API (Maximum Flexibility, More Code)

Add google-cloud-monitoring to your requirements.txt.
Utilize google.cloud.monitoring_v3 to programmatically write custom metrics. This offers granular control.

Sample code:

from google.cloud import monitoring_v3
import time
import os

project_id = "adk-learning-journey" # Ensure this is configured or dynamically fetched
client = monitoring_v3.MetricServiceClient()
project_name = f"projects/{project_id}"

def write_custom_metric(metric_type, value, labels=None):
    series = monitoring_v3.types.TimeSeries()
    series.metric.type = f"custom.googleapis.com/{metric_type}" # Standard prefix for custom metrics
    series.resource.type = "cloud_run_revision"
    # These labels are crucial for associating the metric with the correct Cloud Run resource
    series.resource.labels["service_name"] = os.environ.get("K_SERVICE", "unknown") # K_SERVICE is the Cloud Run service name
    series.resource.labels["revision_name"] = os.environ.get("K_REVISION", "unknown") # K_REVISION is the specific revision
    series.resource.labels["configuration_name"] = os.environ.get("K_CONFIGURATION", "unknown") # K_CONFIGURATION is the configuration name

    if labels:
        for k, v in labels.items():
            series.metric.labels[k] = str(v) # Metric labels must be strings

    point = monitoring_v3.types.Point()
    # Ensure value is appropriate type (int64_value, double_value, etc.)
    if isinstance(value, int):
        point.value.int64_value = value
    elif isinstance(value, float):
        point.value.double_value = value
    else:
        # Handle other types or raise error, e.g. for Distribution for complex types
        # For simplicity, this example assumes int or float.
        point.value.int64_value = int(value) 


    now_ts = time.time()
    point.interval.end_time.seconds = int(now_ts)
    point.interval.end_time.nanos = int((now_ts - point.interval.end_time.seconds) * 10**9)

    series.points.append(point)

    # Call the API to create the time series
    try:
        client.create_time_series(name=project_name, time_series=[series])
    except Exception as e:
        # Implement proper error handling/logging for production
        print(f"Error writing custom metric {metric_type}: {e}", file=sys.stderr)


# Example usage:
# write_custom_metric("streamlit/successful_meetings", 1, {"agent_type": "manager"})
# write_custom_metric("streamlit/processing_latency_ms", 150.5, {"task_category": "report_generation"})

Set Up Grafana

Deploy Grafana:
- Option 1 (Recommended for GKE/GCE): Deploy via Google Cloud Marketplace if operating within these environments.
- Option 2: Install Grafana in your designated environment.
Connect Grafana to Google Cloud Monitoring:
- Access Grafana.
- Navigate: Configuration → Data Sources → Add data source.
- Select "Google Cloud Monitoring".
- Authentication:
  - If Grafana runs on GCE/GKE, leverage the attached service account (grant roles/monitoring.viewer).
  - Otherwise, create a service account, assign roles/monitoring.viewer, download its JSON key, and upload to Grafana.
- Set Default Project: adk-learning-journey.
- Save & Test. A successful test validates the connection.

Create Grafana Dashboards

Create → Dashboard → Add new panel.
Query Configuration:
- Select the "Google Cloud Monitoring" data source.
- Service: Choose "Cloud Run" for standard metrics or "Custom Metrics" for your defined metrics.
- Metric: Select your log-based metric, standard Cloud Run metrics (e.g., Request Count, Latency, Instance Count), or your custom metric name (e.g., custom.googleapis.com/streamlit/request_count).
- Utilize the query editor to filter and aggregate data (e.g., by resource.labels.service_name, resource.labels.revision_name, or custom metric labels).
Visualization: Choose the optimal chart type for the data.
Alerting: Configure alert rules in Grafana for critical metrics to ensure operational awareness.

Cost Control & Optimization

Monitor Costs: Regularly audit Google Cloud Billing reports. Filter by service (Cloud Run, Secret Manager, Logging, Monitoring) for granular insight.
Set Budget Alerts: Implement budget alerts in Billing for proactive cost management.
Optimize Cloud Run Settings:
- Tune CPU, memory, and min/max instances based on observed performance data from Grafana/Cloud Monitoring.
- Employ --min-instances 0 for services with intermittent traffic to minimize idle costs.
Logging & Monitoring Costs:
- Be aware: Logging ingestion, storage, and Monitoring (especially custom metrics & API calls) have associated costs.
- Reduce log ingestion costs by setting appropriate application log levels at the source. Log-based metric filters refine insights from ingested logs; they do not reduce the initial volume of logs stored.
- For custom metrics, govern write frequency to balance granularity with cost.
Secret Manager Costs: Costs are driven by the number of secrets and access frequency. Reading secrets primarily at application startup minimizes these operational costs.

Google Agent Development Kit (ADK) Introduction (6): Deploy to Google Cloud

Jonathan Huang — Tue, 20 May 2025 09:19:19 +0000

Learning Objectives

Master container deployment and autoscaling on Google Cloud Run, including secure key management.
Implement performance monitoring and cost control using Cloud Monitoring and Grafana.

Task Overview

Application Containerization: Package the Streamlit Agent as a Docker image, manage credentials.json/token.json securely with Secret Manager, and deploy to Cloud Run.
Performance Monitoring: Set up Cloud Monitoring and Grafana.
Environment Setup: Install Google Cloud SDK and handle Docker image authentication.

Prerequisites: Install and Configure Google Cloud SDK

Install following the official documentation.
macOS (Homebrew): brew install --cask google-cloud-sdk
Initialize: gcloud init (sign in, set or create a project, e.g. adk-learning-journey)
Set project: gcloud config set project adk-learning-journey
Docker auth: gcloud auth configure-docker
Enable required APIs:

  gcloud services enable secretmanager.googleapis.com \
      artifactregistry.googleapis.com \
      run.googleapis.com \
      iam.googleapis.com \
      cloudbuild.googleapis.com \
      logging.googleapis.com \
      monitoring.googleapis.com
  # If additional APIs are needed (e.g. Calendar, Gemini), enable them as well
  # gcloud services enable calendar-json.googleapis.com
  # gcloud services enable generativelanguage.googleapis.com

Deployment Steps (Detailed)

1. Prepare Application and Security Config

requirements.txt: Make sure all required packages are included (such as google-cloud-secret-manager, etc).
Sensitive Files: Never include credentials.json or token.json in your Git repo or Docker image. Add them to .gitignore.

Using Secret Manager

A. Upload credentials.json

gcloud secrets create calendar-credentials \
    --project="adk-learning-journey" \
    --replication-policy="automatic" \
    --description="OAuth client credentials for Google Calendar API"
gcloud secrets versions add calendar-credentials \
    --project="adk-learning-journey" \
    --data-file="path/to/credentials.json"

B. Upload token.json

gcloud secrets create calendar-token \
    --project="adk-learning-journey" \
    --replication-policy="automatic" \
    --description="User OAuth token for Google Calendar API"
gcloud secrets versions add calendar-token \
    --project="adk-learning-journey" \
    --data-file="path/to/token.json"

C. Modify your application to read from Secret Manager
Your code should load credentials.json and token.json from Secret Manager (see example).

2. Docker Packaging

Sample Dockerfile (key points):

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8080
ENV PYTHONUNBUFFERED 1
ENV GOOGLE_CLOUD_PROJECT "adk-learning-journey"
ENV PORT 8080
CMD streamlit run streamlit_app.py --server.port $PORT --server.address 0.0.0.0

Tip: Use --set-env-vars during Cloud Run deployment to override the project ID for portability.

3. Build & Test Docker Image

docker build -t $IMAGE_URI .
docker run -p 8080:8080 \
  -e GOOGLE_CLOUD_PROJECT="adk-learning-journey" \
  -e PORT="8080" \
  $IMAGE_URI
# Verify local access via http://localhost:8080

4. Push Image to Artifact Registry (or GCR)

Create repository (if not already created):

  gcloud artifacts repositories create $REPO \
    --project="adk-learning-journey" \
    --repository-format=docker \
    --location=$REGION

Push:

  docker push $IMAGE_URI

5. Deploy to Cloud Run

A. Create Service Account (SA):

gcloud iam service-accounts create meeting-workflow \
  --project="adk-learning-journey" \
  --description="Service account for Meeting Workflow Streamlit Agent" \
  --display-name="Meeting Workflow"

B. Grant Secret Manager access to SA:

gcloud projects add-iam-policy-binding adk-learning-journey \
  --member="serviceAccount:meeting-workflow@adk-learning-journey.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

C. Deploy to Cloud Run:

gcloud run deploy meeting-scheduler \
  --image gcr.io/adk-learning-journey/meeting-workflow \
  --platform managed \
  --service-account meeting-workflow@adk-learning-journey.iam.gserviceaccount.com \
  --set-env-vars="GOOGLE_CLOUD_PROJECT=adk-learning-journey"

6. Validate Deployment

After deployment, open the Cloud Run URL provided by gcloud in your browser to test your service.
In Google Cloud Console > Cloud Run > select your service > Logs, check for errors (env vars, secret access, app startup, etc).

Google Agent Development Kit (ADK) Introduction (5): Developer Mindset

Jonathan Huang — Fri, 16 May 2025 01:43:54 +0000

Conceptual Comparison: Developer Mindset, Responsibility Separation, and Task Decomposition

Building on the previous article, this one will explore the shift in developers' mindset when transitioning from API development to A2A development.

Developer Mindset Shift: Function-Oriented vs. Agent-Oriented. Traditional development often involves thinking in terms of functions or API call sequences: starting from input, invoking services step-by-step, and finally producing output. Developers act as "orchestrators," controlling every step. In contrast, agent-oriented architecture requires a new mindset—designing a community of agents, each responsible for a subtask and interacting via messages and protocols. Instead of scripting flows directly, developers configure systems of autonomous agents, each with its own goal. Since agents make decisions independently (via LLMs), developers must shift from controlling every detail to setting up high-level rules and supervision.

Responsibility Separation and Task Decomposition. In monolithic models, task decomposition happens at the code level—breaking big functions into smaller ones or chaining API calls. But the entire task remains owned by a single system component. Agent-based architectures promote system-level separation of responsibilities, assigning different subtasks to specialized agents. For example, in the meeting_workflow project, the workflow is split into three agents: one for input validation (email format), one for Google Calendar scheduling, and one for sending notifications. Each agent does what it's best at, and a sequential agent links them. This clear boundary improves maintainability and debuggability. In a traditional model, the same process would likely be a single script chaining everything, with tightly coupled logic that hinders reuse or evolution.

This kind of agent-based decomposition is similar to team collaboration: breaking a big goal into professional subtasks executed by different roles. The multi_agent_pm project demonstrates this: Manager, Engineering, and QA/Test agents work together. The manager plans and assigns tasks, the engineering agent executes them, and QA ensures quality. With A2A, they coordinate like a real team. Each agent keeps context within its domain, avoiding the confusion of a single model tracking everything. Adding new roles (e.g., a design agent) is simple—just define its role and connections.

Ultimately, the big shift is this: from commanding computers to enabling agent collaboration. Developers need to think at a higher level—turning hardcoded flows into agent-to-agent protocols. It also requires accepting partial autonomy of agents and trusting them to complete subtasks and return results. This shift takes practice, but it enables more flexible and intelligent systems.

Transitioning Your Developer Mindset (Function-Oriented → Agent-Oriented)

To adopt these new paradigms, engineers must adjust both mindset and skills. As some have put it, "MCP is just the prelude—ADK and A2A are the beginning of the Agent era." Here's how to make that transition:

Think Like an Architect: Break problems down into agent roles instead of steps in a script. Ask: what subtasks exist? What kind of agents should own each one? For example, a support system might include an analyzer agent, a retriever agent, and a responder agent—not a monolithic chain.
Learn the New Tools and Protocols: Study ADK, A2A, and MCP. Understand how to create tools, define agent metadata files (like .well-known/agent.json), and integrate MCP services. Start small and build confidence.
Shift Design Philosophy: Move from OOP or functional programming to models like Actor systems or Microservices. Each agent is like a self-contained actor with its own state, communicating via protocols. Focus on defining interfaces and message contracts—not just function inputs/outputs.
Plan for Asynchrony and Uncertainty: Agent interactions are often async and non-deterministic. Responses may be delayed or require multiple exchanges. Agents may misunderstand or misbehave due to model randomness. Plan for retries, validations, and human-in-the-loop steps where needed.
Migrate Gradually: Don’t overhaul everything. Start by refactoring one sub-feature into a mini-agent workflow or building a multi-agent demo. Limit the number of agents initially. Reflect after each iteration—what got better? What got more complex? Adjust accordingly.

In summary, transitioning to agent-oriented development means evolving from micro-managing logic to coordinating intelligent actors. Developers must expand their skills to cover LLMs, natural language, and distributed architecture. Early adopters of this shift will be well-positioned for the next wave of AI software.

Summary and Application Suggestions

Key Difference: Google ADK + A2A enables highly modular, scalable agent collaboration, while MCP/traditional APIs rely on centralized, sequential flows. ADK/A2A breaks complexity into autonomous parts and uses open protocols for communication. Monolithic models are fine for static, predictable tasks but struggle with complexity or dynamic coordination.

Best Use Cases: If your app has multi-step workflows, cross-functional collaboration, or dynamic logic, use agent-based design. For example, internal enterprise assistants that interact with marketing, support, and analytics systems benefit from splitting tasks among specialized agents. ADK tools and A2A protocols simplify building and scaling this setup. For simple, one-off tasks (e.g., checking the weather), traditional API calls or function calling may be enough.

Note: ADK and MCP are not mutually exclusive—you can combine them. Agents built in ADK can call external MCP tools. Future AI systems may involve agents that collaborate (via A2A) and invoke tools (via MCP). Learning both gives you an edge.

In short, ADK and A2A represent a shift in developer thinking—not just toolkits, but a whole new mental model. This article aims to highlight that shift. Try it in your projects, validate it in small scopes, and once you're ready, you'll be capable of building smarter, more autonomous, and extensible AI systems ready for what’s next.

In the upcoming chapter, I want to learn the process of deploying an Agent to Google Cloud Run, containerizing it, and setting up monitoring.

Google Agent Development Kit (ADK) Introduction (4): Google ADK and A2A vs MCP and Traditional APIs

Jonathan Huang — Thu, 15 May 2025 02:45:10 +0000

At this stage in my learning, I've paused to reconsider the development differences between the A2A model and the MCP/traditional API models based on experiences from several projects above.

Core Architecture and Development of Google ADK and Agent-to-Agent (A2A)

In 2025, Google launched the Agent Development Kit (ADK), an open-source Python toolkit aimed at simplifying AI agent development. ADK emphasizes modularity and flexibility, allowing developers to build agents with memory, tool access, and coordination features. It integrates well with Google services (e.g., Vertex AI, Gemini) but also supports external models and tools.

The Agent-to-Agent (A2A) protocol, also by Google, standardizes communication between agents. Each agent exposes a /run endpoint and metadata, enabling other agents or systems to send requests and receive responses. A2A solves the interoperability issue among agents from different platforms—acting like a "diplomatic hotline" for direct collaboration.

In ADK, every agent supports A2A by default, making integration seamless. Developers can compose agents into sequential, parallel, or hierarchical workflows. For example, SequentialAgent handles ordered execution of sub-agents. Simple use cases may use a single multi-tool agent (e.g., multi_tool_agent), while complex flows (e.g., meeting_workflow, multi_agent_pm) coordinate multiple agents to achieve their goals efficiently.

Typical Processes of MCP Architecture and Traditional API Calls

The Model Context Protocol (MCP) introduced by Anthropic in 2024 is an open standard often described as the "USB-C interface" of the AI industry. It standardizes how large language models (LLMs) connect with external tools/data sources. MCP specifies how agents (or models) invoke external resources such as database queries, web services, or software APIs through standardized interfaces. In other words, MCP standardizes previously fragmented API integration methods, making interactions between AI agents and software services more consistent. Using MCP, an AI assistant-type agent can conveniently call various tools that implement MCP interfaces—such as querying databases, reading files, or performing web searches—without redesigning communication methods for each new tool.

Typically, MCP-based architectures adopt a "monolithic command mode" to organize application logic. "Monolithic" means primary logic controlled by a central agent (or application), while the command mode refers to the agent sequentially issuing tool invocation commands as needed to complete subtasks. For example, without multi-agent collaboration, a chatbot arranging travel might internally execute: "input validation → flight API call → hotel API call → integrate results → respond to user". This entire process is orchestrated by a single agent or program, directly invoking external APIs and handling responses traditionally. Developers must manually code the logic for each API call, including parameter preparation, error handling, and result parsing. The key characteristic of traditional API call models is that developers fully control workflow details, explicitly executing each step via function calls or HTTP requests.

When employing traditional methods to enable AI models to use tools, two typical approaches emerge: one is similar to OpenAI Function Calling, where models reference predefined functions in conversation, intercepted and executed by external code; the other involves developers explicitly coding sequential logic within applications, feeding model responses at appropriate times. Both methods essentially directly connect models and functional modules via code. Due to the lack of standardization, integration methods between different tools vary significantly, and developers' mental models remain largely function-oriented—viewing AI primarily as an initiator of various library or API calls, with themselves acting as orchestrators arranging linear execution sequences. This approach works well for straightforward tasks but can cause code to become difficult to maintain and scale as complexity grows.

Notably, MCP protocols somewhat enhance the traditional model by allowing some tool integrations to be managed by standardized MCP tool servers. Advanced AI models like Claude can now invoke external knowledge bases or execute programs via MCP interfaces. However, even with MCP, architectures dominated by a single central agent remain monolithic: a single intelligent entity sequentially connects multiple tools. Although MCP creates more consistent interfaces between agents and tools, the overall development process remains traditional, following a "plan → invoke → control results" pattern. Developers must manually dissect complex tasks into steps and code the logic themselves. In short, MCP offers standardized tool integration, enhancing agent interactions with external resources, whereas A2A/ADK introduces an agent collaboration architecture, fundamentally shifting how we organize program logic. Below, I will further detail the technical and conceptual differences between these approaches.

Technical Comparison: Modularity, State Management, Workflow Control, etc.

The following table compares ADK/A2A multi-agent mode with MCP/traditional API monolithic mode across critical dimensions from a technical perspective:

Aspect	ADK/A2A Development Mode	MCP/Traditional API Mode
Modularity	Highly modular: Systems composed of multiple specialized Agents cooperating via standardized interfaces, with clear responsibilities.	Low modularity: Typically a single application or agent handling all functions, connected via function calls, with blurred responsibility boundaries and high coupling.
State Management	Built-in state management: Framework provides session memory and context management (e.g., ADK's Session Service), allowing agents easy access to shared information.	Manual state management: Developers manually maintain context within programs or rely on models' prompt memory, lacking a unified strategy, often causing synchronization issues.
Workflow Control	Flexible workflow control: Supports sequential, parallel, hierarchical execution, using built-in scheduling mechanisms such as SequentialAgent to organize multi-step tasks.	Linear procedural flow: Developers hard-code execution sequences and logic manually, lacking high-level abstraction, leading to complex and tangled workflows.
Error Handling	Granular error handling: Frameworks like ADK provide middleware for centralized management of tool errors, retry strategies, fallback plans, enhancing reliability.	Manual error handling: Developers must individually handle each API call error (e.g., try/except), without centralized control. Inconsistent error handling across modules increases complexity.
Scalability	Easy expansion: Easily expand functionality by adding Agents or Tools, with standardized interfaces minimally impacting existing systems, akin to adding microservices.	Difficult expansion: Monolithic architectures require widespread code modifications when adding new features, becoming unwieldy and costly to maintain as complexity grows.

(Note: MCP and traditional API methods are grouped as one due to similar single-agent structures, despite differences in standardization.)

Summary

The comparison clearly shows that ADK/A2A's multi-agent architecture excels in terms of system cohesion and loose coupling. Developers can construct AI agents akin to microservices, communicating via standardized protocols, each focused clearly on their responsibilities without interfering with others. Conversely, traditional monolithic models entangle functional components tightly within a single process, limiting flexibility and scalability. Modifications typically affect entire workflows significantly. Writing up to this point, the length is getting a bit too long. Next, I will look at how this transition affects the daily development of engineers from the perspective of the developer's mental model and task division.

This article references Simon Liu's introduction to ADK/MCP/A2A and Koyeb's technical blog analysis of the A2A and MCP protocols. The content may contain misunderstandings, but I have done my best to understand and complete this article.

It is worth noting that since these technologies are relatively new (all launched between the end of 2024 and the beginning of 2025), some details may still be under development, especially since the version of the A2A protocol is only 0.1.0, indicating that it may still be in its early stages. As these technologies mature and see wider adoption, more features and best practices may emerge in the future.

Google Agent Development Kit (ADK) Introduction (3): Building a Multi-Agent Project Management System

Jonathan Huang — Wed, 14 May 2025 06:12:13 +0000

Learning Objectives

Master Layered Agent Architecture: Learn how to design and implement a hierarchical agent system for real-world collaboration.
Implement Task Delegation and Coordination: See how agents can assign, accept, and complete tasks collaboratively.
Build Dynamic Load Balancing: Ensure optimal workload distribution among agents to maximize efficiency.
Technical Breadth: Compare agent-based project management with traditional monolithic approaches.

System Architecture and Project Structure

This project uses the Google ADK (Agent Development Kit) to build a multi-agent project management system, simulating a real-world team with three specialized agent types:

Manager Agent: Oversees the project, assigns tasks, and reviews progress.
Engineer Agents: Implement assigned tasks and report their status.
Tester Agents: Test completed tasks and provide feedback.

These agents are coordinated by a workflow engine, forming a complete project management workflow.

multi_agent_pm/
├── __init__.py
├── __main__.py         # Entry point for running as a module
├── main.py             # Main system implementation
├── common.py           # Shared data models and utilities
├── ai/                 # Natural language processing with Gemini
│   ├── __init__.py
│   ├── agent_nlp_handler.py
│   └── gemini_client.py
├── agents/             # Agent implementations
│   ├── __init__.py
│   ├── engineer/
│   ├── manager/
│   └── tester/
├── workflow/           # Workflow coordination
│   ├── __init__.py
│   └── coordinator.py
└── requirements.txt    # Project dependencies

Agent Implementation and Collaboration

Manager Agent

Assigns tasks to engineers based on workload.
Reviews completed and tested tasks.
Monitors overall project progress.

Engineer Agents

Accept and work on assigned tasks.
Mark tasks as completed when done.
Communicate progress and issues.

Tester Agents

Pick up completed tasks for testing.
Submit test results and feedback.
Help ensure quality before final approval.

Each agent exposes a REST API (as defined in their .well-known/agent.json manifest) and can also be interacted with via natural language commands, thanks to Gemini AI integration.

Dynamic Load Balancing

The system features an automatic load balancing mechanism:

Monitor Agent Workloads: Regularly checks each agent’s task queue.
Redistribute Tasks: Moves tasks from overloaded agents to those with spare capacity.
Adapt to Change: Handles new tasks, agent failures, and shifting priorities in real time.

This ensures that no single agent becomes a bottleneck, and the project progresses smoothly.

Natural Language Understanding

With Google Gemini integration, you can interact with the system using plain English:

“Create a new high-priority task for payment integration.”
“Show me all tasks assigned to engineers.”
“Reassign the authentication task to Engineer2.”

Gemini parses these commands, extracts intent and parameters, and routes them to the appropriate agent and API.

A2A Protocol and Agent Manifests

Each agent follows the Agent-to-Agent (A2A) protocol:

Manifest File: .well-known/agent.json describes each agent’s capabilities, API endpoints, and schemas.
Standardized Communication: Ensures agents can discover and interact with each other seamlessly.
Extensibility: New agent types can be added by defining their manifest and implementing the required APIs.

How to Run This Project

1. Install dependencies:

pip install -r requirements.txt

2. Set up Gemini (optional, for NLU):

Get your API key from Google AI Studio
Add it to a .env file:

  GEMINI_API_KEY=your_api_key_here

3. Run the system:

python -m multi_agent_pm

4. Interact via CLI or REST API:

Use natural language commands in the CLI.
Or, send HTTP requests to the agent endpoints (see README for details).

What You’ll Learn

Agent System Design: How to break down complex workflows into specialized, cooperating agents.
Task Delegation and Coordination: Implementing real-world project management logic in code.
Dynamic Load Balancing: Keeping your system efficient and responsive.
Natural Language Integration: Making your system user-friendly and AI-powered. (Actually, this part wasn't done very well, let's talk about it later.)
ADK Best Practices: Using manifests and protocols for scalable, maintainable agent systems.

Conclusion

Building a multi-agent project management system with Google ADK is a powerful way to learn about modern, distributed, and intelligent software architecture.

You’ll gain hands-on experience with agent design, coordination, and AI integration—skills that are increasingly valuable in today’s tech landscape.

For complete code and examples, see the GitHub repository.

Google Agent Development Kit (ADK) Introduction (2): Building a Multi-Agent Meeting Scheduling System

Jonathan Huang — Mon, 12 May 2025 15:03:16 +0000

Learning Objectives

Master Tool Development and Integration Patterns: Learn how to design, implement, and integrate multiple tools within a multi-agent architecture.
Implement Complex Task Decomposition and Execution: Break down complex tasks like meeting scheduling into multiple steps, executed collaboratively by different agents.
API Permission Management and Error Handling: Understand Google Calendar API permission application, token management, and common error handling strategies.
Technical Breadth: Compare Google ADK with OpenAI Function Calling for multi-step task planning.

System Architecture and Project Structure

This project uses the Google ADK (Agent Development Kit) multi-agent architecture, breaking the meeting scheduling process into three specialized agents:

Validator Agent: Validates attendee email formats
Scheduler Agent: Integrates with Google Calendar API, responsible for scheduling and conflict detection
Notifier Agent: Generates and sends meeting notifications

These three agents are connected via SequentialAgent, forming a complete multi-step workflow.

meeting_workflow/
├── meeting_workflow_adk.py  # Main ADK implementation
├── streamlit_app.py         # Web interface
├── common/                  # Shared utilities
│   └── google_auth.py       # Google authentication functionality
├── agents/                  # Agent configurations
│   └── .../.well-known/agent.json
├── requirements.txt         # Dependencies
└── README.md                # Project documentation

Tool Development and Integration

Tool Implementation

Each agent’s core capability is implemented as a Tool, inheriting from BaseTool and implementing the execute method.

Example: Email Validation Tool

class ValidateAttendeesTool(BaseTool):
    def execute(self, context, attendees: list):
        invalid_emails = [email for email in attendees if '@' not in email or '.' not in email]
        if invalid_emails:
            return {"valid": False, "invalid_emails": invalid_emails}
        return {"valid": True}

Example: Meeting Scheduling Tool (Google Calendar Integration)

class ScheduleMeetingTool(BaseTool):
    def execute(self, context, summary, start_time, duration_min, attendees, description=None):
        # 1. Get Google Calendar credentials
        service = get_calendar_service()
        # 2. Check for time conflicts
        # 3. If no conflicts, create the meeting event
        # 4. Return the result

Example: Notification Tool

class SendMeetingNotificationTool(BaseTool):
    def execute(self, context, event_id, summary, start_time, duration_min, attendees, description=None):
        # Generate notification content; can be integrated with Email/Line/Slack, etc.
        return {"status": "success", "message": "Notification sent"}

Integrating Tools into Agents

Each Agent is built around its tools and can be given an instruction:

validate_agent = Agent(
    name="attendee_validator",
    model="gemini-pro",
    tools=[ValidateAttendeesTool()],
    instruction="Validate meeting attendee email formats"
)

Multi-Step Task Planning (Workflow)

Use SequentialAgent to connect the three agents, forming a multi-step workflow:

meeting_workflow = SequentialAgent(
    name="meeting_workflow",
    sub_agents=[validate_agent, scheduling_agent, notification_agent],
    instruction="Complete meeting scheduling workflow"
)

The main process process_meeting_request will:

Validate email formats
Attempt to schedule the meeting (if conflicts, return suggested times)
Send meeting notifications

Google Calendar API Permission Management and Error Handling

Permissions and Token Management

You must first create a project in Google Cloud Console, enable the Calendar API, set up OAuth, and download credentials.json.
On first run, token.json is generated automatically and refreshed as needed.

def get_calendar_service():
    if os.path.exists('token.json'):
        creds = Credentials.from_authorized_user_file('token.json', SCOPES)
    # ... If not, guide through OAuth flow ...
    return build('calendar', 'v3', credentials=creds)

Error Handling

Email format errors, API errors, time conflicts, and network issues are all clearly reported.
All exceptions are logged for easy debugging.

try:
    # Google Calendar API operations
except HttpError as error:
    logger.error(f"Calendar API error: {error}")
    return {"status": "error", "message": f"API Error: {str(error)}"}

Web Interface (Streamlit)

A simple web interface is provided for users to enter meeting information and instantly see scheduling results and conflict suggestions.

# streamlit_app.py
summary = st.text_input("Meeting Subject", "Product Development Discussion")
meeting_date = st.date_input("Meeting Date", ...)
meeting_time = st.time_input("Meeting Time", ...)
# ... On submit, call process_meeting_request ...

Comparison with OpenAI Function Calling

Item	Google ADK Multi-Agent/Tool	OpenAI Function Calling
Multi-step Task Flow	Supports SequentialAgent	Must design multi-step logic manually
Tool Integration	Register as Tool class	Register as function schema
Permission & API Mgmt	Handle OAuth yourself	Handled by external code
Error Handling	Customizable granularity	Must wrap yourself
Multi-Agent Workflow	Built-in sub-agent support	Must decompose manually

Conclusion:

Google ADK is suitable for applications requiring multi-agent collaboration and complex task decomposition, with clear Tool/Agent concepts. OpenAI Function Calling is suitable for single-step, single-model-driven tasks; complex workflows must be designed manually.

Certainly! Here’s the revised conclusion section, now including clear instructions on how to execute the Python app from both the command line and the web interface:

Conclusion

This project demonstrates how to use Google ADK to develop a multi-agent meeting scheduling system, covering tool development, API integration, multi-step task planning, permission management, and error handling. You are encouraged to further try:

Adding cross-timezone support
Integrating meeting room reservations
Supporting natural language input and parsing

How to Run This Python App

Command Line Usage:

You can schedule a meeting directly from the command line by running:

python meeting_workflow_adk.py --summary "Product Meeting" --time "2025-05-15T14:00:00" --duration 60 --attendees "alice@example.com,bob@example.com" --description "Product development meeting"

Or, for a demonstration with example parameters, simply run:

python meeting_workflow_adk.py

Web Interface:

To use the Streamlit web interface, run:

streamlit run streamlit_app.py

Then open the displayed URL in your browser (typically http://localhost:8501).

For complete code and examples, please refer to this project’s GitHub Repo.

Next Article Preview

Multi-Agent Collaboration System: Project Management Collaboration Platform

In the next article, we will explore how to build a multi-agent collaboration system for project management, featuring Manager, Engineering, and QA/Test agents. This system will demonstrate advanced agent collaboration patterns for handling project planning, task assignment, and quality assurance workflows. Stay tuned!

Google Agent Development Kit (ADK) Introduction (1): Quickly Build Your First AI Agent

Jonathan Huang — Mon, 12 May 2025 07:12:03 +0000

What is Google Agent SDK

Google Agent SDK (also known as Agent Development Kit, ADK) is an open-source SDK developed by Google, primarily in Python, designed to simplify and accelerate the development, testing, and deployment of AI Agents.

Developers can use this SDK to build modern AI Agents equipped with memory, tool invocation, task coordination, and other capabilities. ADK is deeply integrated with Google Gemini, Vertex AI, and various Google Cloud services.

Setup Environment and Configure Google Cloud

Go to Google Cloud Console and sign in or register an account.
Create a new project and ensure billing is enabled.
Enable the 'Vertex AI API' in the API management.
Install Google Cloud CLI (gcloud), official download page.
Update CLI components:

   gcloud components update

Log into your Google account in the terminal and generate Application Default Credentials (ADC):

   gcloud auth application-default login

A browser will open, complete the login to authenticate your Google account

Create a Python Virtual Environment and Install ADK

Create a virtual environment in your project directory:

   python -m venv .venv

Activate the virtual environment (run this every time you open a new terminal):
- macOS/Linux:
```
  source .venv/bin/activate 
```
- Windows CMD:
```
  .venv\Scripts\activate.bat 
```
- Windows PowerShell:
```
  .venv\Scripts\Activate.ps1
```
Install Google Agent SDK（ADK）：

   pip install google-adk

(For advanced Vertex AI features, use pip install --upgrade --quiet google-cloud-aiplatform[agent_engines,adk])

Create project and .env

Create project and necessary files：

   mkdir multi_tool_agent
   cd multi_tool_agent
   touch __init__.py agent.py .env

project structure example：

   parent_folder/
     multi_tool_agent/
       __init__.py
       agent.py
       .env

Edit the .env file and enter your Google Cloud project information (example):

   GOOGLE_CLOUD_PROJECT="your-project-id"
   GOOGLE_CLOUD_LOCATION="us-central1"
   GOOGLE_GENAI_USE_VERTEXAI="True"

Or, if you're using an API Key (Google AI Studio):

   GOOGLE_GENAI_USE_VERTEXAI=FALSE
   GOOGLE_API_KEY="your-api-key"

Write Your First Agent

In agent.py, write a simple example (refer to the official Quickstart):

   from google.adk.agents import Agent

   root_agent = Agent(
       name="hello_agent",
       model="gemini-2.5-pro-preview-05-06",
       instruction="You are a friendly assistant answering user questions."
   )

In __init__.py Add：

   from . import agent

Launch the Agent Dev Interface or Run Locally

Go back to the parent folder and launch the dev UI:

adk web

parent_folder/  <-- Run 'adk web' here
└── your_agent_folder/
    ├── __init__.py
    └── agent.py

Open the displayed URL in a browser (usually http://localhost:8000) to interact with the Agent.

Or test directly in the terminal:

  adk run multi_tool_agent

Advanced: Quickly Try Official Samples

Clone the official sample repo:

  git clone https://github.com/google/adk-samples.git cd adk-samples/agents

Follow each subfolder’s README to quickly try various pre-built agents.

FAQ and Notes

I encountered issues finding available regions and models.
- Use region: us-central1
- Region list: https://cloud.google.com/compute/docs/regions-zones?hl=en
- Use model: gemini-2.5-pro-preview-05-06
- Model list: https://cloud.google.com/vertex-ai/generative-ai/docs/models

使用 VS Codium 代替 Visual Studio Code

Jonathan Huang — Mon, 05 Sep 2022 06:21:23 +0000

我自己也是很喜歡 Visual Studio Code，可以說他是近幾年來非常成功的 editor，但是最大缺點就是 tracking 跟 telemetry 的問題。如果你跟我一樣不想要被 track，VS Codium 就是一個好選擇。

VS Codium 和 Visual Studio Code 幾乎完全相同，唯一的不同是他不會追蹤你的使用行為。

Visual Studio Code 本身是 open source，但是他的 binary 是經過微軟包裝過的，並且加入了若干追蹤機制。

當然在 Visual Studio Code 裡面你可以透過設定一系列的參數來 disable telemetry reporting，但是更乾淨的作法會是你可以下載一個完全 open source 的版本，就是 VS Codium。

VS Codium 是從 Visual Studio Code 的 repository folk 出來的版本，並且在 package 的過程中不會加入 tracking 和 telemetry 的機制。

至於 extension 的支援，目前為止我覺得是完全相容。Visual Studio Code 有個 extension marketplace，而 VS Codium 也一樣有個 Open VSX Registry 的 marketplace。

	Visual Studio Code	VS Codium
License	Microsoft product license	MIT
Tracking/telemetry	Enabled by default	Disabled
Marketplace	Microsoft Visual Studio Code Marketplace	Open VSX Registry
Extensions	All extensions including Microsoft extensions	Some Microsoft's extensions are restricted

最後，我在轉移的過程中使用了 Sync Settings 這個 extension，感覺比之前使用的 Settings Sync 簡單不少。