DEV Community: Shir Meir Lador

Build a Long-Running Agent in the Cloud for $5.70/Month

Shir Meir Lador — Thu, 03 Sep 2026 15:54:57 +0000

How do you run an autonomous AI agent in the cloud 24/7 for just $5.70 a month?

I recently wanted to build a background worker with persistent disk storage and an instant web dashboard, but I didn't want the headache of managing a virtual machine or paying a massive monthly bill.

If you are building long-running agents, you know this exact cloud hosting dilemma:

Standard serverless (like Cloud Run services or Lambda): When traffic stops, the container scales to zero — instantly killing your background loops and wiping your agent's active memory (RAM). On the flip side, a sudden traffic spike spins up multiple containers that can overwrite each other's state files and corrupt your data. (Note: Save state using JSON or Markdown files. Avoid SQLite, as Cloud Run volume mounts)
A regular virtual machine (like EC2 or Compute Engine): Keeps your agent running 24/7, but a standard 1-vCPU machine typically costs $15 to $25 a month even when idle. Even if you use a heavily-throttled fractional VM for $7/month, you are still stuck with the full infrastructure management overhead.

Last year, I built a multi-agent Trend Spotter with ADK. It worked well, but I wanted to make it fully autonomous: a continuous, long-running agent that scans and summarizes tech feeds in the background without manual triggers or high hosting costs.

Google Cloud's new Cloud Run instances primitive solves this exact problem. It gives you a single, always-on container that runs 24/7, costs $5.70 a month on a shared CPU, provides a free HTTPS endpoint, and lets you mount cloud storage like a normal local disk.

Here is how to build and deploy a production long-running agent with this setup (you can follow along with the complete source code in the repo.

What are we building?

I want to stay up to date with what is happening in AI and agent engineering. But instead of manually opening 20 browser tabs across different websites every morning, I wanted to build my own long-running agent that updates me on recent news anytime I want.

Personal tech briefing agent UI

Here is what the agent does:

Runs continuously as a background daemon: Wakes up automatically every 30 minutes to collect fresh news. Note that Cloud Run instances restart automatically up to every 7 days, so your agent just needs to gracefully resume its schedule when restarted.
Scans Hacker News and other curated AI and agent engineering sources.
Accepts real-time alerts & mobile shares: Includes an inbound webhook (POST /api/webhook) so you can push breaking tweets, iOS Share Sheet links, or GitHub releases straight into the agent for instant summarization.
Filters the noise: Strips out paywalls, ads, and low-substance articles.
Summarizes with Gemini 2.5 Flash: We use Gemini 2.5 Flash to keep costs low. You can swap in the newer Gemini 3.5 or 3.6 Flash models if you need advanced reasoning, but note that their input tokens cost 5x as much compared to 2.5 Flash ($1.50 vs $0.30 per 1M tokens). For simple daily summarization, 2.5 Flash (or the equally cheap Gemini 3.5 Flash-Lite) is fast, highly capable, and keeps the monthly API bill to just a few cents.
Saves data safely: Stores the daily markdown briefing and seen URLs directly in a mounted cloud storage folder (/data).
Serves a clean web dashboard: Gives an instant web page to read your briefing or trigger a fresh run whenever you want.

How the system works

The whole application runs inside one Cloud Run instance:

Tech briefing agent architechture

What else can you build with a long-running agent?

A tech briefing agent is just one example. Because Cloud Run instances give you an always-on background worker, a free web endpoint, and safe local disk storage, you can use this exact same pattern for many developer workflows:

Persistent Slack, Discord, or Telegram Bot: A bot that maintains long-lived connections to chat gateways, answers developer questions, and syncs unresolved issues to your backlog.
Security & Vulnerability Watchdog: An agent that runs on an internal timer to monitor dependencies and CVE security feeds, caching vulnerability signatures on local disk.
DevOps Incident Triage Co-Pilot: An agent that receives incoming webhook alerts from monitoring tools, runs background log queries without timing out, and renders an instant root-cause dashboard.
Pull-Based Queue Worker: An agent that continuously pulls complex tasks from Pub/Sub, Kafka, or RabbitMQ, performs multi-step LLM reasoning, and writes results to storage.
Nightly CI/CD & Flaky Test Fixer: A background daemon that runs overnight test suites, analyzes test logs to spot flaky tests, and opens pull requests with automated fixes.

Why Cloud Run instances are great for agents

Standard serverless platforms are designed for quick web requests. They wait for a user to click a button, run for one second, and shut down.

Long-running background agents have different needs:

Comparison — Standard Serverless / Regular VMs / Cloud Run Instances

With an instance, you get the simplicity of serverless with the stability of a VM. Because your instance is always hot with a public HTTPS endpoint, it easily handles three trigger styles in one container:

Periodic Background Polling: Runs autonomously on an internal asyncio schedule without needing external cron services.
Instant Web Dashboard: Zero cold starts when you open the reading dashboard.
Real-Time Push Webhooks: An inbound POST /api/webhook route that lets you push breaking tweets, iOS share sheet links, or GitHub release alerts straight into the agent for immediate summarization.

When NOT to use this

Cloud Run instances are great for single-worker background agents. You should pick a different tool if you need:

Massive parallel batch jobs: If you need to process 10,000 documents at once across 100 parallel workers, use Cloud Run Jobs or GKE. An instance is a single worker.
High-traffic, bursty web APIs: If your website gets sudden spikes of millions of requests, use standard Cloud Run services so your app can automatically autoscale to hundreds of containers and scale down to zero when traffic stops.
Heavy local GPU model hosting: If you want to host an open 70B model directly inside your container on a dedicated H100 GPU, use GKE or Compute Engine. Cloud Run instances are built for CPU applications that connect to hosted models like Gemini.

Alternative architecture: Decoupled Job + Service

Instead of a single instance, you could build an event-driven system: a Cloud Scheduler triggers a Cloud Run Job for polling, while a scale-to-zero Cloud Run Service hosts the dashboard and listens for webhooks.

While this decoupled approach drops compute costs to virtually $0.00 in the free tier, you lose single-container simplicity. You are forced to manage multiple cloud services and message queues (to prevent concurrent webhooks from corrupting your state), while accepting cold starts on your web dashboard.

Compare instances with Decoupled Job + Service for this task

Deploy your long-running agent in 6 simple steps

You can deploy this setup to Google Cloud in about five minutes.

1. Turn on the cloud services

export PROJECT_ID="your-project-id"
export REGION="us-west1"
export BUCKET_NAME="${PROJECT_ID}-agent-data"
export REPO_NAME="agent-repo"
gcloud config set project $PROJECT_ID
gcloud services enable run.googleapis.com storage.googleapis.com artifactregistry.googleapis.com cloudbuild.googleapis.com secretmanager.googleapis.com

Note: Cloud Run instances are not available in every region. Please pick a supported region near you from the Cloud Run instances locations page.

2. Create a storage bucket for your data

gcloud storage buckets create gs://$BUCKET_NAME \
  --location=$REGION \
  --uniform-bucket-level-access

3. Build your container

gcloud artifacts repositories create $REPO_NAME \
  --repository-format=docker \
  --location=$REGION
gcloud builds submit \
  --tag ${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/tech-briefing-agent:latest .

4. Create a service account

gcloud iam service-accounts create briefing-agent-sa \
  --display-name="Briefing Agent SA"
gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
  --member="serviceAccount:briefing-agent-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectUser"

5. Store your API key securely

Never pass API keys in plain text. Store your Gemini API key in Google Cloud Secret Manager and grant your service account permission to read it:

echo -n "YOUR_GEMINI_API_KEY" | gcloud secrets create gemini-api-key \
  --data-file=- \
  --replication-policy="automatic"
gcloud secrets add-iam-policy-binding gemini-api-key \
  --member="serviceAccount:briefing-agent-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

6. Launch the instance

gcloud beta run instances create tech-briefing-agent \
  --image=${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/tech-briefing-agent:latest \
  --region=$REGION \
  --port=8080 \
  --cpu=1 \
  --memory=1Gi \
  --public \
  --service-account=briefing-agent-sa@${PROJECT_ID}.iam.gserviceaccount.com \
  --add-volume mount-path=/data,type=cloud-storage,mount-options="uid=1000;gid=1000;file-mode=0700;dir-mode=0700",bucket=$BUCKET_NAME \
  --set-secrets "GEMINI_API_KEY=gemini-api-key:latest" \
  --set-env-vars "DATA_DIR=/data,POLL_INTERVAL_MINUTES=30"

We set --cpu=1 and --memory=1Gi to keep the cost at $5.70. If you omit these, it defaults to 2 CPUs and 2 GiB (~$11.40/month, see pricing table). To improve load times, you can increase the CPU and memory.

[!TIP] Adjust uid=1000;gid=1000 in the mount-options flag to match the specific non-root user ID defined in your Dockerfile, if different.

When this command finishes, Cloud Run gives you a live HTTPS web address. Open it in your browser to see your briefing dashboard.

What does this cost in real life?

Here is the real monthly bill for running this 24/7:

Monthly cost breakdown

For less than the price of two cups of coffee, you have a private agent running day and night.

Learn more about Cloud Run instances

Want to dive deeper into Cloud Run Instances? Check out these official Google Cloud resources:

Official Launch Blog: Introducing Cloud Run instances
Official Documentation: Create and manage Cloud Run instances
Hands-on Codelab: Deploying to Cloud Run instances Codelab
Source Code & ADK Graph: Tech-briefing-agent on GitHub

What is coming next?

Now that the hosting problem is solved, how do you make the agent smart and resilient? How do you stop it from summarizing noise when it hits a paywall, or build self-correcting reflection loops?

Join us in the next part where we will dive into graph engineering and the architecture of the agent using ADK 2.0.

Happy building!

Your First Multi-agent system: A Beginner's Guide to Building an AI Trend finder with ADK

Shir Meir Lador — Thu, 03 Sep 2026 15:53:27 +0000

Welcome back to our series on building the ultimate AI research assistant for our AI agent podcast! In our first post, we built a fantastic agent that could search the web to find the latest AI agent news for the agent factory podcast. But what if we want to add more specialized skills, like getting the real pulse from developer communities on Reddit? To do that, we need to upgrade our agent's design.

In this guide, we are going to level up our skills and refactor our simple agent into a powerful multi-agent system. We will build a "Manager" agent that directs a team of specialists, including one with a custom-built Reddit tool, to gather richer, more diverse insights.

By the end of this post, you'll have an even more powerful Trend Spotter agent that gets information from multiple sources. More importantly, you will learn the advanced skills needed to build complex agents with ADK. You will know how to:

Build a scalable multi-agent system.
Build a custom tool from any Python function (like our new Reddit tool).
Create an orchestrator agent that delegates tasks to a team of specialists.
Write advanced prompts to manage a multi-step, multi-tool workflow.
Debug a multi-agent system using the ADK's powerful Trace view.

This architecture is the key to unlocking your agent's full potential. Let's get started!

Our Multi agent system flow

Step 1: Get Reddit API Credentials & Install Library

To allow our agent to access Reddit programmatically, we need to get API credentials. This is free and only takes a minute.

Navigate to Reddit Apps: Log in to your Reddit account and go to the app preferences page: https://www.reddit.com/prefs/apps.
Create a New App: Scroll to the bottom and click the button that says "are you a developer? create an app…".
Fill out the form:

name: Trend Spotter Agent
Select the script option for the application type.
about url: You can leave this blank.
redirect url: You must enter http://localhost:8080 for this field.

Click create app. You will now be taken to a new page showing your credentials.

5. Set Environment Variables: For security, we'll store these credentials as environment variables.

Your client ID is the string of characters right under "personal use script".
Your client secret is the long string next to the secret label.
Open your terminal and run the following export commands:

export REDDIT_CLIENT_ID=”YOUR_CLIENT_ID”  
export REDDIT_CLIENT_SECRET=”YOUR_CLIENT_SECRET”  
export REDDIT_USER_AGENT=”TrendSpotterAgent/0.1 by u/YourUsername”

6. Update Dependencies: Add the praw library to your requirements.txt file and install it.

# requirements.txt  
google-adk  
praw

Install it from your terminal:

pip install -r requirements.txt

Configure Your Cloud Environment

If you haven't done so already, in our previous blog we showed how to define the settings to tell ADK how to securely connect to your Google Cloud account to use services like Vertex AI and Google Search.

export GOOGLE_GENAI_USE_VERTEXAI=true  
export GOOGLE_CLOUD_PROJECT=<your-gcp-project-id>  
export GOOGLE_CLOUD_LOCATION=<your-gcp-project-location>

Run this one-time command. It will open a browser for you to sign in, allowing ADK to make authorized requests on your behalf.

gcloud auth application-default login

Step 2: Create the Project Folder

To organize our new team of agents, we'll create a sub_agents directory inside our main trend_spotter package.

No worries if you haven't gone through the first blog post, we got you! here is how you create the folder structure for your main agent:

# Create the main project folder  
mkdir trend-spotter && cd trend-spotter  
# Create the Python package folder that will hold our code  
mkdir trend_spotter  
touch trend_spotter/__init__.py  
touch trend_spotter/agent.py  
touch trend_spotter/prompt.py  
# Create the top-level configuration files  
touch pyproject.toml requirements.txt  
# Finally, create and activate a virtual environment  
python3 -m venv venv && source venv/bin/activate

(On Windows, use python -m venv venv && .\venv\Scripts\activate)

After you have the main agent and your folder structure defined, from your trend-spotter root folder, run:

# Create the sub-agents directory and its Python initializer  
mkdir trend_spotter/sub_agents  
touch trend_spotter/sub_agents/__init__.py

Step 3: Create the Specialist Sub-Agents

Now we'll build our two specialist agents by directly creating instances of the Agent class.

1. The Google Search Specialist:

Create a new file: trend_spotter/sub_agents/google_search_agent.py
Add this code. Note how we directly create the google_search_agent variable.

# trend_spotter/sub_agents/Google Search_agent.py  
from google.adk.agents import Agent  
from google.adk.tools import google_search  

MODEL = "gemini-2.5-pro-preview-05-06"  

# A specific, structured prompt to control the output format of this sub-agent.  
google_search_SUB_AGENT_PROMPT = """  
**Role:**  
- You are a specialist Research Assistant.  
- Your only purpose is to execute a Google Search based on instructions from your manager and return the raw, structured results.  

**Tools:**  
- You have access to one tool: `Google Search`.  

**Context:**  
- You will be given a query by a manager agent.  
- Your output will be read by another agent, so it must be clean, predictable, and structured.  
- You must not summarize, analyze, or interpret the search results. Your job is only to find and format the information directly from the tool's output.  

**Task:**  
1.  Take the search query provided to you.  
2.  Execute a search using the `Google Search` tool.  
3.  Format the raw output from the tool into a list, following the **exact** `Output Format` specified below.  

**Output Format:**  
For each search result, you MUST provide the Title, Link, and Snippet. Each complete result must be separated by '---'.  

---  
Title: [Title of the first search result]  
Link: [Full URL of the first search result]  
Snippet: [Snippet text of the first search result]  
---  
Title: [Title of the second search result]  
Link: [Full URL of the second search result]  
Snippet: [Snippet text of the second search result]  
---  
(and so on for all results)  
"""  

google_search_agent = Agent(  
    model=MODEL,  
    name="google_search_agent",  
    description="An expert at using google_search to find recent information and return a structured list of results including URLs.",  
    # We assign the new, structured instruction here.  
    instruction=google_search_SUB_AGENT_PROMPT,  
    tools=[google_search]  
)

2. The Reddit Specialist:

First, create a new file for our custom tool's code: trend_spotter/tools.py. Add the following function to it.

import os  
import praw  

# The function now accepts a LIST of subreddit names  
def search_hot_reddit_posts(subreddit_names: list[str], limit_per_subreddit: int = 5) -> str:  
    """  
    Searches a list of subreddits for their current hot posts and returns their titles and URLs.  

    Args:  
        subreddit_names: A list of subreddit names to search (e.g., ["LocalLLaMA", "MachineLearning"]).  
        limit_per_subreddit: The number of top posts to retrieve from each subreddit.  

    Returns:  
        A dictionary containing the status and a list of formatted post strings.  
    """  
    try:  
        print(f"\n🔎 Searching Reddit for hot posts in: {', '.join(subreddit_names)}...")  

        reddit = praw.Reddit(  
            client_id=os.environ["REDDIT_CLIENT_ID"],  
            client_secret=os.environ["REDDIT_CLIENT_SECRET"],  
            user_agent=os.environ["REDDIT_USER_AGENT"],  
            read_only=True,  
        )  

        all_posts = []  
        # Loop through each subreddit name provided in the list  
        for sub_name in subreddit_names:  
            print(f"  - Fetching from r/{sub_name}...")  
            subreddit = reddit.subreddit(sub_name)  
            for post in subreddit.hot(limit=limit_per_subreddit):  
                # We can add a simple filter here if we want, e.g., for score  
                if post.score > 5:  
                    all_posts.append(f"Title: {post.title}\nLink: {post.url}")  

        if not all_posts:  
            return "No hot posts found meeting the criteria in the specified subreddits."  

        print(f"✅ Reddit search complete. Found {len(all_posts)} qualifying posts.")  
        return "\n---\n".join(all_posts)  

    except Exception as e:  
        return f"Error searching Reddit: {e}"

Now, create the Reddit agent itself at trend_spotter/sub_agents/reddit_agent.py:

# trend_spotter/sub_agents/reddit_agent.py  
from google.adk.agents import Agent  
from trend_spotter.tools import search_hot_reddit_posts  
MODEL = "gemini-2.5-pro-preview-05-06"  

reddit_agent = Agent(  
    name="reddit_agent",  
    model=MODEL,  
    description="An expert at finding hot posts on specific Reddit subreddits using its tool.",  
    tools=[search_hot_reddit_posts]  
)

Step 4: Build the Main Orchestrator Agent

Now we'll modify our main agent from Part 1 to become the "manager" of our new specialist team.

Open trend_spotter/prompt.py and replace its contents with this new orchestrator prompt:

# trend_spotter/prompt.py  

ORCHESTRATOR_PROMPT = """  
**Role:**  
- You are the highly-capable manager of an AI research team.  
- Your purpose is to produce a high-quality, detailed intelligence report for the "The Agent Factory" podcast.  
- Your focus is exclusively on developments in AI agents that are impactful and relevant to software developers.  

**Tools:**  
- You have a team of two specialist agents available to you as tools:  
  1. `google_search_agent`: An expert at performing general web searches for news, releases, and technical articles.  
  2. `reddit_agent`: An expert at finding real, hands-on developer conversations on specific subreddits.  

**Context:**  
- You must synthesize information from BOTH the `google_search_agent` and the `reddit_agent` to form your conclusions.  
- Your primary filter for all information is its direct and significant impact on developers. Discard anything that is purely business-focused or marketing fluff.  
- Topics that appear in multiple sources (e.g., in both tech news and on Reddit) should be considered more important and prioritized in your report.  
- The final report must be structured exactly as described in the Task section.  

**Task:**  
1.  **Discover the Current Date:** Your very first action is to delegate to your `google_search_agent`. Instruct it to find the current date.  
2.  **Delegate Focused Research:**  
    - Based on the date, calculate the start and end dates for the last 7 days.  
    - Instruct the `google_search_agent` to find news about new open-source agent frameworks, updates to popular libraries (like LangChain, ADK, CrewAI or LlamaIndex), and technical tutorials about building agents within the calculated date range using `after:YYYY-MM-DD` and `before:YYYY-MM-DD` operators.  
    - Instruct the `reddit_agent` to find the hottest developer conversations about practical challenges, new techniques, and opinions on new tools from subreddits like "LocalLLaMA", "MachineLearning", "LangChain", "AI_Agents", "LLMDevs", and "singularity".  
3.  **Synthesize and Create the Final Report:**  
    - Review the information provided by **both** specialist agents.  
    - Combine, filter, and deduplicate the findings. Your primary filter is to **only select topics that have a direct and significant impact on developers.**  
    - **Pay special attention to topics that appear in multiple source in the general web search and on Reddit**, as these are likely the most important and should be prioritized.  
    - The report **must begin with a header** specifying the date range used.  
    - The body of the report must have exactly three sections as detailed below.  
    - For each item, you **must provide four pieces of information**: a 1-2 sentence explanation, an indented "Developer Impact" analysis, a "Prioritization Rationale", and a verifiable source URL.  

**Final Report Format:**  

**🔥 Top 5 Trends for Agent Developers**  
1.  **[Trend 1 Name]**: [A 1-2 sentence explanation of this trend.]  
    **(Source: [URL])**  
    * **Developer Impact**: [A 1-sentence explanation of why this matters to developers.]  
    * **Prioritization Rationale**: [A 1-sentence explanation of why this topic was selected, e.g., "High volume of discussion on Reddit and mentioned in multiple tech articles."]  
2.  ... (up to 5 total)  

**🚀 Top 5 Releases for Agent Developers**  
1.  **[Release 1 Name]**: [A 1-2 sentence explanation of the tool, framework, or model.]  
    **(Source: [URL])**  
    * **Developer Impact**: [A 1-sentence explanation of why this matters to developers.]  
    * **Prioritization Rationale**: [A 1-sentence explanation of why this topic was selected.]  
2.  ... (up to 5 total)  

**🤔 Top 5 Questions from Agent Developers**  
1.  **[Question 1 Topic]**: [A 1-2 sentence explanation of what developers are asking.]  
    **(Source: [URL])**  
    * **Developer Impact**: [A 1-sentence explanation of why this matters to developers.]  
    * **Prioritization Rationale**: [A 1-sentence explanation of why this topic was selected.]  
2.  ... (up to 5 total)  
"""

Open trend_spotter/agent.py and replace its contents to turn it into the orchestrator. Notice how we now import the agent instances we created.

# trend_spotter/agent.py  
from google.adk.agents import LlmAgent  
from google.adk.tools.agent_tool import AgentTool  
# Import the sub-agent INSTANCES  
from .sub_agents.google_search_agent import google_search_agent  
from .sub_agents.reddit_agent import reddit_agent  
from . import prompt  
MODEL = "gemini-2.5-pro-preview-05–06"  
# This is our main "manager" agent, now an LlmAgent  
root_agent = LlmAgent(  
model=MODEL,  
name="TrendSpotterOrchestrator",  
description="The manager of a team of specialist AI agents.",  
instruction=prompt.ORCHESTRATOR_PROMPT,  
# The Orchestrator's "tools" are its sub-agents, wrapped in AgentTool  
tools=[  
AgentTool(agent=google_search_agent),  
AgentTool(agent=reddit_agent)  
],  
)

Step 5: Running Your Multi-Agent System

The run process remains the same. The adk web tool will automatically load your root_agent, which is now the orchestrator.

Ensure your pyproject.toml file still correctly points to your main agent:

[project]  
name = "trend_spotter"  
version = "0.1.0"  
# Setuptools will now auto-discover your trend_spotter package.  
[tool.adk.agents]  
trend_spotter = "trend_spotter.agent:root_agent"

Install your updated package with the new dependencies:

pip install -e .

Launch the web interface:

adk web

In the "Event" tab of the web UI, you will now see the main orchestrator agent making calls to its new google_search_agent and reddit_agent sub-agents. You've successfully built a more robust and scalable AI system using the correct ADK patterns!

You should get an output like this:

Report for the week of June 4, 2025 - June 11, 2025  

🔥 Top 5 Trends for Agent Developers  

Enterprise Adoption of Agent Frameworks: Frameworks like LangChain are showing significant growth in enterprise contexts, indicated by surpassing the OpenAI SDK in Python downloads and new integrations with systems like SAP and Salesforce. (Source: news.knowledia.com - "LangChain Surpasses OpenAI SDK in Monthly Python Downloads" - This specific URL was not in the provided search but is representative of the type of news article that would contain this information from the search summary "LangChain: Surpassed the OpenAI SDK in monthly Python downloads as of June 2025")  
Developer Impact: Developers using or learning LangChain can expect more mature tooling and greater demand for their skills in enterprise settings.  
Prioritization Rationale: This trend is based on download statistics and enterprise integration news, indicating a major shift in the landscape relevant to developers' career opportunities.  
Enhanced Observability and Debugging in Agent Development: There's a clear move towards more sophisticated tools for monitoring, debugging, and managing the cost of AI agents, exemplified by Langfuse's integration with LlamaIndex and new features in LangSmith. (Source: https://news.llamaindex.ai/integrating-langfuse-for-observability-and-debugging-in-llamaindex-5f4f7f8c29ac [Example URL based on search "An article from June 6, 2025, discusses integrating Langfuse with LlamaIndex for observability and debugging."])  
Developer Impact: Developers will have better tools to understand agent behavior, optimize performance, and control operational costs.  
Prioritization Rationale: Addresses a critical developer need for building robust and maintainable agents, highlighted by multiple framework updates.  
Advanced Structured Data Handling by Agents: Agents are becoming more adept at working with structured data, with developments like Microsoft AutoGen's Structured Retrieval Augmentation and LlamaIndex's Spreadsheet Agent. (Source: Daily AI Agent News - "Microsoft AutoGen v0.4: Structured Retrieval Augmentation & MCP" - this URL was not in the search results but the information "Microsoft AutoGen v0.4 implements Structured Retrieval Augmentation" was.)  
Developer Impact: This allows developers to build agents for more complex, real-world use cases involving databases, spreadsheets, and other structured formats.  
Prioritization Rationale: Represents a significant expansion in agent capabilities, enabling new applications and increasing their utility.  
Growth of Local and Open-Source Agent Solutions: New open-source frameworks like "Goose" (from Block) and "OpenHands" emphasize local execution and customization, aligning with developer discussions on platforms like Reddit (r/LocalLLaMA) about gaining more control over their LLM setups. (Source: https://www.reddit.com/r/LocalLLaMA/comments/1l8pem0/i_finally_got_rid_of_ollama/ and news articles on Goose/OpenHands release)  
Developer Impact: Provides developers with more options for privacy-centric, cost-effective, and highly customizable agent development.  
Prioritization Rationale: Supported by both new tool releases in the general tech news and active discussions within the developer community (Reddit).  
Rise of Multi-Agent Systems and Interoperability Standards: The development of orchestrators like Fujitsu's and advancements in frameworks such as CrewAI and AutoGen (with MCP support) highlight a focus on complex systems where multiple agents collaborate. LangGraph is also central to this trend. (Source: Tech news article on "Fujitsu's Agentic Workflow Orchestrator" and https://www.reddit.com/r/LangChain/comments/1l8zy42/built_a_texttosql_multiagent_system_with/ )  
Developer Impact: Developers are increasingly tasked with designing, building, and managing interactions between multiple specialized agents, requiring new skill sets.  
Prioritization Rationale: This is a key area of innovation, mentioned in multiple framework updates and discussed by developers building sophisticated applications.  

🚀 Top 5 Releases for Agent Developers  

LangGraph Platform General Availability: LangChain's LangGraph, a library for creating stateful, multi-actor LLM applications, is now generally available, offering features like 1-click deployment. (Source: LangChain official blog/documentation - the search mentioned "LangGraph Platform is now generally available" as a LangChain update.)  
Developer Impact: Offers a production-ready path for developers to build complex, scalable agentic systems and multi-agent collaborations.  
Prioritization Rationale: Significant release for a popular ecosystem, addressing the need for robust multi-agent system development.  
AutoGen v0.4 (Microsoft): This version introduces Structured Retrieval Augmentation and full support for the Model Context Protocol (MCP), enhancing data handling and enabling interoperability with other agent platforms. (Source: GitHub releases page for Autogen or news articles covering the v0.4 release mentioned in the search: "Microsoft AutoGen v0.4 implements Structured Retrieval Augmentation and full support for the open-source MCP standard")  
Developer Impact: Allows developers to build more powerful AutoGen agents capable of complex data interactions and cross-platform collaboration.  
Prioritization Rationale: Major update to a key framework from Microsoft, improving core functionality and ecosystem compatibility.  
CrewAI v0.126.0: Features real-time task redistribution, Python 3.13 support, persisted tools from a Tool repository, streamable-http transport in MCP, and major documentation restructuring. (Source: CrewAI GitHub releases or their official blog - "CrewAI: Released v0.126.0 on June 5, 2025" was in the search results.)  
Developer Impact: Provides developers with improved performance, better tool management, enhanced interoperability, and easier onboarding through better documentation.  
Prioritization Rationale: A substantial update to a growing agent framework, focusing on efficiency and developer experience.  
LlamaIndex Spreadsheet Agent & Llama Cloud Updates: LlamaIndex launched a production-ready Spreadsheet Agent for natural language Q&A on spreadsheets and announced new MCP integration and Llama Cloud enhancements. (Source: LlamaIndex Newsletter/Blog - "LlamaIndex: ...announcing a new production-ready Spreadsheet Agent...new MCP (Model Context Protocol) integration..." was in the search results.)  
Developer Impact: Delivers a practical tool for a common business analytics task and improves the deployability and connectivity of LlamaIndex agents.  
Prioritization Rationale: Addresses specific, high-value developer use cases (spreadsheet interaction) and improves platform capabilities.  
Goose (Open-Source AI Agent Framework by Block): An extensible AI agent framework from Block designed to run entirely locally, capable of writing/executing code and interacting with the file system. (Source: News articles covering the Goose release - "Goose: Released by Block (formerly Square), Goose is an open-source AI agent framework..." was in the search results.)  
Developer Impact: Gives developers a new, powerful, and locally controllable tool for building agents, especially those focused on coding tasks.  
Prioritization Rationale: A new entrant in the open-source framework space from a well-known company, catering to local-first development.  
🤔 Top 5 Questions from Agent Developers  

Getting Started with AI Agent Development: Newcomers are actively seeking guidance on initial steps, choosing foundational frameworks (LangChain, CrewAI, AutoGen frequently cited), and identifying suitable beginner projects. (Source: Reddit thread from June 5, 2025, providing advice for beginners, or a general link like https://www.reddit.com/r/AI_Agents/ if specific links are too numerous. The search mentioned: "A Reddit thread from June 5, 2025, provides advice for beginners...")  
Developer Impact: Highlights a need for more structured learning paths and accessible resources for developers new to building AI agents.  
Prioritization Rationale: A foundational question indicating growing interest and the need for community/educational support, seen in both search and Reddit results.  
Optimizing and Controlling Local LLM Setups: Developers on subreddits like r/LocalLLaMA are discussing practical challenges and alternatives for local LLM environments (e.g., moving from Ollama to llama.cpp/OpenWebUI). (Source: https://www.reddit.com/r/LocalLLaMA/comments/1l92vr0/as_some_people_asked_me_to_share_some_details/)  
Developer Impact: Reflects the hands-on effort by developers to fine-tune their local development stacks for better performance, control, or feature sets.  
Prioritization Rationale: A practical, developer-driven discussion on Reddit about tooling and local environment optimization.  
Implementing Text-to-SQL Multi-Agent Systems: There is active exploration and sharing of projects on building multi-agent systems for complex database interaction tasks like Text-to-SQL, particularly using LangGraph. (Source: https://www.reddit.com/r/LangChain/comments/1l8zy42/built_a_texttosql_multiagent_system_with/)  
Developer Impact: Shows developers are pushing the capabilities of agents to tackle sophisticated, high-value enterprise tasks with multi-agent designs.  
Prioritization Rationale: Represents advanced application development discussed within the LangChain developer community.  
Seeking Open Source Alternatives for Observability Tools: Developers are interested in and building open-source options for agent observability, such as alternatives to LangSmith, including LangGraph visualization. (Source: https://www.reddit.com/r/LangChain/comments/1l93195/open_source_langsmith_alternative_with_langgraph/)  
Developer Impact: Indicates a community drive for more accessible and customizable tools for monitoring and understanding agent behavior.  
Prioritization Rationale: Highlights a specific tooling need and community-led solutions on Reddit, relevant for the LangChain ecosystem.  
Ensuring Code Quality in AI Training Data: A discussion on r/LLMDevs raises the question of how to ensure AI agents learn from high-quality code, suggesting approaches like using "gold standard files" rather than random code. (Source: https://www.reddit.com/r/LLMDevs/comments/1l8yweo/devs_stop_letting_ai_learn_from_random_code_use/)  
Developer Impact: This points to an evolving concern about data integrity and best practices when fine-tuning or training agents for coding tasks.  
Prioritization Rationale: An important discussion on Reddit regarding the quality and reliability of AI-assisted software development.

Part 6: Next Steps and Conclusion

Congratulations! You have successfully upgraded your simple agent into a powerful, multi-agent system using the Agent Development Kit's orchestrator pattern. This is a huge step in your journey as an agent developer.

You've now learned some of the most important skills for building complex AI applications:

How to create specialist sub-agents
Build a custom tool from any Python function
Design a manager agent that orchestrates an entire team to solve a problem.

This is how real-world, scalable agentic systems are built.

But this is just the beginning. You now have a truly powerful foundation that you can expand upon. Think about what other specialists you could add to your team — agents/tools to fetch additional sources of information? an agent that saves the report to a Google Doc? A tool that posts the summary to Slack or email? The possibilities are endless.

When you're ready to dive deeper and explore all the advanced features the framework has to offer, the best place to go is the official Google Cloud ADK documentation.

Happy building!

Your First AI Agent: A Beginner's Guide to Building an AI Trend finder with ADK

Shir Meir Lador — Thu, 03 Sep 2026 15:52:29 +0000

The world of AI agents is moving at lightning speed. Keeping up with the latest trends, new open-source tools, and important developer conversations can feel like a full-time job. We're facing this exact challenge as we prepare to launch our new podcast for agent developers, which will be dedicated to all things AI agents (stay tuned!). To make sure we're ready for each episode, we wanted to create an automated way to get up-to-date with the news that matters.

In this guide, we are going to walk you step-by-step through building your very first AI agent on Google Cloud using the open-source Agent Development Kit (ADK). We will design a "Trend Spotter" agent whose mission is to act as your personal AI analyst, teaching it to scan the web and sift through the noise to find what truly matters.

By the end of this post, you will have a practical, working tool that automatically creates a concise intelligence report to keep you up-to-date, saving you hours of manual research. More importantly, you will learn the fundamental skills to build your own agents with ADK. You will know how to:

Structure a simple, powerful ADK agent as a proper Python package.
Write a detailed prompt to define your agent's logic and workflow.
Provide your agent with tools like Google Search.
Set up, test, and run your agent locally using the adk web interface.
Deploy your agent to Cloud Run.

Let's get started.

Part 1: Setup and Configuration

This setup uses a standard package structure that allows the ADK tools to discover and run our agent without a main.py file.

Step 1.1: Prerequisites

Python 3.11+
Google Cloud CLI: Follow the official installation guide here.
Google Cloud Account.

Step 1.2: Create Your Project Structure

Open your terminal. Create the following folder structure and virtual environment.

# Create the main project folder  
mkdir trend-spotter && cd trend-spotter  
# Create the Python package folder that will hold our code  
mkdir trend_spotter  
touch trend_spotter/__init__.py  
touch trend_spotter/agent.py  
touch trend_spotter/prompt.py  
# Create the top-level configuration files  
touch pyproject.toml requirements.txt  
# Finally, create and activate a virtual environment  
python3 -m venv venv && source venv/bin/activate  
(On Windows, use python -m venv venv && .\venv\Scripts\activate)

Step 1.3: Install ADK

Open requirements.txt and add our single dependency:

google-adk

Install it from your terminal:

pip install -r requirements.txt

Step 1.4: Configure Your Cloud Environment

These settings tell ADK how to securely connect to your Google Cloud account to use services like Vertex AI and Google Search.

Set Environment Variables: In your terminal, run the following export commands. These tell ADK to use the Vertex AI platform in your specific Google Cloud project and region.

export GOOGLE_GENAI_USE_VERTEXAI=true  
export GOOGLE_CLOUD_PROJECT=<your-gcp-project-id>  
export GOOGLE_CLOUD_LOCATION=<your-gcp-project-location>

Log In to Your Account: Run this one-time command. It will open a browser for you to sign in, allowing ADK to make authorized requests on your behalf.

gcloud auth application-default login

Part 2: Building Your Agent

Now we'll write the code and place it inside our trend_spotter package directory.

Step 2.1: Define the Agent's Brain (The Prompt)

The prompt contains all the instructions for our agent.

Note that we are guiding the LLM to specify the date range in the call to the GoogleSearch tool to make sure we are focusing on trends from the last week.

Open trend_spotter/prompt.py and add these instructions:

# trend_spotter/prompt.py  

TREND_SPOTTER_PROMPT = """  
You are a helpful AI assistant and expert tech analyst for a new podcast called "The Agent Factory". Your goal is to generate a highly relevant and verifiable report about the latest developments in AI agents that specifically impact developers.  

**Your multi-step plan is as follows:**  

**Step 1: Discover the Current Date.**  
Your very first action must be to find the current date.  
- **Action**: Use the `Google Search` tool with a query like "what is today's date".  
- From the search result, identify the current year, month, and day.  

**Step 2: Formulate and Execute Search Queries with Date Operators.**  
Now, you must formulate your search queries by embedding the date range directly into the query string using Google's `after:YYYY-MM-DD` and `before:YYYY-MM-DD` operators. Calculate these dates to cover the last 7 days.  
- You must perform at least three initial searches to cover trends, releases, and questions.  
- **Example Query Format**: `"AI agent trends after:2025-06-01 before:2025-06-08"`  
- After the initial searches, you may perform 1-2 additional, more targeted searches if a category is missing information. **Do not perform more than 5 searches in total.**  

**Step 3: Analyze the Results and Create the Report.**  
Read through all the text and links from your searches. Your primary filter is to **only select topics, tools, and questions that have a direct and significant impact on developers building AI agents.**  

**Critical Rule for Sourcing:** For every trend, release, or question you identify, you must first pinpoint the **single best search result** that provides the evidence. You will then use the URL from that **exact search result** as the source link for that item. **If you cannot find a specific source link for an item, do not include that item in the report.**  

Based on these rules, create a report:  
1.  The report **must begin with a header** specifying the date range used.  
2.  The body of the report must have exactly three sections.  
3.  For each item, you **must provide three pieces of information**: a 1-2 sentence explanation, the "Developer Impact" analysis, and the **verifiable source URL**.  

The report format must be:  

**🔥 Top 5 Trends for Agent Developers**  
1.  **[Trend 1 Name]**: [A 1-2 sentence explanation of this trend.] (Source: [URL])  
    * **Developer Impact**: [A 1-sentence explanation of why this matters to developers.]  
2.  ... (up to 5 total)  

**🚀 Top 5 Releases for Agent Developers**  
1.  **[Release 1 Name]**: [A 1-2 sentence explanation of the tool, framework, or model.] (Source: [URL])  
    * **Developer Impact**: [A 1-sentence explanation of why this matters to developers.]  
2.  ... (up to 5 total)  

**🤔 Top 5 Questions from Agent Developers**  
1.  **[Question 1 Topic]**: [A 1-2 sentence explanation of what developers are asking.] (Source: [URL])  
    * **Developer Impact**: [A 1-sentence explanation of why this matters to developers.]  
2.  ... (up to 5 total)  

Begin your work now by executing your plan.  
"""

Step 2.2: Assemble the Agent

The agent.py file connects our prompt and the search tool to a new ADK Agent.

Open trend_spotter/agent.py and add this code:

# trend_spotter/agent.py  
from google.adk.agents import Agent  
from google.adk.tools import google_search  
from . import prompt  
# Use the "latest" tag to always get the most recent stable version of the model.  
MODEL = "gemini-2.5-pro-preview-05–06"  
# This single agent will perform all the work.  
trend_spotter_agent = Agent(  
model=MODEL,  
name="trend_spotter_agent",  
description="An agent that finds and reports on AI agent trends.",  
# The agent's entire logic comes from our detailed prompt.  
instruction=prompt.TREND_SPOTTER_PROMPT,  
# We give the agent a single tool: the ability to search Google.  
tools=[google_search],  
)  
# We assign it to `root_agent` by convention for ADK to discover.  
root_agent = trend_spotter_agent

Step 2.3: Making Your Agent Discoverable

To use the adk web command, we need to tell ADK where to find our agent. We do this in the pyproject.toml file.

Open pyproject.toml in your root directory and add the following configuration:

[project]  
name = "trend_spotter"  
version = "0.1.0"  
# This section tells the ADK how to find our agent.  
[tool.adk.agents]  
trend_spotter = "trend_spotter.agent:root_agent"

Part 3: Running Your Agent

Now for the exciting part!

Step 3.1: Install your agent:

Run this command from your project's root directory. The -e . command installs your project in "editable" mode so the adk tool can find it.

pip install -e .

Step 3.2: Launch the web interface:

adk web

Open the URL that appears in your terminal. In the web interface, select "trend_spotter" from the dropdown menu. You can now chat with your agent! Ask it: "Generate a report on the latest AI agent news." This might take a few minutes, depending on the amount of searches you instruct the agent to perform in your prompt.

The response will look similar to this:

Okay, I will begin by finding the current date.  


Okay, I have identified the current date as June 7, 2025.  

Now, I will formulate and execute search queries to find information from the last 7 days (June 1, 2025, to June 7, 2025) about AI agent trends, releases, and questions relevant to developers.  


Okay, I have analyzed the search results and will now generate the report on AI agent developments impacting developers for the period of June 1, 2025, to June 7, 2025.  

Report: AI Agent Developments for Developers (June 1, 2025 - June 7, 2025)  

🔥 Top 5 Trends for Agent Developers  

Maturation of Agentic AI: Agentic AI, which involves AI systems that can autonomously handle complex tasks, is moving beyond hype and into practical application, with companies beginning to launch pilot projects. This trend signifies a shift towards more sophisticated AI that can streamline various stages of software development, testing, and maintenance.  
Developer Impact: Developers will increasingly need to build, integrate, and manage these more autonomous AI agents, requiring skills in designing for complex, goal-oriented behaviors.  
Rise of Multi-Agent Systems: There is a growing interest in systems where multiple AI agents collaborate to solve larger, more complex problems than a single agent could handle. This involves individual agents with specific goals and tools working together within a broader workflow.  
Developer Impact: This trend requires developers to think about inter-agent communication protocols, task delegation, and overall system orchestration.  
Emphasis on AI Agent Evaluation and Benchmarking: As AI agents become more capable and undertake more complex tasks, there's a corresponding growth in the need for robust evaluation methods and standardized benchmarks. These benchmarks aim to assess core competencies like planning, reasoning, and tool usage.  
Developer Impact: Developers will need to leverage these evolving benchmarks to test, validate, and improve the reliability and performance of the agents they build.  
Enhanced NLP and Personalization in Conversational AI: Conversational AI agents are advancing to provide more human-like interactions, including better understanding of natural language, emotional cues, and offering highly personalized user experiences.  
Developer Impact: Developers creating conversational interfaces must focus on incorporating these advanced NLP and personalization techniques to build more engaging and effective AI agents.  
Shift Towards AI-Native Development Infrastructure: The rapid generation of code by AI agents is prompting a re-evaluation of existing development platforms like GitHub and GitLab, which were primarily designed for human development speeds. This points towards a need for infrastructure that can better support AI-driven development rhythms.  
Developer Impact: Developers should anticipate changes in their toolchains and workflows, potentially including new platforms designed to handle the increased volume and velocity of AI-generated code and the unique review processes required.  

🚀 Top 5 Releases for Agent Developers  

Embabel Agent Framework: Launched by Spring founder Rod Johnson, Embabel is a new JVM-based, type-safe framework for building AI-powered applications, particularly for integrating Large Language Models (LLMs) with Java applications using Goal-Oriented Action Planning (GOAP).  
Developer Impact: Java developers now have a dedicated, high-level framework that emphasizes production-readiness, type safety, and advanced planning capabilities for creating sophisticated AI agents within the Spring ecosystem.  
Digitate's ignio™ Agentic AI Platform Update: Digitate announced a significant update to its ignio™ platform, introducing a suite of purpose-built AI agents aimed at IT operations, SREs, and CIOs to accelerate the move towards autonomous enterprise and ticketless IT operations.  
Developer Impact: Developers working on enterprise IT and business process automation can leverage these new agents to handle complex tasks more autonomously, improving efficiency and system resiliency.  
Digital Twin Consortium's AI Agent Capabilities Periodic Table (AIA CPT): The DTC launched the AIA CPT, an industry-first standardized framework for evaluating AI agent systems based on their actual capabilities, designed to reduce market confusion.  
Developer Impact: This framework provides developers with a clear, objective way to assess and compare different AI agent technologies and vendor offerings, aiding in technology selection and expectation setting.  
Google's Agent Development Kit (mentioned with Agentspace): Alongside its Agentspace hub for managing AI agents, Google has noted the availability of a new Agent Development Kit designed to help developers build AI agents.  
Developer Impact: Developers within the Google Cloud ecosystem can expect new and refined tools to streamline the creation and deployment of AI agents, fostering more sophisticated agent-based solutions.  
MetaGPT Framework Highlighted: Although an existing open-source framework, MetaGPT continues to be recognized for its capability in allowing multi-agent systems to automate complex software engineering tasks by encoding Standard Operating Procedures (SOPs) into LLM prompts.  
Developer Impact: Developers can utilize MetaGPT to create collaborative multi-agent systems for various development tasks, potentially improving efficiency in areas like game development, web development, and data analysis.  

🤔 Top 5 Questions from Agent Developers  

Determining When to Use AI Agents: Developers are actively discussing the appropriate use cases for AI agents, cautioning against over-engineering solutions with complex agents when simpler AI workflows or even manual intervention would be more efficient.  
Developer Impact: This highlights the need for developers to critically evaluate task complexity and ROI before committing to building an AI agent, ensuring the chosen solution fits the problem.  
Managing Repository Strategy in an AI World: There's ongoing debate about how to structure code repositories when AI agents are involved—whether smaller, focused repositories are better for AI comprehension or if larger, comprehensive ones provide necessary context.  
Developer Impact: Developers need to consider how their repository strategy impacts AI agent performance and collaboration, potentially adapting practices to include AI-generated artifacts like prompts.  
Addressing the Impact of AI on Team Dynamics: As AI tools create a potential "productivity divide" where some engineers significantly increase output, questions arise about how to maintain team cohesion, collaboration, and equitable workload distribution.  
Developer Impact: This requires a conscious effort from development teams and managers to adapt team structures and processes to integrate AI assistance smoothly and support all team members.  
Ensuring Architectural Consistency with Multiple AI Agents: A key concern is how to ensure that different AI agents, possibly working across various repositories or parts of a system, adhere to consistent architectural principles and design patterns.  
Developer Impact: Developers may need to establish clearer architectural guidelines for AI agents or develop new mechanisms to enforce consistency when employing multiple autonomous agents.  
Need for AI-Native Development Infrastructure: Developers are questioning whether current development platforms and their associated workflows (e.g., for code review) are adequate for the speed and volume of code that AI agents can produce.  
Developer Impact: This points to an upcoming need for developers to adapt to, and possibly help shape, new tools and platforms specifically designed for an AI-assisted and AI-native development lifecycle.

Step 3.3: Debugging

The adk web interface is your best debugging tool. On the "Events" tab, you can see every step your agent takes, including which tools it calls and what the LLM is thinking. If the output isn't right, your first step should always be to adjust the instructions in prompt.py.

Part 4 - Deployment

The adk deploy cloud_run command deploys your agent code to Google Cloud Run.

Ensure you have authenticated with Google Cloud (gcloud auth login and gcloud config set project ) and setup your environment variables to deploy your agent to cloud run with one line command.

Step 4.1: Setup environment variables

Optional but recommended: Setting environment variables can make the deployment commands cleaner.

# Set your Google Cloud Project ID  
export GOOGLE_CLOUD_PROJECT="your-gcp-project-id"  
# Set your desired Google Cloud Location  
export GOOGLE_CLOUD_LOCATION="us-central1" # Example location  
# Set the path to your agent code directory  
export AGENT_PATH="./trend_spotter" # Assuming capital_agent is in the current directory  
# Set a name for your Cloud Run service (optional)  
export SERVICE_NAME="trend-spotter-service"  
# Set an application name (optional)  
export APP_NAME="trend-spotter-app"

Step 4.2: Deployment to Cloud Run

adk deploy cloud_run \  
 - project=$GOOGLE_CLOUD_PROJECT \  
 - region=$GOOGLE_CLOUD_LOCATION \  
 - service_name=$SERVICE_NAME \  
 - app_name=$APP_NAME \  
 - with_ui \  
$AGENT_PATH

(more options for Cloud run deployment can be found here)

Step 4.3: Testing your deployed agent

You can test your agent by simply navigating to the Cloud Run service URL provided after deployment in your web browser. (The URL should be similar to this: https://your-service-name-abc123xyz.a.run.app)

Part 5: Next Steps and Conclusion

Congratulations! You have successfully designed, built, tested and deployed your very first AI agent using the Agent Development Kit.

You've learned how to structure a proper agent package, how to write a detailed prompt to control an agent's logic, and how to run and interact with your agent using the adk web interface. We now have a working "researcher" for our AI agent podcast and you you now have a working foundation that you can expand upon. Try modifying the prompt to research a different topic, or explore adding new custom tools to give your agent more capabilities.

In our next post, we'll continue to build on this foundation and make our agent even more powerful by adding richer, more specialized tools.

When you're ready to dive deeper and explore all the powerful features the framework has to offer, the best place to go is the official Google Cloud ADK documentation.

Happy building!

What is harness engineering and why should I care?

Shir Meir Lador — Wed, 02 Sep 2026 15:28:05 +0000

How do you ship a software product with 0 lines of manually-written code?

A friend asked me this today, and I realized I didn't have a simple answer. So I dug deeper.

It turns out the answer is in how you engineer your harness.

Wait now, what? What is harness engineering?

There is a reason this is the most important trend right now around coding agents. The biggest question these days is how to validate AI-generated code without reading every single line. How do you make sure an agent doesn't break production or delete your data?

A blog by OpenAI shared an interesting experiment where a team of 3 engineers have built and shipped an internal beta of a software product with 0 lines of manually-written code. Every line of code: application logic, tests, CI configuration, documentation, observability, and internal tooling, has been written by Codex.

How did they do it? They didn't write the app. They designed the harness.

What exactly is a harness?

Think of an AI agent like a powerful racehorse. The harness is the track, the blinders, and the jockey's reins that keep it running in the right direction instead of jumping into the stands.

As my colleague Arthur Thompson explained today: for agents — the harness is composed of all the deterministic components that wrap the LLM.

Balaji Subramaniam details those deterministic components in his blog — the orchestration layer, execution sandboxing, state persistence, and verification tools.

If you want to build reliable agentic systems, your job shifts from writing the logic to designing the environment. Here is what you need to focus on:

Set strict boundaries: Don't let the agent guess what it can touch. Enforce strict access rules (like confining it to a specific sandbox) so it can't accidentally wipe out production data.
Build "Repair Loops": Agents will inevitably make mistakes. A great harness automatically traps errors, like a failed build or a test failure, and feeds those clean logs right back to the agent so it can fix its own code.
Give them a map, not a manual: As the OpenAI team discovered, don't overwhelm the agent with massive instruction files. Structure your repository logically so the agent can discover context progressively as it works.

Show me the code

What does this look like in practice? Here is a simple example using the Google Antigravity SDK with Google's ADK to configure a local harness. Notice how we are strictly bounding the agent to a specific workspace (workspaces=["./sandbox"]) and giving it a place to save its memory (save_dir="./trajectories" ) so it can learn from previous experience:

import os
from google.adk.labs.antigravity import AntigravityAgent
from google.antigravity import LocalAgentConfig
from google.antigravity.hooks import policy

# Ensure absolute paths for workspace containment
sandbox_dir = os.path.abspath("./sandbox")
os.makedirs(sandbox_dir, exist_ok=True)
save_dir = os.path.abspath("./trajectories")

# 1. Engineer the harness environment
sdk_config = LocalAgentConfig(
    system_instructions="You are a helpful local environment assistant.",
    workspaces=[sandbox_dir],
    # Let the agent write safely within the restricted sandbox boundary
    policies=[policy.allow_all()],
    save_dir=save_dir,
)

# 2. Wrap the config to run the agent inside the harness
root_agent = AntigravityAgent(
    name="antigravity_assistant",
    description="Runs an Antigravity SDK agent inside ADK.",
    config=sdk_config,
)

The policy keeps the agent access only in the Sandbox folder

With this design in place, you can drop your legacy code into the sandbox, write a simple loop to run unit tests against it, and let the agent iteratively fix its own bugs.

Adding Tests

So, how do we actually run tests against this sandboxed agent?

In modern harness engineering, tests are an active part of the agent's workflow graph. Using Google's ADK 2.0, which introduces graph-based workflows, you can define a test validation step as a simple routing node.

If the test passes, the job is done. If it fails, the harness automatically loops the error back to the agent to try again. Notice the built-in 'kill switch': we track the iteration count so if the agent gets stuck in an infinite loop of breaking and fixing code, the harness safely pulls the plug.

from google.adk.agents.context import Context
from google.adk import Event
from google.adk.events.event_actions import EventActions
from google.genai import types

# 3. Evaluate the code in the sandbox
def execution_test_node(ctx: Context):
    # Safely track our attempts to prevent infinite loops
    iteration_count = ctx.state.get("iteration_count", 0) + 1
    ctx.state["iteration_count"] = iteration_count

    test_passed = ctx.state.get("test_passed", False)
    feedback = ctx.state.get("feedback", "")

    if test_passed:
        # Success! End the workflow.
        return Event(actions=EventActions(route="END"))

    if iteration_count > 5:
        # The Kill Switch: The agent is stuck. Stop the loop.
        return Event(actions=EventActions(route="END"))

    # Failure! Feed the error trace back to the agent and loop it.
    feedback_msg = f"The unit tests failed with the following traceback:\n\n{feedback}"

    return Event(
        content=types.Content(role="user", parts=[types.Part(text=feedback_msg)]),
        actions=EventActions(route="loop_back")
    )

If you want to see this test routing pattern in action, you can check out an example with a full implementation in Balaji's ADK harness repository.

Wiring it all together using graph-based workflow

To connect the agent and the test node, you can use a Workflow graph to map out exactly how the execution should flow without needing complex, nested Python while loops.

Think of this as drawing the actual lanes on the racetrack:

from google.adk import Workflow

# 4. Wire the agent and the test node together into a loop
repair_loop = Workflow(
    name="repair_loop",
    edges=[
        # 1st Step: Define the main sequence (START -> agent -> test node)
        ("START", root_agent, execution_test_node),

        # 2nd Step: If the test returns "loop_back", go back to the agent
        (execution_test_node, {"loop_back": root_agent})
    ]
)

The test loop

Congratulations! you've built an autonomous system. The agent writes the code and hands it off to the test node. If the test fails and returns a loop_back route, the agent tries again with the error log in hand.

See more examples of loop patterns in ADK samples.

Try it yourself

You might wonder why you need a Python script to run an agent. In a normal chat window, you are the harness: you copy the error logs and babysit the model. A software harness lets the system babysit itself, allowing you to fully automate test-driven coding or safely refactor massive legacy codebases.

To run this self-healing loop on your own machine today, the setup takes less than five minutes:

Install the framework: Run pip install "google-adk[antigravity]" in your terminal to get the open-source Agent Development Kit and the Antigravity integration.
Set your API key: Grab a free Gemini API key from Google AI Studio and export it to your environment (export GEMINI_API_KEY="your-key").
Run the loop: Save the code blocks above as a Python script, drop a broken Python or Node file into your new ./sandbox directory, and run your script.
Expand your graph: Unit tests are just the baseline. To make your harness bulletproof, add a second AI agent to your workflow, like a SecurityAuditor, to review the code before it passes, or wire in custom linters to enforce strict architectural rules.

From there, you can swap out our simple test node for a subprocess that actually executes pytest or npm test against your sandbox, and you will have a fully functioning repair loop.

If you are ready to scale this up, you can download the full IDE and CLI at antigravity.google, explore the Antigravity managed agent for remote execution and google's ADK 2.0 for using graph based workflows.

Google Cloud Labs: Accelerate AI with Cloud Run

Shir Meir Lador — Tue, 21 Jul 2026 13:00:00 +0000

Moving Beyond the Prototype

The AI landscape has shifted. While "vibe coding" with tools like Antigravity and AI Studio lets you build and deploy complex agents in minutes, the real work begins on "Day 2". Moving from a magical prototype to a hardened, production-grade application requires professional AI engineering. We're excited to bring back the Accelerate AI with Cloud Run roadshow for 2026. This year, we've updated our curriculum to focus on the full AI agent lifecycle, giving you the keys to productionizing and scaling agentic workloads on Google Cloud's serverless platform.

The Coffee Shop Journey: A Hands-On Experience

Experience the ease of building advanced AI agents on Cloud Run through 'The Coffee Shop Journey'. This interactive session is designed to guide you through the full lifecycle of an AI agent, moving beyond prototyping to focus on real business use cases. You will solve real-world business problems as you evolve from launching a simple cafe to building complex, intelligent assistants.

Our curriculum covers the core pillars of modern AI development:

The Basics: Gain familiarity with Cloud Run by deploying a simple web app (a Coffee Shop launch scenario) to understand the platform fundamentals.
Build a Coffee Recommendation Agent: Create a personalized AI assistant using Google's Agent Development Kit (ADK) and Retrieval-Augmented Generation (RAG).
Optimize Coffee Stand Locations: Use Gemma 4 and the BigQuery MCP server to identify the most profitable locations for new coffee stands by analyzing popular bike routes.
Personal Productivity Assistant for Store Managers: Create a personal productivity assistant using Cloud Run to help a coffee shop manager with daily operational tasks and scheduling.
Master Advanced Features with Antigravity 2.0: Learn how to use skills, context, rules, and hooks with Antigravity 2.0 to build new features for your Cloud Run applications.

Production-Grade AI on Cloud Run

Get first-hand experience with the platform innovations that make Cloud Run the ideal home for production-grade agentic workloads. Through hands-on exercises, you will learn to build, scale, and orchestrate long-running agents using Google's ADK and Antigravity 2.0. Additionally, you will utilize BigQuery MCP for automated, data-driven expansion strategies, and experience low-latency inference for frontier models using Cloud Run's GPU offerings without the traditional overhead of cluster management.

Ready to Build for Scale? Join us in North America

Don't just witness the AI revolution - build it. Find the workshop in your city and secure your spot today! Let's transform your AI journey from a simple prototype into a powerful, production reality.

City	Date	Registration Link
Atlanta, GA (as a part of Atlanta Tech week)	August 12-13	https://www.renderatl.com/tickets Event tickets grant access to the workshops on a first-come, first-served basis.
Sunnyvale, CA	August 13	Register now!
Toronto, Canada	August 27	Register now!
Seattle, WA	September	Registration opens late July!
New York City, NY	October	Registration opens late July!
Los Angeles, CA	November	Registration opens late July!
Boston, MA	October	Registration opens late July!
Washington D.C.	October	Registration opens late July!

Registration Update: Links for our September, October, and November workshops will be added to this page in late July. Stay tuned!

Agent Factory Recap: 100X engineering with AI agents in Google Antigravity 2.0

Shir Meir Lador — Tue, 07 Jul 2026 17:28:25 +0000

In this episode of the Agent Factory, I sat down with Rody Davis, one of Google's top agentic engineers. We dive into the massive shift from traditional IDEs to agent-first platforms, the reality of code reviews in an AI-driven world, and how to use "skills" to perform at a 100X level.

This post guides you through the key ideas from our conversation. Use it to quickly recap topics or dive deeper into specific segments with links and timestamps.

Google Antigravity 2.0 - What is it?

Antigravity 2.0 has evolved from a simple agentic IDE into a full-scale agent-first platform. It now consists of four core pillars: a standalone desktop Agent Manager for orchestration, a robust CLI for server-side work, an SDK for custom Python-based workflows, and a specialized IDE. This unbundled approach allows developers to compose their own environment, managing multiple folders and complex project structures without being forced into a single-workspace layout.

Rody Davis on 100X Engineering

We explored the strategies elite engineers use to scale their impact and reduce the "cognitive toil" of daily development.

Scaling Impact and Reducing Toil

Timestamp: 01:55

Rody explains that AI isn't just about writing code; it's about accelerating the entire lifecycle. He uses agents to write richer test suites and prototype multiple versions of an app before committing to a framework. By offloading "toil", like building marketing sites, he can focus on high-level architecture and problem-solving.

Skills as "Context Cheat Sheets"

Timestamp: 03:05

A core philosophy in Rody's workflow is the use of "Skills." He views skills as a way to compress context for the model. "It's literally a cheat sheet for the agent," Rody notes. By providing the agent with specific design systems or API documentation, the model becomes significantly faster and more accurate, avoiding the latency of searching through massive, unorganized docs.

Customizations, Skills, and MCP Servers

Timestamp: 04:17

Rody walks us through the customizations tab in Antigravity 2.0, showing how to extend an agent's capabilities:

Android CLI: Building and deploying mobile apps directly from the command line.
Modern Web Guidance: Grounding the agent in the latest CSS and accessibility standards.
MCP Servers: Using the Model Context Protocol to enable features like hot reloading for Flutter and Dart.

The Bonsai Approach to Code Review

Timestamp: 05:27

Rody compares maintaining a codebase to being a Bonsai artist: constantly pruning to keep things simple. He advocates for flat architectures where state, UI, and data are strictly separated. This makes it easier for a human to "steer" the agent; if the agent starts putting files in the wrong place, the architectural violation is immediately obvious.

Do you review 100% of agent-generated code?

Timestamp: 07:11

Rody's answer depends on the task. For a marketing site, he focuses on the visual output rather than the code. However, for backend logic, he cares deeply about API contracts and schemas. He recommends writing the first example yourself so the agent can simply "copy the pattern" for the rest of the codebase.

Building Extensions to Solve Daily Friction

Timestamp: 09:05

To solve the problem of managing files across multiple Git projects, Rody used Antigravity to build a custom macOS Finder extension in Swift. This tool allows him to filter files by time boxes (today, last week, etc.), demonstrating how agents can build specialized utilities that reduce daily friction.

Do AI engineers still write code by hand?

Timestamp: 10:22

"Oh yeah," Rody says. He still loves the syntax of languages like Go and the challenge of controlling computers. He believes it's vital to understand the building blocks deeply so that when you face a problem two years down the road, you know exactly which "old project" to reach back for.

Powering Personal Websites with Gemma 4

Timestamp: 11:42

Rody showcases his personal website, which uses Gemma 4 and Embedding Gemma to provide dynamic content recommendations offline. By vectorizing post summaries at compile time, the site can suggest related content via a local vector database without needing a live backend server.

The Factory Floor

The Factory Floor is our segment for getting hands-on. Here, we moved from high-level concepts to practical code with live demos.

Multi-Agent Parallelism in Action

Timestamp: 14:02

In this demo, Rody uses a single stream-of-thought voice prompt to build a full-stack application. We watched as Antigravity:

Spun up parallel sub-agents, including a dedicated DevOps and QA engineer. (see 19:48)
Built a multilingual note-taking app using Vite, Go, and SQLite.
Orchestrated the entire stack via Docker Compose.
Localized the app into five different languages simultaneously.

Unbundling the IDE Ecosystem

Timestamp: 15:35

We discussed why Google separated the IDE from the Agent Manager. Rody highlights that this unlocks different workflows: the CLI is perfect for SSH sessions on a Raspberry Pi, while the Agent Manager handles general knowledge work and orchestration across multiple folders.

Turning Documentation into Reusable Skills

Timestamp: 25:41

Rody shares his process for turning documentation into skills. He wrote a Go CLI that parses websites into markdown, allowing him to install hundreds of skills for the sites he visits frequently. This ensures the agent always has access to the specific version of the docs he is using.

Rapid Fire: Future Tech Predictions

Timestamp: 27:35

We put Rody on the spot with some controversial takes:

Vibe Coding: Rody believes a non-technical founder will launch a company using only vibe coding by 2026, but the real test will be maintaining it in years 2 through 5.
Production Failures: Rody agrees that vibe coding will cause significant production failures, leading to a new hot job for software engineers: consulting to solve those failures.
Codebase Health: Rody argues that poor codebase health, not context windows, is the biggest bottleneck in AI speed.

Grounding Yourself in a Changing Landscape

Timestamp: 31:10

Rody advises engineers to focus on why they were hired: to solve problems and engineer things that didn't exist before. He suggests using AI to provide better communication handoffs between colleagues, making artifacts so easy to approve that they are "ready to sign off" the moment they are handed over.

Conclusion

The era of agentic engineering is here, but as Rody Davis demonstrated, it requires more architectural discipline, not less. By treating your codebase like a Bonsai tree and your agents like an orchestra, you can move past the "toil" and focus on building the frameworks of the future.

Your turn to build

Are you ready to build anything? We've officially launched the #NapkinChallenge. Take a handwritten sketch of an app idea, use Antigravity 2.0 to build it, and share your creation on social media.

Try Antigravity 2.0: antigravity.google
Join the Challenge: Napkin Challenge Details
Rody's personal website, github repo and skills

Connect with us

Rody Davis → X, LinkedIn
Shir Meir Lador → X, LinkedIn

A Guide to AI Cold Starts on Cloud Run

Shir Meir Lador — Fri, 26 Jun 2026 16:50:58 +0000

I saw a developer asking on Reddit if there was any “sane way” to manage Cloud Run cold starts for AI across multiple regions. They were experiencing startup latencies of up to 20 seconds, a frustrating gap where the infrastructure is spinning up while the user waits for a response.

The discussion was full of developers who had almost given up on serverless GPUs, with some even migrating back to GKE just to escape the latency. I decided it was time to dive deep into the Mechanics of AI Cold Starts and see if we could find that "sane way."

During my research into hosting models like Gemma 4 on Cloud Run, I had the privilege of co-presenting at Google Cloud Next '26 with Oded Shahar (Senior Engineering Manager for Cloud Run) and our guest speaker Ajay Nair (Global VP of Platform at Elastic).

In our session, "Build AI architectures with custom models on Cloud Run," Ajay shared the production-hardened strategies that allow Elastic to serve millions of daily requests across 17+ model variants, all while maintaining the 'scale-to-zero' efficiency of Cloud Run.

Build AI architectures with custom models on Cloud Run

Ajay showed us that the secret isn't just in the model, but in treating GPUs as fungible compute rather than infrastructure to manage.

I realized then that minimizing cold start latency isn't just about the model, it's about the infrastructure patterns and architectural decisions that keep it fast, scalable, and secure.

The anatomy of an AI cold start

As the official Google Cloud GPU best practices explain, an AI cold start is a shift from standard web microservices. You aren't just booting code, you're moving gigabytes of weights into a specialized physical accelerator.

Think of it as a four-phase race. If you don't optimize each step, you're going to lose your users.

Phase 1: Infrastructure Provisioning (~5s)

Cloud Run allocates the physical GPU and injects pre-installed NVIDIA drivers. Since Google manages the drivers for you, you don't have to bloat your Dockerfile.

Phase 2: Block-Level Container Image Streaming (1-2s)

Cloud Run uses "image streaming," meaning it pulls only the blocks needed to boot. Your 15GB CUDA image can actually start as fast as a tiny Node.js app!

Phase 3: Engine Initialization (5-15s)

This is where your inference engine (vLLM, Ollama) warms up. This is a massive CPU-heavy task, and it's where most people get throttled without realizing it.

Phase 4: Model Loading & VRAM Transfer

This is the final hurdle - moving those model weights from storage into the GPU memory. Unlike standard web apps where CPU is king, GPU memory is your primary constraint here. If your model’s weights don’t fit entirely within the GPU memory, performance degrades significantly as it swaps to slower system RAM.

Best practices to handling AI cold starts

To build a "sane" production environment, here are a few crucial levers you can pull, informed by the official Google Cloud documentation on AI inference with GPUs.

Optimize Phase 4

Pick the Right Deployment Option

Phase 4 is the "final hurdle" where you move gigabytes of weights from storage into GPU memory. Your choice of storage determines how fast this transfer happens:

Cloud Storage (Concurrent Download) - Fastest: Using the Google Cloud CLI (gcloud storage cp) allows you to download model files in parallel. This is the recommended method for massive weights because it maximizes network throughput and drastically reduces transfer time.
Cloud Storage (FUSE) - Easiest: This provides "zero-code" changes by mounting a bucket as a local file system. However, because it does not parallelize the initial download, it is significantly slower for large model weights
Container Image - Best for <10GB: Baking weights into your image is efficient for smaller models thanks to Cloud Run's Image Streaming. For models over 10GB, however, the import and streaming overhead can become a bottleneck.
Internet: Avoid this. It is the slowest and least predictable path for production inference.

Model Format & Size

Optimizing your model's format and size is a direct "hack" to shorten Phase 4 (Model Loading & VRAM Transfer). Because this phase is constrained by how fast you can move gigabytes of data into VRAM, smaller and more efficient files are critical.

4-bit Quantization: This is the ultimate cold start hack. Smaller weights mean fewer gigabytes to pull from storage, which directly accelerates the download and transfer portion of Phase 4,
Fast Formats: Pick a model format with fast load times like GGUF to minimize startup time. For the fastest performance, move away from Python "pickle" files and use Safetensors for zero-copy loading.
Ensure VRAM Fit: Use quantized models to ensure the weights fit entirely within the GPU memory. If the model exceeds VRAM, Phase 4 will stall as the system swaps to significantly slower RAM.

Optimize Phases 3 & 4: Infrastructure & Network Levers

These infrastructure settings provide the necessary resources to accelerate the most demanding parts of the startup process.

Startup CPU Boost (Accelerates Phase 3)

This feature temporarily doubles your CPU power during startup. A 1 vCPU instance boosts to 2 vCPUs for the duration of startup and the first 10 seconds of serving. It is essential for Phase 3, as engine initialization is a massive CPU-heavy task.

Direct VPC Egress & PGA (Accelerates Phase 4)

Utilizing Direct VPC Egress with Private Google Access (PGA) ensures your model weight traffic stays on Google’s internal high-speed backbone. This optimizes the network path to shorten the time spent moving gigabytes of weights into VRAM.

Concurrency Tuning (Cold Start Avoidance):

In Cloud Run, "concurrency" refers to the maximum number of requests a single instance can handle before the platform scales out to start a new one. For AI workloads, you must tune this setting in tandem with your model engine's internal parallelism flags (e.g., --max-num-seqs for vLLM or OLLAMA_NUM_PARALLEL for Ollama).

Use the official Google Cloud formula to find your ideal Cloud Run concurrency:

(Number of model instances∗parallel queries per model)+(number of model instances∗ideal batch size)

Example: If your instance loads 3 model instances onto the GPU, and each model instance can handle 4 parallel queries with an ideal batch size of 4, you would set your Cloud Run maximum concurrent requests to 24: (3×4)+(3×4)

How the math works: The goal is to keep the GPU fully saturated while ensuring users aren't stuck in a long queue. In this example, the total of 24 concurrent requests is split into two functional groups:

Active Processing (12 requests): Calculated as (3 instances×4 queries), this represents the total number of requests the GPU can actively process at any given moment.
The "Next Batch" Buffer (12 requests): Calculated as (3 instances×4 batch size), these are the requests waiting "on deck" inside the container. As soon as the GPU finishes the first batch, it immediately picks up these waiting requests.

By tuning this value as high as your VRAM allows (usually 10-20 users), one warm instance can serve many requests without triggering a new scale-out event and the cold start that comes with it.

Scaling Controls (Tuning the Threshold)

While the formula above defines your maximum capacity, you can also tune when Cloud Run decides to start the next instance. Cloud Run's autoscaler typically targets 60% utilization, but for long-running AI cold starts, you can increase this threshold to 80% or 90% via Scaling Controls.

Concurrency Target: Increasing this allows you to "pack" more requests into a single warm instance before triggering a scale-out.
CPU Target: Increasing the CPU target prevents the platform from starting a new instance just because initialization or high-intensity inference spiked the CPU utilization.

Scaling & Reliability Strategies

Sometimes the best way to handle a cold start is to avoid it entirely or manage it proactively.

The Single-Region "Always-On" Tradeoff

If you are deploying globally, the cost of keeping minimum instances set to 1 in every region adds up. Instead, consider an 'always-on' service in just one region. A 100ms global network delay is a much better user experience than a 20s local cold start.

The 15-Minute Grace Period: A common question is 'How long will my instance stay warm after a request?' Cloud Run generally keeps instances alive for 15 minutes after they become idle (processing zero requests). If your traffic is predictable and comes in every 10–12 minutes, you might not even need an 'always-on' service, the platform’s default shutdown policy will keep a warm instance ready for your next user.

Note: While this idle time is "free" for standard request-based services, remember that GPU services require instance-based billing, so you will be billed for the duration the instance remains warm between requests.

The "Wake-Up Call" Strategy

Sometimes the best way to handle a cold start is to proactively mask it. If your UI can predict an upcoming request, for example, when a user clicks "New Chat" or begins hovering over a text area, you can send a lightweight health check to your service immediately. By the time the user finishes typing their prompt, the first two phases of the cold start (Infrastructure Provisioning and Container Image Streaming) are already finished in the background.

Pro-Tip: Use Non-Inference Endpoints To make this "wake-up call" as fast as possible, always use a non-inference endpoint rather than sending a dummy prompt like "hi".

Why it’s faster: Non-inference endpoints (like /v1/models for vLLM or /api/tagsfor Ollama) are handled by the container’s web server the moment it starts. They don’t have to wait for the slow "Phase 4" model loading and VRAM transfer to complete before sending a success response.
No Chat Pollution: Because these endpoints don't trigger the model's completion logic, they won't interfere with the user's actual chat history or accidentally trigger session creation in your backend.

Recommended Endpoints:

vLLM: GET /health or GET GET /v1/models
Ollama: GET /api/tags or GET /api/version

Tune Startup Probes for VRAM

AI models take significant time to move gigabytes of weights from storage into GPU memory (Phase 4). If your startup check fails too many times, Cloud Run will assume your container is broken and kill it.

To prevent this:

Increase the Failure Threshold: Use a high failureThreshold (e.g., 60 or more). Since the total allowed startup time is the product of failureThreshold \times periodSeconds, a threshold of 60 with a 5-second period gives your model a healthy 5-minute window to load.
Utilize the 30-Minute Maximum: While standard services are limited to 4 minutes, Cloud Run supports a total startup time of up to 30 minutes (1,800 seconds) for intensive workloads.
Avoid False Positives (The Ollama Fix): Be careful with engines like Ollama, which may open a TCP port as soon as the service starts, but before the model is actually in VRAM. Always ensure you are preloading models during the container's entrypoint script to ensure the startup probe only passes once the model is truly ready for inference.

Lessons from Elastic’s strategy

In our NEXT ‘26 session, Ajay Nair highlighted three architectural decisions that allowed Elastic to treat GPUs as fungible compute, rather than infrastructure to manage:

Bypass the Compilation Tax: By setting enforce_eager=True in vLLM, they traded a tiny bit of throughput for cold starts that finish in less than a minute rather than multiple minutes.
Standalone Checkpoints: They avoided the latency of runtime adapter-switching by pre-merging each LoRA variant into a standalone checkpoint.
One Workload, One Service: Each independently-scalable workload — defined by model, task adapter, and traffic shape — is deployed as its own Cloud Run service. This produces 30+ services across ~15 model families, with some models split by task (e.g., v5 retrieval vs. clustering) or by query/passage role.

Ready to get started?

Optimizing the cold start process is the difference between a hobby project and a production-ready application. The best part? Cloud Run handles the NVIDIA driver and CUDA installation for you, starting the instance in about 5 seconds.

For a deeper dive, the official documentation is your best friend:

For the full technical breakdown, I highly recommend watching the recording of the session from Google Cloud Next '26. It provides the most comprehensive blueprint for hosting high-performance open models on serverless infrastructure.

Happy building!

Special thanks to Sara Ford and Shane Ouchi from the Cloud Run team and to Zac Li from Elastic for the helpful review and feedback on this article.

Can Google Antigravity 2.0 Pass the "Napkin Challenge"? 📝🚀

Shir Meir Lador — Wed, 27 May 2026 00:02:51 +0000

🚀 From Napkin Sketch to data-driven real-estate advisor Agent in Under 40 Minutes? 🚀

Can a coding agent really work autonomously on complicated problems without human intervention? I decided to put Google’s new Antigravity 2.0 and Gemini 3.5 to the test: The Napkin Challenge. 📝

The goal: Build and deploy a real estate investment advisor - based on real-world data, starting with nothing but a rough sketch on a napkin.

The Result? With the right context, yes!

I used:
Antigravity 2.0 & Gemini 3.5: Architect and execute the plan
Agent CLI Skills: Scaffold, build, test and evaluate the agent using ADK.3
Developer Knowledge MCP: Provided necessary context to connect to BigQuery MCP and integrate the census dataset for grounded investment advice.
Parallelized Workflow using sub-agents: While the system ran the evaluation suite, it simultaneously deployed the agent to Cloud Run.

The Outcome:

Built and deployed in under 40 minutes.
Zero human input beyond a napkin sketch (other than approving the plan and setting the model and region).
100% passing scores on evaluation cases, with responses delivered in under 30 seconds.
A fully functional real estate advisor providing data-driven analysis on short and long term investments.

The "Napkin Challenge" proves that when you combine the right context with powerful models, the barrier between an idea and a deployed product has virtually disappeared.

I challenge you: What is your "napkin" project? Try it with Antigravity 2.0 and Gemini 3.5. 📝

🚀 How to join the challenge -

Sketch an architecture or app idea on a literal napkin.
Feed it to Antigravity 2.0 + Gemini 3.5. (I recommend making sure you have relevant skills in place for the task - context makes all the difference!)
Drop a quick video or screenshot of your results on socials with the hashtag #NapkinChallenge.
Add the link to your demo in the comments to this post!
Tag 3 other folks and give them 48 hours to match the challenge! 👇 What will you build? Let me know in the comments!

Agent Factory Recap: How Gemma 4 Taught Itself Physics

Shir Meir Lador — Thu, 14 May 2026 14:10:49 +0000

In this episode of The Agent Factory, Vlad Kolesnikov and I sat down with Omar Sanseviero from the Developer Experience team at Google DeepMind. We explored the groundbreaking release of Gemma 4: a new family of open models designed to bring high-level intelligence and agentic capabilities directly to consumer hardware and mobile devices. Since the launch last month, Gemma 4 had over 50 million downloads!

This post guides you through the key ideas from our conversation. Use it to quickly recap topics or dive deeper into specific segments with links and timestamps.

Gemma 4 - What is it?

Gemma 4 is the latest generation of open models from Google DeepMind, built on the same foundational research as Gemini 3. The family is designed to deliver exceptional "intelligence per parameter" across a range of deployment scenarios, from mobile phones to powerful workstations. The Gemma 4 model family now spans three distinct architectures:

Small Sizes (E2B & E4B): Optimized for ultra-mobile, edge, and browser deployment (such as Pixel or Chrome).
Dense (31B): A powerful 31-billion parameter model that provides server-grade performance for local execution on consumer GPUs.
Mixture-of-Experts (26B MoE): A highly efficient architecture designed for high-throughput tasks and advanced reasoning.

With the shift to an Apache 2 license, these models provide developers and startups with the flexibility to build, modify, and commercialize applications while maintaining full control over their infrastructure.

Omar Sanseviero on how Gemma 4 changes the landscape for agent developers

Timestamp: 1:40

Omar highlighted that Gemma 4 brings "very high intelligence per parameter," making it possible to run agentic workflows entirely offline. We saw examples of multiple Gemma instances running locally to generate SVGs (1:53) and an Android-based agent picking specific skills, like playing the piano, to complete tasks (2:45). As Omar noted, "This means that you can run very powerful things with very little hardware overhead...even in the phone that you have in your pocket."

The Factory Floor

Building a Local Food Tour Agent

Timestamp: 5:29

We showcased a food tour agent powered by Gemma 4 using the Agent Development Kit (ADK) and a Google Maps MCP server. We demonstrated how a local model can handle complex, multi-step reasoning tasks.

The agent identified the best ramen spots in Seattle under a $30 budget.
It verified that the locations were within walking distance of each other.
It processed search results to provide specific tips on what to order and what to avoid.

Autonomous Python Code Execution

Timestamp: 8:03

In this demo, we pushed Gemma 4's coding capabilities to the limit by asking it to express itself through animation. Using a sandbox execution environment, the model performed the following:

Wrote Python code using the Matplotlib library.
Attempted to build a physics engine to simulate a bouncing ball.
Self-corrected when the initial execution environment lacked certain CPU features, finding an alternative path to successfully generate the animation.
Demonstrated a deep understanding of real-world physics and gravity through code.

The Shift to Apache 2 Licensing

Timestamp: 4:05

A major theme of the conversation was the community-driven decision to move Gemma 4 to an Apache 2 license. This change provides developers and startups with maximum flexibility to build, modify, and commercialize applications. Omar emphasized that this was a direct response to developer feedback, aiming to unlock a new wave of innovation in the open models ecosystem.

Developer Q&A

Architectural Decisions and Mixture of Experts (MoE)

Timestamp: 17:23

Omar explained the technical shifts that make Gemma 4 so efficient. For the first time, the Gemma family includes a Mixture of Experts (MoE) architecture, which optimizes for extremely low latency in production. Additionally, the smaller E2B and E4B models utilize per-layer embeddings to remain "cheap" to run on GPUs. For vision tasks, the model now supports variable aspect ratios, allowing it to understand images of various sizes more accurately than previous fixed-resolution versions.

Comparing Gemma to Gemini

Timestamp: 19:51

When asked how Gemma stacks up against its larger sibling, Gemini, Omar clarified that they serve different purposes. While Gemini excels at massive-scale tasks and deep "world knowledge" due to its size, Gemma is the "best open model that can run on a single consumer GPU." It is specifically optimized for instruction following, coding, and agentic use cases where local deployment or fine-tuning is required.

Fine-Tuning for Specialized Industries

Timestamp: 21:10

The conversation touched on the importance of "Sovereign AI" and privacy. Because Gemma is an open model, developers in regulated industries, like healthcare or finance, can fine-tune the model on their private data and deploy it within their own air-gapped infrastructure. This gives developers full control over their data and the model's specialized expertise.

Conclusion

Gemma 4 marks a turning point for agentic development, proving that you don't always need a massive cloud cluster to build something smart. Whether it's running a physics simulation on a laptop or a travel guide on a phone, the barrier to entry for high-performance AI has never been lower. We are entering an era where the "conductor" of the AI orchestra can be any developer with a single GPU and a great idea.

Your turn to build

Now that you've seen what Gemma 4 can do, it's time to start building. Check out the resources in our show notes, the food tour agent, the coding agent, explore the ADK support, and try running Gemma 4 on your local machine or on Cloud Run. We can't wait to see what agents you create!

Watch more of The Agent Factory → Reinforcement learning & fine-tuning on TP...

Subscribe to Google Cloud Tech → https://goo.gle/GoogleCloudTech

Connect with us

Shir Meir Lador → LinkedIn, X
Vlad Kolesnikov → LinkedIn, X
Omar Sanseviero → LinkedIn, X

Deploying a Multi-Agent System with Terraform and Cloud Run

Shir Meir Lador — Thu, 07 May 2026 21:04:12 +0000

In support of our mission to accelerate the developer journey on Google Cloud, we built Dev Signal: a multi-agent system designed to transform raw community signals into reliable technical guidance by automating the path from discovery to expert creation.

In the first three parts of this series, we laid the essential groundwork by establishing its core capabilities and local verification process:

In part 1, we standardize the agent's capabilities through the Model Context Protocol (MCP), connecting it to Reddit for trend discovery and Google Cloud Docs for technical grounding. In part 2, we built a multi-agent architecture and integrated the Vertex AI memory bank to allow the system to learn and persist user preferences across different conversations. In part 3, we verified the full end-to-end lifecycle locally using a dedicated test runner to ensure that research, content creation, and cloud-based memory retrieval were perfectly synchronized.

If you'd like to dive straight into the code, you can clone the repository here.

Deployment to Cloud Run and the Path to Production

To help you transition from this local prototype to a production service, this final part focuses on building the production backbone of your agent using the foundational deployment patterns provided by the Agent Starter Pack. We will implement the essential structural components required for monitoring, data integrity, and long-term state management in the cloud. You will learn to implement the application server and helper utilities needed for a production-ready deployment before provisioning secure, reproducible infrastructure with Terraform.

While the Dockerfile packages your agent's code and its specialized dependencies, such as Node.js for the Reddit MCP tool, Terraform is used to build the platform it lives on. Terraform automates the creation of your Artifact Registry, least-privilege service accounts, and Secret Manager integrations to ensure your API keys remain protected.

By the end of this part, you will have a standardized application framework deployed on Google Cloud Run and a roadmap for graduating your prototype through continuous evaluation, CI/CD and advanced observability.

Production Utilities and Server: Building the System's Body

In this section, you implement the structural components required for monitoring and long-term state management in the cloud.

The Application Server: Initializing the FastAPI server and establishing a vital connection to the Vertex AI memory bank.
Implementing Telemetry: Enabling 'Agent Traces' for visibility into internal reasoning.

The Application Server

The fast_api_app.py file serves as the vital entry point for your agent, transforming the core logic into a production FastAPI server that acts as the "body" of your system. When deploying to Cloud Run, this server is essential because it provides the necessary web interface to listen for incoming HTTP requests and dispatch them to the agent for processing. Beyond basic serving, its most critical role is establishing a connection to the Vertex AI memory bank by defining a MEMORY_URI, which allows the ADK framework to persist and retrieve user preferences across different production sessions. Additionally, the application server initializes production-grade telemetry for real-time monitoring.

Go back to the dev_signal_agent folder.

cd ..

Paste the following code in dev_signal_agent/fast_api_app.py:

import os
from fastapi import FastAPI
from google.adk.cli.fast_api import get_fast_api_app
from google.cloud import logging as cloud_logging
from vertexai import agent_engines
from dev_signal_agent.app_utils.env import init_environment

# --- Initialization & Secure Secret Retrieval ---
# We now unpack the SECRETS dictionary returned by our updated env.py
PROJECT_ID, MODEL_LOC, SERVICE_LOC, SECRETS = init_environment()
logger = cloud_logging.Client().logger(__name__)

# Access sensitive credentials from the SECRETS dictionary
# These keys stay in memory and are NOT injected into os.environ
REDDIT_CLIENT_ID = SECRETS.get("REDDIT_CLIENT_ID")
REDDIT_CLIENT_SECRET = SECRETS.get("REDDIT_CLIENT_SECRET")
REDDIT_USER_AGENT = SECRETS.get("REDDIT_USER_AGENT")
DK_API_KEY = SECRETS.get("DK_API_KEY")

# --- Configuration & Sessions ---
AGENT_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
# Non-sensitive configuration uses environment variables
BUCKET = os.environ.get("AI_ASSETS_BUCKET")
USE_IN_MEMORY = os.environ.get("USE_IN_MEMORY_SESSION", "").lower() in ("true", "1")

# --- MEMORY BANK CONNECTION ---
def _get_memory_bank_uri():
    if USE_IN_MEMORY: return None, None
    # We use 'dev_signal_agent' as the display name for the Vertex AI memory bank
    name = os.environ.get("AGENT_ENGINE_MEMORY_BANK_NAME", "dev_signal_agent")
    existing = list(agent_engines.list(filter=f"display_name={name}"))
    ae = existing[0] if existing else agent_engines.create(display_name=name)
    uri = f"agentengine://{ae.resource_name}"
    print(f"DEBUG: Connecting to Memory Bank: {uri} (display_name={name})")
    return uri, uri

SESSION_URI, MEMORY_URI = _get_memory_bank_uri()

# --- Initialize FastAPI with ADK ---
app: FastAPI = get_fast_api_app(
    agents_dir=AGENT_DIR,
    web=True,
    artifact_service_uri=f"gs://{BUCKET}" if BUCKET else None,
    allow_origins=os.getenv("ALLOW_ORIGINS", "").split(",") if os.getenv("ALLOW_ORIGINS") else None,
    session_service_uri=SESSION_URI,
    memory_service_uri=MEMORY_URI, # <--- Connects the Memory Bank
    otel_to_cloud=True, # <--- Enables production telemetry
)

if __name__ == "__main__":
    import uvicorn
    # Standard Cloud Run port is 8080
    uvicorn.run(app, host="0.0.0.0", port=8080)

Implementing Telemetry

In a production environment, visibility into your agent's reasoning is critical. We leverage the built-in observability features of the Google ADK by setting the otel_to_cloud=True flag in our application server. This single parameter handles the majority of the instrumentation automatically, exporting "Agent Traces" directly to the Google Cloud Console. These traces provide a "visual waterfall" of the agent's operation, including individual agent thought processes, LLM invocations, and MCP tool calls.

Monitoring vs. Targeted Evaluation

It is essential to understand that production tracing is subject to sampling to balance performance and cost. Because Cloud Run captures only a subset of requests, not every individual user interaction will be visible.

System Traces (Monitoring): Used to analyze behavior "at large," such as identifying latency bottlenecks or system timeouts.
Reasoning Traces (Evaluation): High-quality evaluation mandates targeted trace capture. This means calling the agent specifically for a test case where you know you will evaluate that particular request in full detail.

Viewing the Trace

To see your traces, navigate to the Trace Explorer in the Google Cloud Console and filter for your service (e.g., dev-signal). Clicking a specific Trace ID opens a Gantt chart that allows you to distinguish between cognitive reasoning failures (wrong decisions) and physical system issues (timeouts).

For advanced configurations, refer to the following documentation:

Infrastructure as Code: Provisioning Secure Cloud Resources

We utilize the infrastructure-as-code patterns provided by the Agent Starter Pack's security-first design. The starter pack builds the professional platform required to automate the creation of least-privilege service accounts and robust secret management in seconds.

Using Terraform ensures that your entire Google Cloud environment - from IAM roles to Secret Manager versions - is defined in reproducible, secure code. We break our infrastructure into the following logical blocks:

Resources & Variables: Define the specific project, region, and sensitive API secrets used by the agent.
Core Infrastructure: Enable essential APIs and provision a private Artifact Registry to host your agent's container images.
Identity & Access Management (IAM): Configure specialized Service Accounts that strictly follow the Principle of Least Privilege to ensure your system remains secure.
Secret Management: Securely ingest API credentials into Google Secret Manager for protected runtime access.
Cloud Run Configuration: Define the container environment, resource limits, and automated secret injection for the final deployment.

To begin provisioning, return to the root folder of your project (dev-signal) and create the necessary deployment directories:

cd ..
mkdir deployment
cd deployment
mkdir terraform
cd terraform

Terraform Resources and Variables

The variables.tf file defines the configurable parameters for your deployment, allowing you to customize the infrastructure without altering the underlying logic. It includes variables for the project_id, the deployment region (defaulting to us-central1), and the service_name for your Cloud Run instance. Furthermore, it defines a secrets map used to securely ingest sensitive API credentials—such as Reddit and Developer Knowledge keys—into Google Secret Manager for runtime access. This modular approach ensures your production environment remains reproducible, secure, and adaptable across different projects.

Paste the following code into deployment/terraform/variables.tf:

variable "project_id" {
  description = "The Google Cloud Project ID"
  type        = string
}
variable "region" {
  description = "The Google Cloud region to deploy to"
  type        = string
  default     = "us-central1"
}
variable "service_name" {
  description = "The name of the Cloud Run service"
  type        = string
  default     = "dev-signal"
}
variable "secrets" {
  description = "A map of secret names and their values (e.g., REDDIT_CLIENT_ID, DK_API_KEY)"
  type        = map(string)
  default     = {}
}
variable "ai_assets_bucket" {
  description = "The GCS bucket for storing AI assets"
  type        = string
}

Core Infrastructure Logic

We define our infrastructure in logical blocks. Here is what each part does:

1. Enable APIs: Ensures the project has the necessary services active (Cloud Run, Vertex AI, etc.). We use disable_on_destroy = false to prevent accidental data loss if the Terraform is destroyed.

Paste the following code into deployment/terraform/main.tf:

resource "google_project_service" "services" {
  project = var.project_id
  for_each = toset([
    "run.googleapis.com",
    "artifactregistry.googleapis.com",
    "cloudbuild.googleapis.com",
    "aiplatform.googleapis.com",
    "secretmanager.googleapis.com",
    "logging.googleapis.com"
  ])
  service            = each.key
  disable_on_destroy = false
}

2. Artifact Registry: Creates a private Docker registry to store our agent's container images.

resource "google_artifact_registry_repository" "repo" {
  location      = var.region
  project       = var.project_id
  repository_id = "dev-signal-repo"
  description   = "Docker repository for Dev Signal Agent"
  format        = "DOCKER"
  depends_on    = [google_project_service.services]
}

3. Service Account & IAM: Adhering to the Principle of Least Privilege - This is a critical security step. In accordance with the Principle of Least Privilege, we avoid using the default compute service account and instead provision a dedicated user-managed service account (dev-signal-sa). By designating this as the Cloud Run service identity, we can grant it only the minimum necessary permissions—specifically roles/aiplatform.user, roles/logging.logWriter, and roles/storage.objectAdmin. This granular access control ensures that the agent has the exact permissions required to interact with Vertex AI and Cloud Storage without over-granting access to other sensitive cloud resources, significantly reducing the potential impact of a compromised account. Learn more best practices for using service accounts securely.

resource "google_service_account" "agent_sa" {
  project      = var.project_id
  account_id   = "${var.service_name}-sa"
  display_name = "Dev Signal Agent Service Account"
}

4. Secret Management: This handles your API keys securely. It creates secrets in Google Secret Manager and gives the agent's Service Account permission to access them at runtime.

resource "google_secret_manager_secret" "agent_secrets" {
  project  = var.project_id
  for_each = toset(keys(var.secrets))
  secret_id = each.key
  replication {
    auto {}
  }
  depends_on = [google_project_service.services]
}
resource "google_secret_manager_secret_version" "agent_secrets_version" {
  for_each    = toset(keys(var.secrets))
  secret      = google_secret_manager_secret.agent_secrets[each.key].id
  secret_data = var.secrets[each.key]
}
resource "google_secret_manager_secret_iam_member" "secret_accessor" {
  project  = var.project_id
  for_each = toset(keys(var.secrets))
  secret_id = google_secret_manager_secret.agent_secrets[each.key].id
  role      = "roles/secretmanager.secretAccessor"
  member    = "serviceAccount:${google_service_account.agent_sa.email}"
}

5. Cloud Run Configuration:

Security Best Practice: To satisfy production security standards, our main.tf grants the Service Account the secretmanager.secretAccessor role. Our Python application then uses the Secret Manager SDK to pull these credentials directly into local memory at runtime, ensuring they never touch the container's environment configuration

# 6. Cloud Run Service Deployment
resource "google_cloud_run_v2_service" "default" {
  project  = var.project_id
  name     = var.service_name
  location = var.region
  ingress  = "INGRESS_TRAFFIC_ALL"

  template {
    service_account = google_service_account.agent_sa.email

    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello" # Placeholder until first build

      env {
        name  = "GOOGLE_CLOUD_PROJECT"
        value = var.project_id
      }
      env {
        name  = "GOOGLE_CLOUD_LOCATION"
        value = "global"
      }
      env {
        name  = "GOOGLE_GENAI_USE_VERTEXAI"
        value = "True"
      }
      env {
        name  = "AI_ASSETS_BUCKET"
        value = var.ai_assets_bucket
      }

      resources {
        limits = {
          cpu    = "1"
          memory = "2Gi"
        }
      }
    }
  }

  traffic {
    type    = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
    percent = 100
  }

Provision the Infrastructure

Before we can deploy our code, we need to provision the Google Cloud infrastructure we just defined.

Initialize Terraform: This downloads the necessary provider plugins. Run this in deployment/terraform folder:

terraform init

Create a Variables File:

Paste this code in deployment/terraform/terraform.tfvars and update it with your project details and secrets.

project_id       = "your-project-id"
region           = "us-central1"
service_name     = "dev-signal"
ai_assets_bucket = "your-bucket-name"
secrets = {
  REDDIT_CLIENT_ID     = "your_client_id"
  REDDIT_CLIENT_SECRET = "your_client_secret"
  REDDIT_USER_AGENT    = "your_user_agent"
  DK_API_KEY           = "your_dk_api_key"
}

Plan configuration: This allows you to review the changes before they are applied. Run this in the deployment/terraform folder:

terraform plan -out=plan.tfplan

Apply Configuration: Once you have reviewed the plan and confirmed it does what you want, run:

terraform apply plan.tfplan

Deployment: Containerization and the Cloud Build Pipeline

In this final stage of the build process, we package our agent's "body" and "brain" into a portable, production-ready container. This ensures that every component - from our Python logic to the Node.js environment required for the Reddit MCP tool - is bundled together with its exact dependencies.

We utilize a Dockerfile to define this environment and a Makefile to orchestrate the deployment pipeline. When you trigger the deployment, Google Cloud Build takes your local source code, builds the container image according to the Dockerfile, and stores it in the private Artifact Registry created earlier by Terraform. Finally, the pipeline automatically updates your Cloud Run service to serve traffic using this fresh image, completing the journey from local code to a live, secure cloud workload.

Paste this code in dev-signal/Dockerfile:

FROM python:3.12-slim

# Install Node.js and npm for MCP tools (like reddit-mcp)
RUN apt-get update && apt-get install -y \
    curl \
    && curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \
    && apt-get install -y nodejs \
    && npm install -g reddit-mcp \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

RUN pip install --no-cache-dir uv==0.8.13

WORKDIR /code

COPY ./pyproject.toml ./README.md ./uv.lock* ./
COPY ./dev_signal_agent ./dev_signal_agent

RUN uv sync --frozen

EXPOSE 8080

CMD ["uv", "run", "uvicorn", "dev_signal_agent.fast_api_app:app", "--host", "0.0.0.0", "--port", "8080"]

The Makefile automates the build and deploys.

Paste this code in dev-signal/Makefile:

PROJECT_ID ?= $(shell gcloud config get-value project)
REGION     ?= us-central1
IMAGE_REPO ?= dev-signal-repo
IMAGE := $(REGION)-docker.pkg.dev/$(PROJECT_ID)/$(IMAGE_REPO)/agent:latest

# Deploy via Cloud Build & Container
docker-deploy:
    @echo "? Building and deploying to $(PROJECT_ID) via Cloud Build..."
    gcloud builds submit --tag $(IMAGE) --project $(PROJECT_ID) .
    gcloud run services update dev-signal \
        --image $(IMAGE) \
        --region $(REGION) \
        --project $(PROJECT_ID) \
        --labels dev-tutorial=dev-signal-agent

Deploy Application

Now that our infrastructure is ready, we can build and deploy the application code.

Run the following command from the root of your project:

make docker-deploy

What happens when you run this?

Build: Google Cloud Build takes your local code and the Dockerfile, builds a container image, and stores it in the Artifact Registry.
Deploy: It updates the Cloud Run service defined in Terraform to use this new image.

When the deployment completes, you should get a message like this:

Service [dev-signal] revision [dev-signal...] has been deployed and is serving 100 percent of traffic.

Service URL: https://dev-signal-...-.us-central1.run.app

Verification: Accessing and Testing Your Deployed Agent

Since production services are private by default, this section covers how to grant permissions and access the agent securely.

Managing IAM Permissions: Granting the necessary run.invoker role to authorized users.

Secure Access via Cloud Run Proxy: Using the gcloud proxy to interact with your live service.

Granting User Permissions

Before you can invoke the service, you must grant your Google account the roles/run.invoker role for this specific service. Run the following command:

gcloud run services add-iam-policy-binding dev-signal \
  --member="user:$(gcloud config get-value account)" \
  --role="roles/run.invoker" \
  --region=us-central1 \
  --project=$(gcloud config get-value project)

Launch the Proxy

Now, access your private service securely via the proxy:

gcloud run services proxy dev-signal \
  --region us-central1 \
  --project $(gcloud config get-value project)

Visit http://localhost:8080 to chat with your deployed agent! See a possible test scenario in part 3 of the series.

Summary

Congratulations! You have successfully built Dev Signal.

What we covered:

Tooling (MCP): You connected your agent to Reddit, Google Docs, and a Local Image Generator using the Model Context Protocol.
Architecture: You implemented a Root Orchestrator managing specialized agents (Scanner, Expert, Drafter).
Memory: You integrated Vertex AI memory bank to give your agent long-term persistence across sessions.
Production: You deployed the entire stack to Google Cloud Run using Terraform for secure, reproducible infrastructure.

You now have a solid foundation for building sophisticated, stateful AI applications on Google Cloud.

Local Testing of a Multi-Agent System with Memory

Shir Meir Lador — Thu, 07 May 2026 21:03:03 +0000

In part 1 and part 2 of this series, we established the essential groundwork by standardizing the core capabilities through the Model Context Protocol (MCP) and constructing a multi-agent architecture integrated with the Vertex AI memory bank to provide long-term intelligence and persistence. Now, we'll explore how to test your multi-agent system locally!

If you'd like to dive straight into the code and explore it at your own pace, you can clone the repository here.

Testing the Agent Locally

Before transitioning your agentic system to Google Cloud Run, it is essential to ensure that its specialized components work seamlessly together on your workstation. This testing phase allows you to validate trend discovery, technical grounding, and creative drafting within a local feedback loop, saving time and resources during the development process.

In this section, you will configure your local secrets, implement environment-aware utilities, and use a dedicated test runner to verify that Dev Signal can correctly retrieve user preferences from the Vertex AI memory bank on the cloud. This local verification ensures that your agent's "brain" and "hands" are properly synchronized before moving to deployment.

Environment Setup

Create a .env file in your project root. These variables are used for local development and will be replaced by Terraform/Secret Manager in production.

Paste this code in dev-signal/.env and update with your own details.

Note: GOOGLE_CLOUD_LOCATION is set as global because that is where gemini-3-flash-preview is supported. We will use GOOGLE_CLOUD_LOCATION for the model location.

# Google Cloud Configuration
GOOGLE_CLOUD_PROJECT=your-project-id
GOOGLE_CLOUD_LOCATION=global
GOOGLE_CLOUD_REGION=us-central1
GOOGLE_GENAI_USE_VERTEXAI=True
AI_ASSETS_BUCKET=your_bucket_name

# Reddit API Credentials
REDDIT_CLIENT_ID=your_client_id
REDDIT_CLIENT_SECRET=your_client_secret
REDDIT_USER_AGENT=my-agent/0.1

# Developer Knowledge API Key
DK_API_KEY=your_api_key

Helper Utilities

Create a new directory for your application utils:

cd dev_signal_agent
mkdir app_utils
cd app_utils

Environment Configuration

This module standardizes how the agent discovers the active Google Cloud Project and Region, ensuring a seamless transition between development environments. Using load_dotenv(), the script first checks for local configurations before falling back to google.auth.default() or environment variables to retrieve the Project ID. This automated approach ensures your agent is properly authenticated and grounded in the correct cloud context without requiring manual configuration changes.

Beyond basic project discovery, the script provides a robust Secret Management layer. It attempts to resolve sensitive credentials, such as Reddit API keys, first from the local environment (for rapid development) and then dynamically from the Google Cloud Secret Manager API for production security. By returning these as a dictionary rather than injecting them into environment variables, the module maintains a clean security posture.

The script further calibrates the environment by distinguishing between global and regional requirements for different AI services. It specifically assigns the "global" location for models to access cutting-edge preview features while designating a regional location, such as us-central1, for infrastructure like the Vertex AI Agent Engine.

Paste this code in dev_signal_agent/app_utils/env.py:

import os
import google.auth
import vertexai
from google.cloud import secretmanager
from dotenv import load_dotenv

def _fetch_secrets(project_id: str):
    """Fetch secrets from Secret Manager and return them as a dictionary."""
    secrets_to_fetch = ["REDDIT_CLIENT_ID", "REDDIT_CLIENT_SECRET", "REDDIT_USER_AGENT", "DK_API_KEY"]
    fetched_secrets = {}

    # First, check local environment (for local development via .env)
    for s in secrets_to_fetch:
        val = os.getenv(s)
        if val:
            fetched_secrets[s] = val

    # If keys are missing (common in production), fetch from Secret Manager API
    if len(fetched_secrets) < len(secrets_to_fetch):
        client = secretmanager.SecretManagerServiceClient()
        for secret_id in secrets_to_fetch:
            if secret_id not in fetched_secrets:
                name = f"projects/{project_id}/secrets/{secret_id}/versions/latest"
                try:
                    response = client.access_secret_version(request={"name": name})
                    fetched_secrets[secret_id] = response.payload.data.decode("UTF-8")
                except Exception as e:
                    print(f"Warning: Could not fetch {secret_id} from Secret Manager: {e}")
    return fetched_secrets

def init_environment():
    """Consolidated environment discovery."""
    load_dotenv()
    try:
        _, project_id = google.auth.default()
    except Exception:
        project_id = os.getenv("GOOGLE_CLOUD_PROJECT")

    model_location = os.getenv("GOOGLE_CLOUD_LOCATION", "global")
    service_location = os.getenv("GOOGLE_CLOUD_REGION", "us-central1")

    secrets = {}
    if project_id:
        vertexai.init(project=project_id, location=service_location)
        secrets = _fetch_secrets(project_id)

    return project_id, model_location, service_location, secrets

Local Testing Script

The Google ADK comes with a built-in Web UI that is excellent for visualizing agent logic and tool composition.

You can launch it by running in the project root:

uv run adk web

However, the default Web UI will not test the long-term memory integration described in this tutorial because it is not pre-connected to a Vertex AI memory session. By default, the generic UI often relies on in-memory services that do not persist data across sessions. Therefore, we use the dedicated test_local.py script to explicitly initialize the VertexAiMemoryBankService. This ensures that even in a local environment, your agent is communicating with the real cloud-based memory bank to validate preference persistence.

The test_local.py script:

Connects to the real Vertex AI Agent Engine in the cloud for memory storage.
Uses an in-memory session service for local chat history (so you can wipe it easily).
Runs a chat loop where you can talk to your agent.

Go back to the root folder dev-signal:

cd ../..

Paste this code in dev-signal/test_local.py:

import asyncio
import os
import google.auth
import vertexai
import uuid
from dotenv import load_dotenv
from google.adk.runners import Runner
from google.adk.memory.vertex_ai_memory_bank_service import VertexAiMemoryBankService
from google.adk.sessions import InMemorySessionService
from vertexai import agent_engines
from google.genai import types
from dev_signal_agent.agent import root_agent

# Load environment variables
load_dotenv()

async def main():
    # 1. Setup Configuration
    project_id = os.getenv("GOOGLE_CLOUD_PROJECT")
    # Agent Engine (Memory) MUST use a regional endpoint
    resource_location = "us-central1"
    agent_name = "dev-signal"

    print(f"--- Initializing Vertex AI in {resource_location} ---")
    vertexai.init(project=project_id, location=resource_location)

    # 2. Find the Agent Engine Resource for Memory
    existing_agents = list(agent_engines.list(filter=f"display_name={agent_name}"))
    if existing_agents:
        agent_engine = existing_agents[0]
        agent_engine_id = agent_engine.resource_name.split("/")[-1]
        print(f"✅ Using persistent Memory Bank from Agent: {agent_engine_id}")
    else:
        print(f"❌ Error: Agent Engine '{agent_name}' not found. Please deploy with Terraform first.")
        return

    # 3. Initialize Services
    session_service = InMemorySessionService()
    memory_service = VertexAiMemoryBankService(
        project=project_id,
        location=resource_location,
        agent_engine_id=agent_engine_id
    )

    # 4. Create a Runner
    runner = Runner(
        agent=root_agent,
        app_name="dev-signal",
        session_service=session_service,
        memory_service=memory_service
    )

    # 5. Run a Test Loop
    user_id = "local-tester"
    print("\n--- TEST SCENARIO ---")
    print("1. Start a session, tell the agent your preference (e.g., 'write in rhymes').")
    print("2. Type 'new' to start a FRESH session (local state wiped).")
    print("3. Ask for a blog post. The agent should retrieve your preference from the CLOUD memory.")

    current_session_id = f"session-{str(uuid.uuid4())[:8]}"
    await session_service.create_session(
        app_name="dev-signal",
        user_id=user_id,
        session_id=current_session_id
    )
    print(f"\n--- Chat Session (ID: {current_session_id}) ---")

    while True:
        user_input = input("\nYou: ")
        if user_input.lower() in ["exit", "quit"]:
            break

        if user_input.lower() == "new":
            current_session_id = f"session-{str(uuid.uuid4())[:8]}"
            await session_service.create_session(
                app_name="dev-signal",
                user_id=user_id,
                session_id=current_session_id
            )
            print(f"\n--- Fresh Session Started (ID: {current_session_id}) ---")
            print("(Local history is empty, retrieval must come from Memory Bank)")
            continue

        print("Agent is thinking...")
        async for event in runner.run_async(
            user_id=user_id,
            session_id=current_session_id,
            new_message=types.Content(parts=[types.Part(text=user_input)])
        ):
            if event.content and event.content.parts:
                for part in event.content.parts:
                    if part.text:
                        print(f"Agent: {part.text}")
            if event.get_function_calls():
                for fc in event.get_function_calls():
                    print(f"🛠️ Tool Call: {fc.name}")

if __name__ == "__main__":
    asyncio.run(main())

Running the Test

First, ensure you have your Application Default Credentials set up:

gcloud auth application-default login

Then run the script:

uv run test_local.py

Test Scenario

This scenario validates the full end-to-end lifecycle of the agent: from discovery and research to multimodal content creation and long-term memory retrieval.

Phase 1: Teaching & Multimodal Creation (Session 1)

Goal: Establish technical context and set a specific stylistic preference.

Discovery

Ask the agent to find trending Cloud Run topics.

Input: "Find high-engagement questions about AI agents on Cloud Run from the last 21 days."

Research

Instruct the agent to perform a deep dive on a specific result.

Input: "Use the GCP Expert to research topic #1."

Personalization

Request a blog post and explicitly set your style preference.

Input: "Draft a blog post based on this research. From now on, I want all my technical blogs written in the style of a 90s Rap Song."

Image Generation

Ask the agent to generate an image that demonstrates the main ideas in the blog using the Nano Banana Pro tool. The image will be saved to your bucket in Google Cloud and you should get the path to see it, which will look like: https://storage.mtls.cloud.google.com/...

Phase 2: Long-Term Memory Recall (Session 2)

Goal: Verify the agent recalls preferences across a completely fresh session.

Type new in the console to wipe local session history and start a fresh state.
Retrieval: Inquire about your stored preferences to test the Vertex AI memory bank.

Input: "What are my current topics of interest and what is my preferred blogging style?"

Verification: Confirm the agent successfully retrieves your "AI Agents on Cloud Run" interest and "Rap" style from the cloud.

Final Test: Ask for a new blog on a different topic (e.g., "GKE Autopilot") and ensure it is automatically written as a rap song without being prompted.

Summary

In this part of our series we focused on verifying the agent's functionality in a local environment before proceeding to cloud deployment. By configuring local secrets and utilizing environment-aware utilities, we used a dedicated test runner to confirm that the core reasoning and tool logic are properly integrated. We successfully validated the full lifecycle: from Reddit discovery to expert content creation, confirming that the agent correctly retrieves preferences from the cloud-based Vertex AI memory bank even in completely fresh sessions.

Ready to run the test scenario yourself? Clone the repository and try the test_local.py script to see 'Dev Signal' retrieve your preferences from the Vertex AI memory bank in real-time. For a deeper dive into the underlying mechanics of memory orchestration, check out this quickstart guide.

In the final part of this series, we will transition our prototype into a production service on Google Cloud Run using Terraform for secure infrastructure, and explore the roadmap to production excellence through continuous evaluation and security.

Special thanks to Remigiusz Samborski for the helpful review and feedback on this article.

For more content like this, follow me on LinkedIn and X.

Architect A Personalized Multi-Agent System with Long-Term Memory

Shir Meir Lador — Thu, 07 May 2026 21:01:06 +0000

In support of our mission to accelerate the developer journey on Google Cloud, we built Dev Signal — a multi-agent system designed to transform raw community signals into reliable technical guidance by automating the path from discovery to expert creation.

In the first part of this series for the Dev Signal, we laid the essential groundwork for this system by establishing a project environment and equipping core capabilities through the Model Context Protocol (MCP). We standardized our external integrations, connecting to Reddit for trend discovery, Google Cloud Docs for technical grounding, and building a custom Nano Banana Pro MCP server for multimodal image generation. If you missed Part 1 or want to explore the code directly, you can find the complete project implementation in our GitHub repository.

Now, in Part 2, we focus on building the multi-agent architecture and integrating the Vertex AI memory bank to personalize these capabilities. We will implement a Root Orchestrator that manages three specialist agents: the Reddit Scanner, GCP Expert, and Blog Drafter, to provide a seamless flow from trend discovery to expert content creation. We will also integrate a long-term memory layer that enables the agent to learn from your feedback and persist your stylistic preferences across different conversations. This ensures that Dev Signal doesn't just process data, but actually learns to match your professional voice over time.

Infrastructure and Model Setup

First, we initialize the environment and the shared Gemini model.

Paste this code in dev_signal_agent/agent.py:

from google.adk.agents import Agent
from google.adk.apps import App
from google.adk.models import Gemini
from google.adk.tools import google_search, AgentTool, load_memory_tool, preload_memory_tool
from google.adk.tools.tool_context import ToolContext
from google.genai import types
from dev_signal_agent.app_utils.env import init_environment
from dev_signal_agent.tools.mcp_config import (
    get_reddit_mcp_toolset,
    get_dk_mcp_toolset,
    get_nano_banana_mcp_toolset
)

PROJECT_ID, MODEL_LOC, SERVICE_LOC, SECRETS = init_environment()

shared_model = Gemini(
    model="gemini-3-flash-preview",
    vertexai=True,
    project=PROJECT_ID,
    location=MODEL_LOC,
    retry_options=types.HttpRetryOptions(attempts=3),
)

Memory Ingestion Logic

We want Dev Signal to do more than just follow instructions — we want it to learn from you. By capturing your preferences, such as specific technical interests on Reddit or a preferred blogging style, the agent can personalize its output for future use. To achieve this, we use the Vertex AI memory bank to persist session history across different conversations.

Long-term Memory

We automate this through the save_session_to_memory_callback function. This callback is configured to run automatically after every turn, ensuring that session details are captured and stored in the memory bank without manual intervention.

How Managed Memory Works:

Ingestion: The save_session_to_memory_callback sends the conversation data to Vertex AI.
Embedding: Vertex AI converts the text into numerical vectors (embeddings) that capture the semantic meaning of your preferences.
Storage: These vectors are stored in a managed index, enabling the agent to perform semantic searches and retrieve relevant history in future sessions.
Retrieval: The agent recalls this history using built-in ADK tools. The PreloadMemoryTool proactively brings in context at the start of an interaction, while the LoadMemoryTool allows the agent to fetch specific memories on an as-needed basis.

Paste this code in dev_signal_agent/agent.py:

async def save_session_to_memory_callback(*args, **kwargs) -> None:
    """
    Defensive callback to persist session history to the Vertex AI memory bank.
    """
    ctx = kwargs.get("callback_context") or (args[0] if args else None)
    # Check connection to Memory Service
    if ctx and hasattr(ctx, "_invocation_context") and ctx._invocation_context.memory_service:
        # Save the session!
        await ctx._invocation_context.memory_service.add_session_to_memory(
            ctx._invocation_context.session
        )

Short-term Memory

The add_info_to_state function serves as the agent's short-term working memory, allowing the gcp_expert to reliably hand off its detailed findings to the blog_drafter within the same session. This working memory and the conversation transcript are managed by the Vertex AI Session Service to ensure that active context survives server restarts or transient failures.

The boundary between session-based state and long-term persistence — It is important to note that while this service provides stability during an active interaction, this short-term memory does not persist between different sessions. Starting a fresh session ID effectively resets this working state, ensuring a clean slate for new tasks. Cross-session continuity, where the agent remembers your stylistic preferences or past feedback, is handled by the Vertex AI Memory Bank.

Paste this code in dev_signal_agent/agent.py

def add_info_to_state(tool_context: ToolContext, key: str, data: str) -> dict:
    tool_context.state[key] = data
    return {"status": "success", "message": f"Saved '{key}' to state."}

Specialist 1: Reddit Scanner (Discovery)

The Reddit Scanner is our "Trend Spotter," it identifies high-engagement questions from the last 21 days (3 weeks) to ensure that all research findings remain both timely and relevant.

Memory Usage: It leverages load_memory to retrieve your past areas of interest and preferred topics from the Vertex AI memory bank. If relevant history exists, the agent prioritizes those specific topics in its search to provide a personalized discovery experience.

Beyond simple retrieval, each sub-agent actively updates its memories by listening for new preferences and explicitly acknowledging them during the chat. This process captures relevant information in the session history, where an automated callback then persists it to the long-term Vertex AI memory bank for future use.

This memory management is supported by two distinct retrieval patterns within the Google Agent Development Kit (ADK). The first is the PreloadMemoryTool, which proactively brings in historical context at the beginning of every interaction to ensure the agent is fully briefed before addressing the current request. The second is the LoadMemoryTool, which the agent uses on an as-needed basis, calling upon it only when it decides that deeper past knowledge would be beneficial for the current step in the workflow.

Paste this code in dev_signal_agent/agent.py

# Singleton toolsets
reddit_mcp = get_reddit_mcp_toolset(
    client_id=SECRETS.get("REDDIT_CLIENT_ID", ""),
    client_secret=SECRETS.get("REDDIT_CLIENT_SECRET", ""),
    user_agent=SECRETS.get("REDDIT_USER_AGENT", "")
)

reddit_scanner = Agent(
    name="reddit_scanner",
    model=shared_model,
    instruction="""
You are a Reddit research specialist. Your goal is to identify high-engagement questions
from the last 3 weeks on specific topics of interest, such as AI/agents on Cloud Run.

Follow these steps:
1. **MEMORY CHECK**: Use `load_memory` to retrieve the user's **past areas of interest** and **preferred topics**. Calibrate your search to align with these interests.
2. Use the Reddit MCP tools to search for relevant subreddits and posts.
3. Filter results for posts created within the last 21 days (3 weeks).
4. Analyze "high-engagement" based on upvote counts and the number of comments.
5. Recommend the most important and relevant questions for a technical audience.
6. **CRITICAL**: For each recommended question, provide a direct link to the original thread and a concise summary of the discussion.
7. **CAPTURE PREFERENCES**: Actively listen for user preferences, interests, or project details. Explicitly acknowledge them to ensure they are captured in the session history for future personalization.
""",
    tools=[reddit_mcp, load_memory_tool.LoadMemoryTool()],
    after_agent_callback=save_session_to_memory_callback,
)

Specialist 2: GCP Expert (Grounding)

The GCP Expert is our "Technical Authority". It triangulates facts by synthesizing official documentation from the Google Cloud Developer Knowledge MCP Server, community sentiment from Reddit, and broader context from Google Search.

Paste this code in dev_signal_agent/agent.py

dk_mcp = get_dk_mcp_toolset(api_key=SECRETS.get("DK_API_KEY", ""))

search_agent = Agent(
    name="search_agent",
    model=shared_model,
    instruction="Execute Google Searches and return raw, structured results (Title, Link, Snippet).",
    tools=[google_search],
)

gcp_expert = Agent(
    name="gcp_expert",
    model=shared_model,
    instruction="""
You are a Google Cloud Platform (GCP) documentation expert.
Your goal is to provide accurate, detailed, and cited answers to technical questions by synthesizing official documentation with community insights.

For EVERY technical question, you MUST perform a comprehensive research sweep using ALL available tools:
1. **Official Docs (Grounding)**: Use DeveloperKnowledge MCP (`search_documents`) to find the definitive technical facts.
2. **Social Media Research (Reddit)**: Use the Reddit MCP to research the question on social media. This allows you to find real-world user discussions, common pain points, or alternative solutions that might not be in official documentation.
3. **Broader Context (Web/Social)**: Use the `search_agent` tool to find recent technical blogs, social media discussions, or tutorials.

Synthesize your answer:
- Start with the official answer based on GCP docs.
- Add "Social Media Insights" or "Common Issues" sections derived from Reddit and Web Search findings.
- **CRITICAL**: After providing your answer, you MUST use the `add_info_to_state` tool to save your full technical response under the key: `technical_research_findings`.
- Cite your sources specifically at the end of your response, providing **direct links** (URLs) to the official documentation, blog posts, and Reddit threads used.
- **CAPTURE PREFERENCES**: Actively listen for user preferences, interests, or project details. Explicitly acknowledge them to ensure they are captured in the session history for future personalization.
""",
    tools=[dk_mcp, AgentTool(search_agent), reddit_mcp, add_info_to_state],
    after_agent_callback=save_session_to_memory_callback,
)

Specialist 3: Blog Drafter (Creativity)

The Blog Drafter is our Content Creator. It drafts the blog based on the expert's findings and offers to generate visuals.

Memory Usage: It checks load_memory for the user's preferred writing style (e.g. "Witty", "Rap") stored in the Vertex AI memory bank.

Paste this code in dev_signal_agent/agent.py

nano_mcp = get_nano_banana_mcp_toolset()

blog_drafter = Agent(
    name="blog_drafter",
    model=shared_model,
    instruction="""
You are a professional technical blogger specializing in Google Cloud Platform.
Your goal is to draft high-quality blog posts based on technical research provided by the GDE expert and reliable documentation.

You have access to the research findings from the gcp_expert_agent here:
{{ technical_research_findings }}

Follow these steps:
1. **MEMORY CHECK**: Use `load_memory` to retrieve past blog posts, **areas of interest**, and user feedback on writing style. Adopt the user's preferred style and depth.
2. **REVIEW & GROUND**: Review the technical research findings provided above. **CRITICAL**: Use the `dk_mcp` (Developer Knowledge) tool to verify key facts, technical limitations, and API details. Ensure every claim in your blog is grounded in official documentation.
3. Draft a blog post that is engaging, accurate, and helpful for a technical audience.
4. Include code snippets or architectural diagrams if relevant.
5. Provide a "Resources" section with links to the official documentation used.
6. Ensure the tone is professional yet accessible, while adhering to any style preferences found in memory.
7. **VISUALS**: After presenting the drafted blog post, explicitly ask the user: "Would you like me to generate an infographic-style header image to illustrate these key points?" If they agree, use the `generate_image` tool (Nano Banana).
8. **CAPTURE PREFERENCES**: Actively listen for user preferences, interests, or project details. Explicitly acknowledge them to ensure they are captured in the session history for future personalization.
""",
    tools=[dk_mcp, load_memory_tool.LoadMemoryTool(), nano_mcp],
    after_agent_callback=save_session_to_memory_callback,
)

The Root Orchestrator

The root agent serves as the system's strategist, managing a team of specialist agents and orchestrating their actions based on the specific goals provided by the user. At the start of a conversation, the orchestrator retrieves memory to establish context by checking for the user's past areas of interest, preferred topics, or previous projects.

Paste this code in dev_signal_agent/agent.py

root_agent = Agent(
    name="root_orchestrator",
    model=shared_model,
    instruction="""
You are a technical content strategist. You manage three specialists:
1. reddit_scanner: Finds trending questions and high-engagement topics on Reddit.
2. gcp_expert: Provides technical answers based on official GCP documentation.
3. blog_drafter: Writes professional blog posts based on technical research.

Your responsibilities:
- **MEMORY CHECK**: At the start of a conversation, use `load_memory` to check if the user has specific **areas of interest**, preferred topics, or past projects. Tailor your suggestions accordingly.
- **CAPTURE PREFERENCES**: Actively listen for user preferences, interests, or project details. Explicitly acknowledge them to ensure they are captured in the session history for future personalization.
- If the user wants to find trending topics or questions from Reddit, delegate to reddit_scanner.
- If the user has a technical question or wants to research a specific theme, delegate to gcp_expert.
- **CRITICAL**: After the gcp_expert provides an answer, you MUST ask the user:
  "Would you like me to draft a technical blog post based on this answer?"
- If the user agrees or asks to write a blog, delegate to blog_drafter.
- Be proactive in helping the user navigate from discovery (Reddit) to research (Docs) to content creation (Blog).
""",
    tools=[load_memory_tool.LoadMemoryTool(), preload_memory_tool.PreloadMemoryTool()],
    after_agent_callback=save_session_to_memory_callback,
    sub_agents=[reddit_scanner, gcp_expert, blog_drafter]
)

app = App(root_agent=root_agent, name="dev_signal_agent")

Summary

In this part of our series, we built multi-agent architecture and implemented a robust, dual-layered memory system. We established a Root Orchestrator, managing three specialist agents: a Reddit Scanner for trend discovery, a GCP Expert for technical grounding, and a Blog Drafter for creative content creation.

By utilizing short-term state to pass information reliably between specialists and integrating the Vertex AI memory bank for long-term persistence, we've enabled the agent to learn from your feedback and remember specific writing styles across different conversations.

In Part 3, we will show you how to test the agent locally to verify these components on your workstation, before transitioning to a full production deployment on Google Cloud Run in Part 4. Can't wait for part 3? The full implementation is already available for you to explore on GitHub.

To learn more about the underlying technology, explore the Vertex AI Memory Bank overview or dive into the official ADK Documentation to see how to orchestrate complex multi-agent workflows.

Special thanks to Remigiusz Samborski for the helpful review and feedback on this article.

For more content like this, follow me on LinkedIn and X.

DEV Community: Shir Meir Lador

Build a Long-Running Agent in the Cloud for $5.70/Month

What are we building?

How the system works

What else can you build with a long-running agent?

Why Cloud Run instances are great for agents

When NOT to use this

Alternative architecture: Decoupled Job + Service

Deploy your long-running agent in 6 simple steps

1. Turn on the cloud services

2. Create a storage bucket for your data

3. Build your container

4. Create a service account

5. Store your API key securely

6. Launch the instance

What does this cost in real life?

Learn more about Cloud Run instances

What is coming next?

Your First Multi-agent system: A Beginner's Guide to Building an AI Trend finder with ADK

Step 1: Get Reddit API Credentials & Install Library

Configure Your Cloud Environment

Step 2: Create the Project Folder

Step 3: Create the Specialist Sub-Agents

Step 4: Build the Main Orchestrator Agent

Step 5: Running Your Multi-Agent System

Part 6: Next Steps and Conclusion

Your First AI Agent: A Beginner's Guide to Building an AI Trend finder with ADK

Part 1: Setup and Configuration

Step 1.1: Prerequisites

Step 1.2: Create Your Project Structure

Step 1.3: Install ADK

Step 1.4: Configure Your Cloud Environment

Part 2: Building Your Agent

Step 2.1: Define the Agent's Brain (The Prompt)

Step 2.2: Assemble the Agent

Step 2.3: Making Your Agent Discoverable

Part 3: Running Your Agent

Step 3.1: Install your agent:

Step 3.2: Launch the web interface:

Step 3.3: Debugging

Part 4 - Deployment

Step 4.1: Setup environment variables

Step 4.2: Deployment to Cloud Run

Step 4.3: Testing your deployed agent

Part 5: Next Steps and Conclusion

What is harness engineering and why should I care?

What exactly is a harness?

Show me the code

Adding Tests

Wiring it all together using graph-based workflow

Try it yourself

Further reading

Google Cloud Labs: Accelerate AI with Cloud Run

Moving Beyond the Prototype

The Coffee Shop Journey: A Hands-On Experience

Production-Grade AI on Cloud Run

Ready to Build for Scale? Join us in North America

Agent Factory Recap: 100X engineering with AI agents in Google Antigravity 2.0

Google Antigravity 2.0 - What is it?

Rody Davis on 100X Engineering

Scaling Impact and Reducing Toil

Skills as "Context Cheat Sheets"

Customizations, Skills, and MCP Servers

The Bonsai Approach to Code Review

Do you review 100% of agent-generated code?

Building Extensions to Solve Daily Friction

Do AI engineers still write code by hand?

Powering Personal Websites with Gemma 4

The Factory Floor

Multi-Agent Parallelism in Action

Unbundling the IDE Ecosystem

Turning Documentation into Reusable Skills

Rapid Fire: Future Tech Predictions

Grounding Yourself in a Changing Landscape

Conclusion

Your turn to build

Connect with us

A Guide to AI Cold Starts on Cloud Run

The anatomy of an AI cold start

Phase 1: Infrastructure Provisioning (~5s)