DEV Community: Google AI

Equip your agent with Google Cloud best practices using google-cloud-developer plugin

Remigiusz Samborski — Thu, 24 Sep 2026 11:55:12 +0000

Coding agents in your terminal can scaffold microservices in seconds. But what happens when your agent needs to deploy directly to Google Cloud?

Without cloud-specific guidance, typical agents struggle. They hallucinate obsolete SDK calls, attempt to run commands without required permissions, or silently enable billable APIs that create surprise costs on your invoice.

The google-cloud-developer plugin changes this dynamic. It equips your agent (such as Antigravity CLI, Claude Code, Codex CLI) with curated skills and the Developer Knowledge MCP server.

To evaluate the plugin in action, I tasked Antigravity CLI (agy) with building a complete, cloud-based solution from a fresh Google Cloud project. The scenario: scaffold, containerize, and deploy a secure Gemini API streaming proxy on Cloud Run, complete with Cloud IAM authentication and Firestore token tracking.

While the resulting Cloud Run proxy codebase works, the proxy itself is just an example. The real value is how the plugin guides the agent through every phase of the cloud development process:

Application design and SDK code generation: Writing Gemini SDK code without hallucinations and selecting the right database.
Project onboarding, billing verification, and API enablement: Auditing the project, linking a Cloud Billing account, and requesting explicit user approval before enabling billable APIs.
Least-privilege IAM and Cloud Run deployment: Provisioning dedicated service accounts and deploying the container asynchronously.
End-to-end verification: Testing streaming and token persistence against the live service.

Quick install: Five skills and an MCP server

Remember the scene in The Matrix where Trinity calls Tank for a helicopter pilot program and learns it in seconds? Adding the plugin to agy works the same way with one terminal command:

agy plugin install https://github.com/google/skills/plugins/cloud/google-cloud-developer

The CLI clones the plugin repository, registers its components, and makes them available immediately.

In seconds, agy configures:

Five specialized skills covering Google Cloud CLI patterns and workflows.
Developer Knowledge MCP server providing access to current API syntax and Google Cloud documentation.

With the plugin active, agy pairs its Gemini 3.8 Flash model with authoritative cloud instructions.

Note: As a heavy user of Google Cloud, I already have gcloud installed and authenticated. I also enabled the Developer Knowledge API in my project. For new users and ones who use a different harness such as Claude Code CLI or Codex CLI, I recommend following the official documentation to get started.

Knowledge grounding: Writing modern SDK code without hallucinations

One frequent failure mode with AI coding assistants is API obsolescence. For example, older tutorials rely on deprecated libraries such as google-generativeai.

Because the google-cloud-developer plugin connects directly to the Developer Knowledge API, the agent checks the latest official syntax before writing a single line of code.

When scaffolding app/gemini_client.py, agy immediately used the current unified Google Gen AI SDK:

The agent produced clean Python code with Pydantic configuration, structured Cloud Logging formatters, and unit tests using pytest and FastAPI's TestClient.

Informed architecture: Evaluating database options with Developer Knowledge

Selecting the right database for a serverless proxy requires balancing latency, connection handling, concurrency, and cost. When I asked agy to track token usage per user and suggest the best database, the agent did not just pick one at random.

Backed by the Developer Knowledge API, the agent pulled real-time architectural guidance and evaluated Google Cloud database options:

By grounding its analysis in the Developer Knowledge, the agent presented a clear comparison table directly in the terminal. It recommended Cloud Firestore as the most cost-effective and operationally simple fit for Cloud Run. You get an informed architectural decision based on official cloud patterns rather than guessing.

Cost guardrails and onboarding: Verifying billing before enabling APIs

Once the code and Firestore design were ready, the agent needed to enable the Gemini Enterprise, Cloud Run, and Firestore APIs in my project. Autonomous agents need strict boundaries here because enabling an API or provisioning a managed resource can incur costs.

Two skills in the google-cloud-developer plugin coordinate this step:

Pre-flight billing audit: Before enabling billable services, the google-cloud-recipe-onboarding skill instructs the agent to verify that the target project is linked to an active Cloud Billing account (gcloud billing projects describe).
Explicit user consent: The gcloud skill requires explicit user approval before running gcloud services enable or any destructive action.

When agy identified the required APIs for the proxy, it first checked my project state and paused for explicit permission:

The system's guardrails require explicit user approval before enabling any API, specifically addressing potential security risks and unexpected costs.

This keeps you in the driver's seat and eliminates accidental spend.

How `agy` helps: Scheduling timers for billing propagation

During the onboarding skill's pre-flight check, I linked a new billing account to my test project so agy could enable the APIs. In Google Cloud, linking a billing account often takes a few minutes to propagate across backend systems.

While the google-cloud-developer plugin tells the agent how to validate billing status (gcloud billing projects describe checking for billingEnabled: true), agy complements the plugin with its native Schedule tool so the session does not fail or spin in a retry loop.

I typed:

"Ok. Let's wait now. I just enabled the billing and it needs to propagate. I'll check in 10 minutes."

The agent scheduled a 600-second timer and freed the terminal prompt:

Exactly 10 minutes later, the timer woke the agent up. It resumed the exact conversation context, checked the billing status with gcloud beta billing projects describe, verified that billingEnabled was true, and prompted to enable the required APIs:

You can walk away, grab a coffee, and let your agent resume right where you left off.

Security enforcement: Least-privilege IAM

With the APIs enabled, the next step before deployment was configuring authentication. Without guidance, agents often suggest creating a long-lived Gemini API key or downloading a service account JSON key file.

Instead, the google-cloud-recipe-auth skill explicitly forbids downloaded service account keys and steers the agent toward Google Cloud security best practices:

Dedicated service identity: Creates a workload-specific service account (gemini-proxy-sa).
Least-privilege IAM bindings: Grants only roles/aiplatform.user for Gemini invocation and roles/datastore.user for Firestore token logging.
Authenticated ingress: Protects the Cloud Run endpoint with --no-allow-unauthenticated so the Google Frontend validates Google-signed OpenID Connect (OIDC) ID tokens before traffic reaches your container.

No secrets live in plaintext, and permissions stay tightly scoped.

Cloud Run deployment

To deploy the container, agy used finding-google-skills to pull Cloud Run deployment patterns (cloud-run-basics) from the remote skill catalog and combined them with the gcloud skill's command formatting rules:

gcloud run deploy gemini-38-flash-proxy \
  --source . \
  --region=us-central1 \
  --service-account=gemini-proxy-sa@[PROJECT_ID].iam.gserviceaccount.com

How `agy` helps: Running long tasks in the background

Building a container image from source still takes a few minutes. agy helps by launching the deployment as a background task instead of locking up your interactive session:

Notice the task status bar in the terminal: [14:12:41] gcloud run deploy gemini-38-flash-proxy ... running (1 task(s) · /tasks)

You can continue chatting with the agent, ask questions, or inspect background jobs with /tasks while Cloud Build compiles your container image.

Live verification: Streaming and per-user token persistence

Once the background deployment completed, agy generated test commands to verify the end-to-end flow.

Calling the usage endpoint with an authenticated identity token:

curl -s -X GET https://gemini-38-flash-proxy-[PROJECT_NUMBER].us-central1.run.app/v1/users/me/usage \
  -H "Authorization: Bearer $(gcloud auth print-identity-token)"

Returns real-time Firestore persistence data:

{
  "user_id": "[EMAIL]",
  "total_input_tokens": 14,
  "total_output_tokens": 41,
  "total_tokens": 55,
  "last_active": "2026-09-21T12:21:21.567000+00:00",
  "models.gemini-3_8-flash.input_tokens": 14,
  "models.gemini-3_8-flash.output_tokens": 41,
  "models.gemini-3_8-flash.total_tokens": 55
}

Atomic increments in Firestore record prompt and completion token counts across requests, giving you immediate visibility into user consumption.

Summary

Pairing agy with the google-cloud-developer plugin creates a safer, smarter CLI workflow:

Knowledge grounding: Developer Knowledge API prevents outdated SDK hallucinations and ensures accurate code generation.
Human in the loop: Built-in skill guardrails require explicit permission before running commands that can incur cloud costs.
Non-blocking workflow: Scheduled timers handle asynchronous cloud operations, while background tasks let long builds run without freezing your prompt.
Enterprise security defaults: Encourages least-privilege service accounts and IAM authentication over hardcoded secrets.

Next steps

Check out more resources on google-cloud-developer plugin:

Connect with me

I am always eager to share what I've learned and hear how fellow developers and AI enthusiasts use Antigravity and Google Cloud. If you found this article helpful, feel free to share it and follow me on your favorite social platform:

Thanks for reading!

Claude Opus 5.5 is now available on Google Cloud

Jen Harvey — Tue, 22 Sep 2026 17:48:24 +0000

Everyday complex tasks? No problem. Opus 5.5 handles long-running coding and knowledge work while keeping you in the loop along the way, all at a lower price per token. Get started in Model Garden today!

Build real-time voice applications with Gemini 3.8 Live and 3.5 Transcribe

Thor 雷神 Schaeff — Wed, 16 Sep 2026 14:30:05 +0000

Yesterday, we released new Gemini Live models in the Gemini API and Google AI Studio, expanding our developer suite for building real-time, voice-first product experiences:

Gemini 3.8 Live and 3.8 Live Extended Thinking: Gemini 3.8 Live brings a step change to our native speech-to-speech models, capable of performing tasks while maintaining dialogue. For complex requests, 3.8 Live Extended Thinking delivers deeper reasoning, ranking #1 on Artificial Analysis’ Speech-to-Speech leaderboard.

Gemini 3.5 Transcribe: Our dedicated speech-to-text model brings highly precise transcription across 85+ languages. Released last month, it achieved an average Word Error Rate (WER) of 4.0% (streaming) and 2.6% (non-streaming).

Gemini 3.8 Live & 3.8 Live Extended Thinking: Build more intelligent conversational agents

Our new models, Gemini 3.8 Live and 3.8 Live Extended Thinking enable developers to build voice agents that can reason and execute tasks while maintaining the flow of conversations. Key capabilities include:

Asynchronous function calling: Execute API and tool calls in the background while continuing to stream audio responses to the user
Visual context: Ground dialogue in live visual inputs to help enable agents that can understand what users say and see
Alphanumeric precision: Accurately parse confirmation codes, claim numbers, and technical data
Multilingual support: Reach global audiences with coverage for 97+ languages and accent consistency
Incremental content updates: Seamlessly merge real-time audio with structured data to return context-aware responses

3.8 Live Extended Thinking also supports configurable thinking to help handle complex, multi-step reasoning in the background, while responding or narrating its progress in the main conversation. These models represent a step-change from our previous live models and provide a more streamlined alternative to cascaded architectures.

Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking are available via the Live API. Competitively priced at $0.005/min for audio input and $0.018/min* for audio output, they allow developers to scale voice applications with industry-leading performance.

Developers can also access the models through Agora, Fishjam, LangChain, LiveKit, Pipecat, Vercel, and Vision Agents, our Live API integration partners that handle media streaming infrastructure for real-world deployment.

Gemini 3.5 Transcribe: Convert streamed speech to text

Real-time speech understanding is critical for voice-first interfaces. Last month, we released Gemini 3.5 Transcribe for low-latency transcription with high precision, achieving a 4.0% WER, and useful features:

Automatic code-switching: Handle intra-sentence and inter-sentential code- and language-switching without manual configuration
Custom vocabulary biasing: Steer speech recognition toward domain-specific terms, uncommon jargon, company names, and proper nouns by passing a custom_vocabulary list of up to 1,000 terms
Smart transcription mode: Deliver polished, reader-ready transcripts with structured formatting, self-corrections, and disfluency removal that eliminates filler words

3.5 Transcribe supports 85+ languages and provides a strong listening engine for voice experiences and stateless tasks like sub-second captioning, call center agents, and real-time audio analytics. You can also access the model via the Interactions API to transcribe audio files up to 1 hour long with structured timestamps and speaker labeling. Read our developer guide to learn more.

Our complete audio suite for developers

To get started, try out the models in ai.studio/live, clone example apps from GitHub, or equip your agent with our live api skill.

You can also create audio experiences with our speech and music generation models, all available in the Gemini API:

Gemini 3.5 Live Translate: Speech-to-speech translation across more than 70 languages
Gemini 3.1 Flash TTS: Highly configurable speech generation (with more updates coming soon)
Lyria 3.5: Production-grade music generation

The mic is yours, and we can’t wait to hear what you build!

How we built a desktop companion robot with Gemma 4 and Raspberry Pi

bebechien — Wed, 16 Sep 2026 10:15:52 +0000

Have you ever wished for a little desk companion—something with the tactile charm of a retro game character that could chat with you, keep track of your desk timers, or talk you through a tricky bug—without a camera staring at you all day?

That question sparked DinoDesk AI: our LEGO Dino AI Companion Robot.

I and my colleague Shama set out to build a smart, low-power desk robot that combines the nostalgia of 8-bit audio-visuals and LEGO Technic mechanics with a modern Hybrid LLM Switching Architecture (Local ↔ Cloud). By pairing a Raspberry Pi on the desk with a local PC gateway running Gemma 4 alongside Gemini Flash, we created a companion that offers 100% visual privacy (no camera), instantaneous zero-cost local chat, and deep cloud reasoning on demand.

Here is the full behind-the-scenes story of how we designed, wired, and programmed DinoDesk AI from the ground up.

1. The Hybrid Brain: Local Gemma 4 ↔ Cloud Gemini

One of the biggest dilemmas when building an AI hardware companion is choosing where the brain lives. If everything runs in the cloud, every casual "What time is it?" costs API tokens, adds network latency, and sends your voice data over the internet. On the other hand, if you strictly limit yourself to a small on-device model, the robot struggles the moment you ask it to create a new feature in your gigantic codebase, or explain a complex topic.

So we decided to build a Hybrid LLM Architecture, with a Unified LLM Gateway (Router) hosted on the user's main PC. The Raspberry Pi on your desk sends identical OpenAI-compatible requests over Wi-Fi regardless of which engine is active:

 ┌─────────────────────────────────────────────────┐
 │           [ Main PC / Local Gateway ]           │
 │                                                 │
 │   ┌─────────────────────────────────────────┐   │
 │   │      Dynamic Model Router / Switch      │   │
 │   └────────────────────┬────────────────────┘   │
 │                        │                        │
 │     ┌──────────────────┴──────────────────┐     │
 │     v                                     v     │
 │  [ LOCAL ENGINE ]              [ CLOUD ENGINE ] │
 │  LM Studio / Gemma 4           Gemini Flash /   │
 │  (Zero Latency, Private)       Gemini Live      │
 └────────────────────────┬────────────────────────┘
                          │
                          │ Wi-Fi (Unified OpenAI-Compatible Stream)
                          v
 ┌─────────────────────────────────────────────────┐
 │           [ DinoDesk AI (RPi) ]                 │
 │  - Pirate Audio LCD & I2S Beep Speaker          │
 │  - Push Button & Optional Sensors               │
 └─────────────────────────────────────────────────┘

Three Modes of Intelligence

Mode	Active Model	Strengths & Primary Use Case	How to Switch
🟢 Local Mode (Default)	Gemma 4 (via LM Studio)	Zero-cost, offline, 100% private. Delivers ~200 ms first-token latency for casual chats, desk timers, and quick status checks.	Double-click Pirate Audio Button X, 3s long-press on Capacitive Touch sensor, or voice command ("Switch to Cloud Mode")
🟡 Cloud Mode	Gemini Flash / Gemini Live	High reasoning & complex problem solving. Ideal for coding help, complex math, deep explanations, or language tutoring (~800 ms first token).	Same as above
⚡ Auto-Hybrid Mode	Automatic Routing	Defaults to Gemma 4 locally. When the complexity classifier detects multi-step reasoning keywords ("explain", "compare", "write code"), it transparently escalates the prompt to Gemini Flash.	Automatic System Routing

When Auto-Hybrid Mode escalates a question to the cloud, the robot's indicator temporarily shifts from 🟢 steady green to 🟡 steady gold for the duration of the response, then returns to green—so you always know at a glance which brain is answering.

2. Hardware & Tactile Mechanics: LEGO Meets Pirate Audio

We wanted DinoDesk AI to feel like a physical toy rather than a cold smart speaker. Instead of 3D-printing a sealed plastic shell, we built the body out of basic LEGO bricks and Technic lever mechanisms so anyone can customize or repair it.

Core Bill of Materials (BOM)

Main Controller: Raspberry Pi + 32GB MicroSD
Display & Audio Shield: Pimoroni Pirate Audio Speaker (1.3" 240×240 ST7789 IPS LCD + I2S 1W Speaker + 4 tactile buttons)
The Red Button: A mini push button switch that gives you a satisfying tactile click to start or stop voice capture
Audio Input: Compact USB Mini Microphone
Motion System: Motors driving Neck movements and Tail wagging

Before building the full body, I first prototyped the logic using a Raspberry Pi and a simple LEGO set.

Physical Button Controls

Even with voice and sensor triggers, dedicated hardware buttons feel good for instant physical control:

Button A (GPIO 5) — Cancel / Mute: Immediately stops the active response stream, silences audio, and returns the robot to Idle.
Button B (GPIO 6) — Home Re-Center: Resets all servos to their neutral center position without interrupting the current state.
Button X (GPIO 16) — Expression & Engine Switch: Single-click cycles facial expressions manually; double-click toggles Local ↔ Cloud Mode.
Button Y (GPIO 24) — Tail Test & Volume: Single-press fires a tail-wagging sequence to verify mechanical alignment; a 2-second long-press cycles beep volume (Low → Medium → High → Mute).

3. Bringing the Dino to Life: The 5-State Finite State Machine

A companion robot only feels alive when its eyes, voice, and body move together. We designed a 5-stage Finite State Machine (FSM) that coordinates the 240×240 LCD eye expressions, 8-bit beeps, and motor movements:

┌──────────┐  button     ┌───────────┐   release   ┌──────────┐   stream   ┌──────────┐
│ Sleeping │──────────>  │   Idle    │────────────>│Listening │─────────>  │ Thinking │
└──────────┘  (wake)     └───────────┘   (trigger) └──────────┘  (send)    └──────────┘
                             ^                                                  │
                             │              ┌──────────┐                        │
                             └──────────────│ Speaking │<───────────────────────┘
                               (done)       └──────────┘       (tokens arrive)

State	Entry Condition	Pirate Audio LCD Expression	8-Bit Audio Feedback	Motor Action (Neck / Tail)
1. Sleeping	Inactive for 3 mins OR room dark	(`- _ -`) Closed eyes + `zzz`	Silent (or optional soft snore)	Motors relaxed; head tilted slightly down
2. Idle	Default standby	(`• •`) Autonomous blinking	Occasional wake/blink chime	Head centers; neck sways slowly
3. Listening	Button click OR sensor trigger	(`O O`) Eyes widen bright	"Beep-Boop!" rising tone	Head tilts 15° toward the user
4. Thinking	Audio sent; router inferring	(`º º`) Spinning pupils + mode badge	Irregular processing ticks (`tick-teek-poh`)	Neck sways slowly side-to-side
5. Speaking	Receiving SSE token stream	Expressive blinking + scrolling subtitles	8-bit typewriter beep per token	Tail wags in sync with text length

Building DinoDesk AI reminded us that AI doesn't have to stay locked inside a browser tab or a cloud data center. When you give an open model like Gemma 4 a pair of pixel eyes, an 8-bit voice, a wiggling LEGO tail, and the ability to call on Gemini when things get heavy, your desk suddenly feels a whole lot more lively. 🦖✨

It's still a work in progress and not quite perfect yet, but I'll be back soon with fully implemented voice chat capabilities! Until then, please enjoy the fun little 8-bit sound effects every time you press the button. Beep-Boop!

Clone the repo here : https://github.com/google-gemma/dinodesk-ai-companion/

And drop a comment to share what you're planning to create.

Embedding versions management, TOAST and bloating in PostgreSQL

Gleb Otochkin — Sat, 12 Sep 2026 00:05:49 +0000

If you are working with vector embeddings you probably already know the AI models including embedding models have their own lifecycle. When a new model is released by a service provider the old version will be eventually deprecated and removed from the service. You might have better control with models deployed on your own infrastructure like EmbeddingGemma in this codelab but eventually you might want the new model just because it works better.

What is the impact of refreshing all the vector embedding in your AlloyDB or PostgreSQL database? Let’s dive in.

Prepare the tests data

Let us prepare a test environment. In my tests I am going to use AlloyDB Omni since it is fully PostgreSQL compatible and in this case behaves exactly like any PostgreSQL database.

We create a test table with the vector data type, add some indexes, and generate 20k rows.

-- Install extensions
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS pgstattuple;

-- Create a function building random vectors
CREATE OR REPLACE FUNCTION random_vector(dim integer)
 RETURNS vector
LANGUAGE sql VOLATILE AS $$
SELECT array_agg(random()::real)::vector FROM generate_series(1, dim);
$$;

-- Create a demo table
DROP TABLE IF EXISTS demo_documents CASCADE;
CREATE TABLE demo_documents (
    id BIGSERIAL PRIMARY KEY,
    category_id INT NOT NULL,
    status VARCHAR(32) NOT NULL,
    title VARCHAR(255) NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    -- Large text column (> 2.5 KB) to demonstrate TOAST interaction with uncompressed/compressed text
    content TEXT NOT NULL,
    -- 768-dim float vector (~3.08 KB) -> pushed to TOAST
    embedding vector(768)
);

-- Pause autovacuum temporarily
ALTER TABLE demo_documents SET (
    autovacuum_enabled = false
);

-- Add a few B-tree indexes
CREATE INDEX idx_docs_category_created ON demo_documents (category_id, created_at);
CREATE INDEX idx_docs_status ON demo_documents (status);
CREATE INDEX idx_docs_title ON demo_documents (title);

-- Create HNSQ index on the vectores
CREATE INDEX idx_docs_embedding_hnsw ON demo_documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Generate some data
INSERT INTO demo_documents (category_id, status, title, created_at, content, embedding)
SELECT
    (random() * 50)::int + 1,
    (ARRAY['draft', 'published', 'archived', 'review'])[(random() * 3)::int + 1],
    'Document title #' || g,
    now() - (g || ' minutes')::interval,
    -- ~3,000 bytes of repetitive text (> 2 KB TOAST threshold)
    repeat('PostgreSQL TOAST and vector storage internals demo ' || g || ' ', 50),
    -- 768-dim vector
    random_vector(768)
FROM generate_series(1, 20000) AS g;

Check the size of all segments

Let’s establish a clear baseline for comparison. We will run an initial vacuum analyze and check all our relations.

-- Run an initial vacuum to start with clean baseline metrics
VACUUM ANALYZE demo_documents;

-- Check all the segments
SELECT
    c.relname AS object_name,
    CASE c.relkind
        WHEN 'r' THEN 'table'
        WHEN 't' THEN 'toast table'
        WHEN 'i' THEN 'index'
    END AS kind,
    pg_size_pretty(pg_relation_size(c.oid)) AS size
FROM pg_class c
WHERE c.relname = 'demo_documents'
   OR c.oid IN (SELECT indexrelid FROM pg_index WHERE indrelid = 'demo_documents'::regclass)
   OR c.oid = (SELECT reltoastrelid FROM pg_class WHERE relname = 'demo_documents')
ORDER BY pg_relation_size(c.oid) DESC;

Here is what we get:

        object_name | kind | size
---------------------------+-------------+---------
 idx_docs_embedding_hnsw | index | 78 MB
 pg_toast_3177242 | toast table | 81 MB
 demo_documents | table | 4336 kB
 idx_docs_category_created | index | 1024 kB
 idx_docs_title | index | 1024 kB
 demo_documents_pkey | index | 512 kB
 idx_docs_status | index | 256 kB
(7 rows)

Our demo_documents table with indexes and TOAST occupies about 170 MB. It might be helpful also to check tuples (physical rows):

-- Dead/Live tuple stats
SELECT 'Main Table' AS component, table_len,tuple_count,tuple_percent,dead_tuple_count, free_percent FROM pgstattuple('demo_documents');
-- TOAST Table Dead/Live tuple stats
SELECT 'TOAST Table' AS component, table_len,tuple_count,tuple_percent,dead_tuple_count, free_percent FROM pgstattuple((SELECT reltoastrelid FROM pg_class WHERE relname = 'demo_documents'));

We see the main table and the TOAST have zero dead tuples and reasonable small free space percentage:

 component | table_len | tuple_count | tuple_percent | dead_tuple_count | free_percent
------------+-----------+-------------+---------------+------------------+--------------
 Main Table | 4440064 | 20000 | 90.92 | 0 | 1.57

  component | table_len | tuple_count | tuple_percent | dead_tuple_count | free_percent
-------------+-----------+-------------+---------------+------------------+--------------
 TOAST Table | 84492288 | 40000 | 74.52 | 0 | 21.82

Here is a basic graph to illustrate the layout:

Updating the vectors

We emulate the process of refreshing embeddings by updating all the vectors in the demo_documents table. For example we had all our embeddings created using Google text-embedding-004 model and we updated all of them using gemini-embedding-2 model. Google publishing life cycle for all its models in the documentation where you can see it and plan your maintenance in advance.

-- Update all vector embeddings
UPDATE demo_documents
SET embedding = random_vector(768);

After updating all the rows we can check the sizes of all objects again and see how they’ve changed:

        object_name | kind | size before update | size after update
---------------------------+-------------+--------------------+-------------------
 idx_docs_embedding_hnsw | index | 78 MB | 156 MB
 pg_toast_3177242 | toast table | 81 MB | 159 MB
 demo_documents | table | 4336 kB | 7376 kB
 idx_docs_category_created | index | 1024 kB | 2048 kB
 idx_docs_title | index | 1024 kB | 2048 kB
 demo_documents_pkey | index | 512 kB | 1024 kB
 idx_docs_status | index | 256 kB | 512 kB
(7 rows)

Almost all objects including table, TOAST and indexes doubled in size. The impact is most visible for the HNSW vector index and the demo_documents table itself. Here is information about dead tuples and space allocation for the main table and TOAST:

 component | table_len | tuple_count | tuple_percent | dead_tuple_count | free_percent
------------+-----------+-------------+---------------+------------------+--------------
 Main Table | 7585792 | 20000 | 47.84 | 20000 | 1.2

  component | table_len | tuple_count | tuple_percent | dead_tuple_count | free_percent
-------------+-----------+-------------+---------------+------------------+--------------
 TOAST Table | 166387712 | 40000 | 37.84 | 40000 | 22.21

Here is a diagram:

So, roughly half of the space is occupied by dead tuples. When I discuss it with some developers they mention the vacuuming process and at least some of them had expectations that it should fix the bloating. Let’s do some vacuuming and see if it changes it.

VACUUM (VERBOSE, ANALYZE) demo_documents;

The verbose output provides enough information about what was done during the vacuum process and everybody who is curious can check it in detail. We can have a look into the main stats about tuples:

 component | table_len | tuple_count | tuple_percent | dead_tuple_count | free_percent
------------+-----------+-------------+---------------+------------------+--------------
 Main Table | 7585792 | 20000 | 47.84 | 0 | 50.16

  component | table_len | tuple_count | tuple_percent | dead_tuple_count | free_percent
-------------+-----------+-------------+---------------+------------------+--------------
 TOAST Table | 166387712 | 40000 | 37.84 | 0 | 60.17

The vacuum process cleared up the dead tuples leaving the space allocation intact and it was exactly what we expected. We have free space which can be used by the new rows but the allocation on the disk didn’t change.

        object_name | kind | size before vacuum | size after vacuum
---------------------------+-------------+--------------------+-------------------
 pg_toast_3177242 | toast table | 159 MB | 159 MB
 idx_docs_embedding_hnsw | index | 156 MB | 156 MB
 demo_documents | table | 7408 kB | 7408 kB
 idx_docs_category_created | index | 2048 kB | 2048 kB
 idx_docs_title | index | 2048 kB | 2048 kB
 demo_documents_pkey | index | 1024 kB | 1024 kB
 idx_docs_status | index | 512 kB | 512 kB

Alternative layout

What if the bloating is a significant issue for your workload? In such a case you might consider a different layout and place the vectors in a separate table connecting to the main table using primary keys. Then you can use either a view or simple table join to work with the data. And when the vectors are required to be updated — create a new table with a new vector version.

Such an approach can save you some vacuum overhead and bloating. But of course the join of two (or more) tables might perform slightly differently than the single flat table approach. You need to test it with your data and with your vectors.

Conclusion

The final layout of your table might depend on multiple factors. In real life I very rarely saw a case when the search was performed only in one single table. In most cases it was always a combination of 2,3,4, or more tables with the resulting dataset. Considering other parts like filters on non-vector columns or full-text search combined with the semantic search, the real case might be much more complicated than a demo with one flat table where all the data is stored in one segment. And for a high-loaded scalable environment, the right relational model can be a key for success and requires vigorous testing.

In the next post I will try to evaluate the performance overhead of keeping the vectors in a separate table vs having them in the same table. Stay tuned!

is Graph Engineering just reinventing systems architecture for the AI age?

Tilde A. Thurium — Thu, 10 Sep 2026 19:23:39 +0000

Bringing backend predictability to multi-agent systems

I've been hearing the phrase "graph engineering" thrown around a lot lately. I originally assumed it had something to do with knowledge graphs, or maybe GraphRAG. Not quite!

I sat down with Annie Wang and asked her to break it down from the ground up: what graph engineering is, and how it gives developers control over complex AI systems.

What's in the video

Demystifying the terms: The actual differences between an agent harness, a loop, and a graph.
A real-world example: Walking through an automated pull request (PR) review pipeline using fan-out, join, and conditional router patterns.
What it isn't: Why graph engineering is fundamentally different from knowledge graphs and agent swarms.
Shared state: How to orchestrate shared state and strict schemas using Google's Agent Development Kit (ADK).

The point that stuck with me is that graph engineering basically feels like modern backend architecture —like microservices— applied to agents. Instead of letting LLMs wander in a black-box loop and hoping for the best, you treat nodes with strict schemas and fan-out/join pipelines. It gives us back the predictability and debuggability that software engineers actually need.

(You can also follow along with the hands-on ADK Codelab).

Did your mental model of "graph engineering" match up? Are you still running straight loops for your agents, or have you started breaking them into graph patterns? Let me know in the comments!

4 pitfalls of loop engineering (and how to fix them)

Tilde A. Thurium — Wed, 09 Sep 2026 17:37:13 +0000

Perhaps you've heard the term Loop Engineering: instead of solving a problem by hand, you build a system, set a measurable goal, and let an agent keep iterating until it gets there.

It sounds great until something goes wrong.

So I sat down with Annie Wang to talk through the four most common ways Loop Engineering breaks down, and how to fix each one.

What's in the video

What Loop Engineering actually means: building an agentic system that retries toward a definable goal
Failure #1 - runaway loops: you need a hard stop rule because tokens cost real $$$.
Failure #2 - unverified autonomy: why letting an agent grade its own work is like asking a kindergartner to grade its own homework, and why you want agent A checking agent B's work instead
Failure #3 - vague or uncheckable goals: why "make this better" breaks an LLM, and how to write criteria that are actually non-negotiable
Failure #4- complexity overflow: when a single loop chokes on a big task, and why that's the moment to move from Loop Engineering to Graph Engineering

Have you hit any of these failure modes yourself? Tell me which one (or more) got you.

Interactive AI Eval Dashboards with Data Studio

Katie McLaughlin — Tue, 08 Sep 2026 07:00:00 +0000

Welcome to the final entry of our series about designing, analyzing and visualizing AI evals! As with the previous entries, you are more than welcome to simply read over my exploration or, for those of you looking for extra credit, feel free to play along at home. If this isn’t you, please skip to "Overview of New Pre-Configured Dashboard Components"

Note: This blog series contains AI-generated diagrams alongside actual screenshots and hand-drawn edits of both. AI also assisted in minor copy editing. Furthermore, the math is mine but the formula formatting is AI's.

Implementation prerequisites

If you intend to (re)implement the procedures in this walkthrough, all you need is the CSV export (data_mega_export.csv) generated during Part 3 (from evaluations performed in Part 1) and a Google Workspace account to access Data Studio. Part 2 will give you a deeper understanding of evals, trace diagnostics and back-of-the-napkin analysis but is optional if you just want to build dashboards.

Back to the story at hand

In this final part of our series, we connect our evaluation dataset to Data Studio to build codeless, interactive dashboards.

While inspect view provides developer-focused TUI trace diagnostics and Google Sheets gives us tabular sparklines, non-technical stakeholders (product managers, business leads, executive sponsors) need interactive dashboards where they can slice performance across our foundational 3D Evaluation Matrix on the fly without writing code. Beyond macro dimensions like model family and skill group, our dashboard empowers users to dynamically partition data over key operational booleans:

completed (Conditional Accuracy): Isolates Model Capability (accuracy on completed runs) from infrastructure noise (quota drops, timeouts, container crashes). Toggling between TRUE and ALL exposes Survivorship Bias in task execution.
is_baseline_or_has_activated_skill (Conditional Uptake Slicer): Separates baseline control cohorts from active skill interventions where the model invoked activate_skill (i.e. uptook the skill into context).
- Crucially, "activated" in Inspect AI telemetry specifically tracks skill uptake (executing the activate_skill tool call). Filtering for FALSE isolates dormant runs where a skill was available but never uptaken.

1-click Data Studio template setup

We provide a pre-configured Master Dashboard Template containing all pre-styled components used here.

Clone the master template

Open the Inspect AI Dashboard Template.
Click Make a copy

30-second setup and customization

Once cloned:

In the new report, press Add data
Select Google Sheets
Select the Spreadsheet and the Worksheet (likely the sole Worksheet) you created in the third entry and press Add
Select all the components and set their data source to that sheet
Finally, select the bubble chart and open the Style tab, find the Bubble color dropdown and set it to ‘model’

That's it! Your interactive dashboard is now live, fully bound to your evaluation data.

Before diving into the new charts, check out the bottom left corner of the report. There you will find a Pivot Table Heatmap. Like the heatmap I made in the second entry in this series, this heatmap is a 2D visual matrix where color intensity represents numerical magnitude—here, quadratic curved accuracy scores. Since I already discussed how to use these for analysis in the earlier blog entry, I will not be explaining it here. If, on the other hand, you are interested in implementation, feel free to inspect and adjust the settings on the Pivot Table Heatmap in your copied report.

Note: This screenshot was done on a later dataset than the rest of the report and the specific metrics should not be taken into account when comparing to the rest of the screenshots here.

Overview of new pre-configured dashboard components

Data Studio translates multi-dimensional evaluation CSV data into intuitive visual dimensions (spatial X/Y coordinates, bubble area scaling, color coding, and hover popovers). Here is how each pre-built dashboard element visually measures evaluation performance:

Chart A: Performance and cost (scatter/bubble chart)

This chart maps three core evaluation dimensions onto a single 2D visual canvas:

Horizontal Position (X-Axis ➔ Latency): Measures average task duration in seconds. Bubbles placed further to the right represent slower runs.
Vertical Position (Y-Axis ➔ Score / Accuracy): Measures average task accuracy from 0.0 to 1.0. Bubbles placed higher up represent better accuracy.
Bubble Size / Area (Visual Cost & Unit Economics): Circle size scales with average task cost for a quick visual gut-check.
Hover Tooltips & Sub-Cent Formatting: Hovering displays latency, accuracy, model, skill group, and cost formatted as Currency > USD (#,##0.0000) so sub-cent costs (e.g., $0.0044) don't round to $0.00.

Chart B: Accuracy and error bars (±1 SEM whiskers)

The second pre-configured chart visualizes accuracy scores alongside standard error of the mean (SEM) whiskers.

Visual Whisker Bounds: The bar height shows average accuracy (score), while floating dots above and below show upper (score_lower) and lower (score_upper) standard error bounds.
Design Note (Multi-Metric vs. Breakdown Dimension Constraint): Data Studio won't let you use a Breakdown Dimension if you're plotting multiple Y-axis metrics on the same chart. Because our whiskers need three Y-metrics (score, score_lower, score_upper), we put model on the X-axis and filter by skill_group using top-level drop-downs instead.

Statistical Rigor Note: Standard error tracks pass/fail score variation across runs. Our demo ( $N = 4$ ) covers a ~68% confidence range ( $\pm 1 SEM$ ), while production benchmarks require $N \geq 30$ for standard 95% confidence intervals.

The 4 dynamic cohort slicers (drop-down controls)

Located across the top control bar, these four drop-down lists act as interactive dynamic filters, immediately re-rendering both canvas charts in real time:

model Slicer: Filters results by model family (gemini-3.5-flash-lite vs gemini-3.6-flash).
skill_group Slicer: Filters by skill setup (gemini-api, gcloud, baseline control).
is_baseline_or_has_activated_skill Slicer (Conditional Uptake): Separates Baseline controls and Active Skill runs (TRUE via activate_skill) from Dormant runs (FALSE, offered but uncalled). Activation confirms tool uptake, not instruction compliance.
completed Slicer (Conditional Accuracy / Infrastructure Noise): Filters clean runs (TRUE) from system failures (FALSE for quota drops, timeouts, container crashes).
- Relevance Note: This is vital for production sweeps hit by rate limits or timeouts—selecting TRUE measures Model Capability (Conditional Accuracy), while FALSE or (All) shows the full audit trail.

View and interact

Click the blue View button in the top right corner to see the dashboard as a user would.
Use the model, skill_group, completed, and is_baseline_or_has_activated_skill drop-downs at the top.
Notice how both the Bubble Chart and the Bar Chart update instantly in unison to show only the models or skills you selected!

Slicer-based analyses

While the model slicer would be useful in a situation with more models, since we only have two and you can visualize them using the existing coloring. skill_group on the other hand is more interesting

On selecting gemini-api (Skill) and gemini-api (Baseline), there are a couple visually apparent trends. As discussed in previous sections, the gemini-api (Skill) run improved the evaluation score at the price of increased latency and cost.

Conditional uptake analysis: Separating skill discovery from capability

By filtering for runs where is_baseline_or_has_activated_skill is FALSE, we perform a Conditional uptake analysis: examining dormant runs where a skill was provided in context (Prior), but the agent chose not to call activate_skill (zero uptake).

Baseline or has activated skill = false (notice these both score relatively low)

Baseline or has activated skill = true

One thing to note immediately is that the total number of bubbles is GREATER than 8 (the count of Model x Skill combinations). This is because each of these bubbles are subsets of the Model x Skill x Sample x Epoch space in that this distinction is made at the samples/epochs level.

In Inspect AI telemetry, "activated" specifically measures uptake—whether the model executed the activate_skill tool call to load the skill into context. Interestingly, the samples of 3.5-flash-lite where the skills were activated have a much higher visual ceiling than the general case (Baseline or Has Activated Skill = Any) corresponding to the elimination of Baseline or Has Activated Skill = False.

Noting that only 3.5-flash-lite had samples where it didn’t activate a provided skill, it may be worth investigating if this is a more general trend.

Survivorship bias and joint operational uptime (`completed` analysis)

For the sake of further exploration, I reran the evals with web search enabled and the same time limit.

inspect eval skills-eval.py \
  --model google/gemini-3.5-flash-lite,google/gemini-3.6-flash \
  --time-limit 300 \
  --epochs 2 \
  --max-tasks 4 \
  -T web_access=true

Running all of these evals serially and in parallel causes them to use too much web search quota and reach the unforgiving time-limit. As such, the most realistic run configuration would be to increase the time limit and use the built-in adaptive rate limits. The problem is this would last a lot longer and take more resources than I care to ask you to emulate.

So let’s look instead at the results of the web search enabled, 300 second time limit run:

completed: ALL

Since this graph contains every model x skill x sample x epoch, you can eyeball the average metric values of a number of bubbles by imagining the centroid of the polygon they define on the space.

Some of the most obvious conclusions in our local web-search enabled eval sweep: 3.5-flash-lite recorded lower latency than 3.6-flash, while their average scores were comparable. To reason about what this might mean, refer to the Gemini API Model Documentation for official model latency, throughput, and performance specifications. Instinctually, this makes me want to check if the timed out runs (counted as score 0) affected 3.6-flash more (since it didn’t complete as quickly in these samples). To test this, let’s see how scores look when we only count completed runs.

completed: TRUE

When filtering the web-search rerun sweep strictly for completed runs (completed = TRUE), the average score for the 3.6-flash sample cohort trended slightly higher, converging between 0.5 and 0.6 for partially scoring runs (which earlier averaged between 0.35 and 0.60 when completed = ALL).

Isolating completed = TRUE calculates Conditional Accuracy (Model Capability on completed runs). However, if longer or more complex tasks disproportionately trigger time-limits, filtering out incompletes introduces Survivorship Bias, truncating the difficult tail of your test set. Comparing completed = ALL against completed = TRUE bridges the gap between pure model intelligence and total operational system reliability for given limits.

Are these findings generalizable to every scenario?

While we’ve uncovered a promising trend, the next step is to validate it with statistical rigor. Think of our current demo ( $N = 4$ ) as an exploratory pilot; it’s great for spotting trends, but we need more data to confirm them. To verify these results aren't coincidental, I encourage you to scale your runs to $N \geq 30$ . With this larger sample size, you can achieve statistical significance, a metric used to ensure that your findings aren't just a random outlier. This is supported by the p-value—a standard calculation that gives you the probability that your results are a fluke. Aiming for a low p-value is the final step in moving from exploratory analysis to building the mathematically sound, launch-ready benchmark required for production.

Conclusion and next steps: Where to go from here

We’ve come full circle in this series—from running terminal-based evaluation sweeps with Inspect AI in Part 1, to analyzing multi-turn LLM reasoning traces in Part 2, modeling tabular metrics with pandas in Part 3, and finally assembling interactive, codeless BI dashboards here in Data Studio.

Now that you have the end-to-end telemetry pipeline running, the floor is yours to explore! Here are a few directions you can take your evaluation harness next:

Custom Calculated Metrics: Experiment with custom formulas in Data Studio to track ROI metrics, cost per successful task, or normalized token efficiency ratios.
Expanded Matrix Sweeps: Scale your evaluation matrix across new LLM provider endpoints, prompt techniques, or tool playbooks.
Direct Database Connectivity: Replace the static CSV / Google Sheets ingestion layer with a direct connector to BigQuery, PostgreSQL, or Cloud Storage for automated, streaming evaluation updates.
Automated Alerting & Thresholds: Set up automated notifications when a new model deployment drops below baseline accuracy or exceeds latency/cost budgets.

Thank you for following along with this series, and happy evaluating!

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!

How to Write Reliable Rubrics for LLM-as-a-Judge Evaluations

Jan-Felix Schmakeit — Wed, 02 Sep 2026 16:35:00 +0000

Follow up to Part 1: How to Design AI Evaluations You Can Actually Trust

At Google, we are publishing a suite of Agent Skills for Google products and technologies on GitHub. My team is interested in measuring their performance to understand how they perform. Deterministic tests, like checking if generated code compiles, are ideal. Unfortunately they can't be easily created at scale for nuanced, generative responses, such as answers to open-ended questions or information retrieval tasks.

In my previous post we looked at what you test, which means the evaluations that are the actions you ask the agent to perform. The next step is to look at how you assert whether the agent succeeded. This means creating reliable and accurate assessments of the agent's response.

To assess complex outputs at scale, especially when topics cover broad areas with nuanced parts, we use an "LLM-as-a-judge" approach. Responses are assessed against a structured rubric using a model based grader. The judge evaluates each response using a set of true/false questions. Aggregated, these answers provide an accuracy score for a response.

Giving an LLM a vague prompt or subjective questions leads to ambiguity in its response. This ambiguity introduces noisy data and causes inconsistent evaluations. Ultimately, it wastes your token budget on metrics that aren't useful.

To make these assessments more reliable, you must treat your rubrics like formal specifications. By constraining the judge to evaluate strict, objective boolean truths, you reduce the chance of hallucinations. Because evaluating strict boolean truths is a less complex task, you can even use smaller, faster models for grading.

Here are four lessons we learned to help you write robust rubric questions for your LLM-as-a-judge scorer.

Keep Questions Atomic and Distinct

Evaluating multiple requirements in a single question, such as "Does the response contain a metadata property and format the output as JSON?", forces the LLM judge to guess which clause is more important. This ambiguity leads to inconsistent grading and wasted tokens.

Split compound questions: Instead of writing one large check, divide your requirements into discrete, atomic TRUE/FALSE questions. (e.g., Check 1: Does it contain a metadata property? AND Check 2: Is the output JSON?)
Avoid overlapping questions: Never test the same underlying concept multiple times across your rubric. Overlap risks double-penalizing the evaluated model for a single mistake, which corrupts your accuracy score.
Reduce the reasoning load: Eliminate the need for the judge to weigh competing clauses. When every question assesses exactly one distinct fact, your grading becomes more consistent.

Constrain the Judge: Objective Facts Over Subjective Reasoning

The rubric-based approach exists because giving an LLM judge a full prose prompt to evaluate a complex response leads to inconsistent numbers. If you ask the judge subjective questions like "Was this a comprehensive answer?" or ask it to explain "Why did the agent do this?", you introduce ambiguity that creates noisy, unrepeatable data.

Focus on observable facts: Do not ask the judge to evaluate concepts that require interpretation, such as intent, quality, or reasoning. Only assess concrete facts that you expect to find in the response.
Write formal specifications: Use strict, objective language, such as RFC 2119 terminology (MUST, MUST NOT, REQUIRED), to test for observable outcomes. The judge should never have to guess what you mean.
Test for negative constraints: Explicitly verify what the agent should not do. Instead of asking if the agent "used best practices", check that it did not suggest a specific deprecated feature.
Require strict true/false answers: By forcing a strict TRUE/FALSE classification on objective facts, you reduce the reasoning load and reduce the variance in ratings.
Avoid opportunities for cheating: Agents will tailor answers to game your tests if given the chance. Keep scoring rubrics isolated in a separate system. Design rubrics that focus on strict functional outcomes or specific topics, rather than broad keywords matches.

Grade Only What You Asked For

When building rubrics, it is easy to accidentally evaluate an agent on requirements that were never stated in the prompt. Doing this creates false negatives and reduces the accuracy of your measurement.

Align the rubric to the prompt: Assess only what was explicitly requested. For example, do not penalize a model for failing to provide citations if the prompt never asked for them.
Grade the destination, not the journey: Avoid writing rubrics that check if the agent used a specific tool or followed a rigid sequence of steps. Pre-trained models might bypass custom tools entirely if they already know the answer.
Evaluate the final response: Grade the objective output. If you need to evaluate a step-by-step process, prompt the agent to output an execution plan and evaluate the plan itself.

Calibrate Your Judge

Even if you follow these rules and write perfectly atomic, objective questions, your LLM judge might still misinterpret your scoring instructions and rubrics. To guarantee your pipeline generates consistent ratings and reliable signals, you must prove that the judge's scoring aligns with how a human subject matter expert would evaluate the exact same response through calibration.

Establish a human baseline: Ask subject matter experts to manually grade a "golden set" of test responses.
Run the comparison: Run your LLM-as-a-judge against this golden set and compare the automated scores against the human scores.
Identify the delta: If the LLM judge disagrees with your human experts, it is usually a sign that your rubric or the grading instructions are too ambiguous.
Iterate until aligned: Tweak and calibrate your rubric questions or the scoring instructions until the LLM judge consistently aligns with human experts. Only then is your judge ready.

Summary

Once you have this reliable data, the next step is making it visible. In AI Evals at a Glance: Heatmaps for Stakeholders Joe Spiro explains how to take these raw measurements and visualize evaluations.

When building our agent skills, we learned that ambiguous evaluation rubrics do not provide useful signals and feedback. Forcing your LLM judge to evaluate strict, boolean facts eliminates this noise. It makes your tests repeatable, optimizes your token spend, and lets you confidently measure whether your AI tool is actually improving.

Photo by William Warby on Unsplash

DEV Community: Google AI

Equip your agent with Google Cloud best practices using google-cloud-developer plugin

Quick install: Five skills and an MCP server

Knowledge grounding: Writing modern SDK code without hallucinations

Informed architecture: Evaluating database options with Developer Knowledge

Cost guardrails and onboarding: Verifying billing before enabling APIs

How agy helps: Scheduling timers for billing propagation

Security enforcement: Least-privilege IAM

Cloud Run deployment

How agy helps: Running long tasks in the background

Live verification: Streaming and per-user token persistence

Summary

Next steps

Connect with me

Claude Opus 5.5 is now available on Google Cloud

Build real-time voice applications with Gemini 3.8 Live and 3.5 Transcribe

Gemini 3.8 Live & 3.8 Live Extended Thinking: Build more intelligent conversational agents

Gemini 3.5 Transcribe: Convert streamed speech to text

Our complete audio suite for developers

How we built a desktop companion robot with Gemma 4 and Raspberry Pi

1. The Hybrid Brain: Local Gemma 4 ↔ Cloud Gemini

Three Modes of Intelligence

2. Hardware & Tactile Mechanics: LEGO Meets Pirate Audio

Core Bill of Materials (BOM)

Physical Button Controls

3. Bringing the Dino to Life: The 5-State Finite State Machine

Embedding versions management, TOAST and bloating in PostgreSQL

Prepare the tests data

Check the size of all segments

Updating the vectors

Alternative layout

Conclusion

is Graph Engineering just reinventing systems architecture for the AI age?

What's in the video

4 pitfalls of loop engineering (and how to fix them)

What's in the video

Interactive AI Eval Dashboards with Data Studio

Implementation prerequisites

Back to the story at hand

1-click Data Studio template setup

Clone the master template

30-second setup and customization

Overview of new pre-configured dashboard components

Chart A: Performance and cost (scatter/bubble chart)

Chart B: Accuracy and error bars (±1 SEM whiskers)

The 4 dynamic cohort slicers (drop-down controls)

View and interact

Slicer-based analyses

Conditional uptake analysis: Separating skill discovery from capability

Baseline or has activated skill = false (notice these both score relatively low)

Baseline or has activated skill = true

Survivorship bias and joint operational uptime (completed analysis)

completed: ALL

completed: TRUE

Are these findings generalizable to every scenario?

Conclusion and next steps: Where to go from here

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

How `agy` helps: Scheduling timers for billing propagation

How `agy` helps: Running long tasks in the background

Survivorship bias and joint operational uptime (`completed` analysis)