标签：#adk

The correlation notice fired. Three sites, same anomaly type, inside the time window. The orchestrator caught it and logged it, live, against the deployed service. Clean, first try. Then I asked myself a question I almost didn't bother asking, because the thing had just worked: why did it work? The answer wasn't "because the logic is correct." It was "because Cloud Run happened to route both requests to the same running instance." Well, shit. My orchestrator was holding its list of recent risk events in a plain Python list, in process memory. Worked in local testing because there's only one process. Worked live because Cloud Run, under light traffic, often reuses the same instance instead of spinning up a second one. Neither one's a guarantee. The moment traffic patterns shifted and two readings landed on two different instances, the second instance wouldn't have a clue the first one existed. A correlation that should fire would just silently not. A bug that passes its own demo is the hardest kind to catch. There's no error to chase. There's just a checkmark. What I was building VES Fleet is a network of independent site-agents (Bori, Choba, Etche, three real survey sites in the Niger Delta). Each one reads an underground electrical survey, send current into the ground, measure how it flows back, a real physical signal of what's down there, and calibrates its own contamination-risk threshold from its own site's real history. Not a number copied from anywhere else. An orchestrator watches for the same risk signature showing up at more than one site inside a time window. It's my submission to the Fortified Enterprise Fleet track of Google's All Things Agentic Hackathon. Architectural discipline is 30% of the score there. Proving it actually runs on Google Cloud is a separate 30%. So a bug that only looked fixed was never going to survive someone actually reading the state-management story. Checking the thing that already worked Once I understood the actual failure mod

This post is my submission for DEV Education Track: Build Multi-Agent Systems with ADK . What I Built I built an Autonomous Multi-Agent Handwritten Notes Generator . Students and educators often need clean, visual study guides that resemble real handwritten notes, but manually summarizing technical subjects and formatting them takes hours. This system solves that by combining autonomous web research, structured note extraction, and headless browser rendering. You enter any topic or question, and a coordinated team of AI agents researches the concept, formats it into a notebook layout using Google handwriting fonts ( Caveat ), and captures a high-resolution .png notebook page screenshot. Deployment & Repository Links: GitHub Repository: himanshuyeolecse-jpg / multi-agent-handwritten-notes An autonomous multi-agent system built with LangGraph, Tavily, and Playwright that researches complex topics and renders handwritten-style student study notes into PNG screenshots. multi-agent-handwritten-notes An autonomous multi-agent system built with LangGraph, Tavily, and Playwright that researches complex topics and renders handwritten-style student study notes into PNG screenshots. 🎓 Multi-Agent Handwritten Notes Generator An autonomous multi-agent workflow built using LangGraph , LangChain , Tavily Search , and Playwright . The system researches complex technical concepts and dynamically compiles the findings into styled, handwritten-notebook PNG screenshots. 🏗️ System Architecture [ User Input / Prompt ] │ ▼ [ Researcher Node ] ── (Tavily Web Search & Summarization) │ ▼ [ Note Renderer Node ] ── (HTML/CSS + Google Caveat Font + Playwright Screenshot) │ ▼ [ Critic Node ] ── (Validation Check: Is Output Complete?) │ Approved? ──► No ──► [ Researcher Node ] │ Yes ▼ [ PNG Screenshot Saved ] ⚡ Features Autonomous Research: Uses Tavily API to fetch up-to-date technical context. Dynamic HTML/CSS Rendering: Formats structured summaries into a paper-notebook layout utilizing… View o

This post is my submission for DEV Education Track: Build Multi-Agent Systems with ADK . Finding the perfect, thoughtful gift shouldn't feel like a chore. Whether it's for a birthday, anniversary, or holiday, we all experience gift-buying paralysis: Generic suggestions : "Just buy them a mug or a generic gift card." Budget anxiety : Falling in love with an idea only to find out it costs 3x what you planned to spend. Missing the subtle nuances : Forgetting that someone dislikes clutter, lives in a tiny apartment, or prefers practical experiences over physical objects. To solve this, I built GiftAdvisor . It is an intelligent, consumer-friendly gift recommendation system built with Google Agent Development Kit (ADK) , Gemini ( gemini-3.1-flash-lite ) , and deployed seamlessly to Google Cloud Run . Live Demo & Links Live Cloud Run App : https://gift-advisor-1008832068452.us-central1.run.app GitHub Repository : https://github.com/inusha-thathsara/Multi-Agent-Gift-Idea-Generator-with-Google-ADK What I Built GiftAdvisor transforms unstructured descriptions of a person into tailored, ranked, and strictly budget-compliant gift recommendations. Instead of dumping everything into a single monolithic prompt, GiftAdvisor splits the cognitive load across three specialized AI agents orchestrated via Google ADK: Profile Analyzer Agent : Understands the human behind the prompt (lifestyle, hobbies, aesthetic preferences, and explicit anti-preferences ). Idea Finder Agent : Brainstorms creative, thoughtful candidate gifts across multiple categories with estimated market prices. Budget Filter Agent : Audits estimated prices, filters out anything exceeding the user's hard budget limit, swaps in budget-friendly alternatives, and delivers a ranked curation. Key Highlights & Features Pure Multi-Agent Pipeline : Built using Google ADK's LlmAgent , SequentialAgent , and InMemorySessionService . Zero-Overhead Scale-to-Zero : Deployed to Google Cloud Run with min-instances=0 (scales to zero w

This article provides a step-by-step guide to building and testing a cross-cloud currency agent. A coordinator built with Strands Agents and hosted on Amazon Bedrock AgentCore Runtime (in AWS us-east-1 ) discovers and delegates to a Google ADK agent (on GCP Cloud Run in us-central1 ) over A2A v1.0 , cross-checks results against an MCP exchange-rate tool , and measures what independent cross-cloud verification costs in latency, reliability, and overhead. What is This Project Trying to Do? Most Agent-to-Agent (A2A) protocol demos stop at "look, the HTTP 200 OK request succeeded." That is a smoke test, not an interoperability benchmark. This project goes further: an Amazon Bedrock AgentCore-hosted Strands Agents coordinator discovers and delegates to a Google ADK agent running on GCP Cloud Run, comparing the results against a local MCP stdio exchange-rate tool backed by live Frankfurter daily reference rates. We also compare the performance, developer experience, and wire compatibility directly against our previous benchmark run hosted on Microsoft Foundry in Azure ( gpt-5-mini ), giving us a true cross-cloud benchmark across AWS, Azure, and GCP. The questions we answer with hard empirical data rather than vibes: Can an AgentCore-hosted Strands agent discover and invoke a Google ADK agent through an A2A agent card with no framework-specific glue? What latency and token overhead does remote-agent verification add? Does independently verifying an MCP tool result over A2A improve correctness or failure recovery enough to justify that overhead? How does AWS Bedrock AgentCore Runtime compare like-for-like with Microsoft Foundry on Azure? Reduce, Re-Use, Re-Cycle! This builds directly on the currency agent from the previous articles in this series: Getting Started with MCP, ADK and A2A | Google Codelabs GitHub - jackwotherspoon/currency-agent That agent — built with Google ADK, Gemini 2.5 Flash, and a FastMCP exchange-rate server backed by the free Frankfurter API — serves a

This post is my submission for DEV Education Track: Build Multi-Agent Systems with ADK . What I Built Preparing for technical interviews can be overwhelming. I wanted to build a tool that doesn't just give generic questions, but actually analyzes my specific resume to challenge my unique skill set. This led me to build a multi-agent system using the ADK. This multi-agent system, will take user resume and extracts their profile for generating Interview Questions specialized to the candidate profile. The agents communicate in a sequential loop: The Profiler extracts data -> The Interviewer generates questions -> The Judge validates them. If the Judge rejects a question, the Interviewer re-drafts it, ensuring only high-quality, resume-relevant questions make it to the user. Cloud Run Embed Your Agents Profiler Receives a resume PDF GCS path, downloads it in-memory, parses the text content, and builds a summary of skills. Interviewer Reads the candidate summary and drafts 3 technical interview questions designed to test the boundaries of their experience. Analyzes the drafted questions. Passes the iteration if they are resume-specific; rejects/fails them if they are too generic. Key Learnings This project was a fantastic weekend challenge. Working through the Google Codelab gave me a solid grasp of agent-based architectures, specifically implementing Agent, LoopAgent, and SequentialAgent to create a robust workflow. A few key technical takeaways included: Managing Statelessness : Learning to handle agent sessions in a Cloud Run environment was a great lesson in explicit session lifecycle management. Cloud Integration : Integrating Google Cloud Storage for file handling taught me how to bridge in-memory document processing with persistent cloud storage efficiently. Deployment Architecture : Mastering the transition from local development to a containerized, production-ready Cloud Run deployment provided deep insights into modern backend orchestration. Check the Code from

When building multi-agent systems, rigid state graphs quickly fall apart in the face of dynamic user inputs. Imagine building a smart assistant: a user hands you a checklist of three household chores today, but tomorrow it might be a list of ten software debugging tasks. Because the number of tasks, their sequence, and their execution details are entirely runtime-dependent, you cannot hardcode this path at design time. Forcing dynamic lists of work into a static graph-based workflow can lead to fragile, over-engineered code. You need a workflow that adapts dynamically at runtime. The Google Agent Development Kit (ADK) provides a flexible programming model to define dynamic workflows . With the release of ADK 2.4.0 , triggering these workflows has become even more seamless: you can register a Workflow directly in an agent's tools list, allowing the coordinator agent to execute it automatically as a first-class tool. In this article, you learn how to configure and trigger a dynamic workflow directly from a coordinator agent. This guide uses a task list coordination example, but you can adjust this pattern to other dynamic orchestration needs. The architecture of a dynamic workflow Static workflows define the execution path at design time. Dynamic workflows, however, allow agents to invoke tools, spawn other nodes, and schedule sub-agents conditionally at runtime. The system consists of three main components: Root agent ( root_agent ) : Gathers the list of tasks from the user, requests final approval, and directly calls the tasks_workflow tool. The workflow ( tasks_workflow ) : A Workflow that iterates over the approved tasks. Sub-agent ( task_explainer ) : An Agent tasked with generating a step-by-step execution plan for each task. Here is the architectural diagram of the solution: Technical implementation Let's break down how to implement this solution using the Google ADK library in Python. The complete code resides in the devrel-demos repository with core logic in

TL;DR — This article is going to be jam-packed with useful information, tips, tricks and hacks for setting up an agentic development in the Google ecosystem. This one isn’t really about the FinOps! Welcome to Part 2 Welcome back, friends! In the first part , I described the purpose of the FinSavant FinOps solution, the motivation for creating it, its overall architecture and tech stack, and how it works. In this part, we’ll use FinSavant as a case study in how to set up a development environment for the purposes of building such an ADK-based agentic solution. Even if you’re not particularly interested in FinSavant itself, I hope you’ll find a bunch of useful information and tips here that will help you build your own agentic solutions more effectively and quickly. We’ll cover: Using Antigravity IDE Overall project workspace structure Setting up agent skills for your coding agent My project’s GEMINI.md (or if you prefer, AGENTS.md ) My documentation approach Setting up MCP servers for your coding agent, such as BigQuery MCP Scaffolding the initial ADK agent using Google Agents CLI and its supporting skill Getting started with a Makefile Sound good? Let’s get cracking! Series Orientation Let’s see where we are in this series. Goals, Architecture, and Tech Stack: Capabilities, project goals, target architecture, technology stack, and design decisions. Development Environment Setup, Google Antigravity, MCPs and Skills, and ADK Bootstrapping with Agents CLI 📍 You are here. Building the ADK Agent and API Designing and Building the UI with Google Stitch and A2UI Deployment with Gemini Enterprise Agent Platform, Agent Runtime, Cloud Run and IAP Automating Deployment with CI/CD and Terraform Agent Observability, Evaluation, and Tuning with Gemini Enterprise Agent Platform Getting Started with Antigravity IDE These days, my favourite coding environment for any significant project is Antigravity IDE. This is Google’s agent-first integrated development environment. You get a lo

This week's Java roundup for July 6th, 2026, features news highlighting: the GA release of TornadoVM 5.0; point releases of JHipster, Keycloak and Google ADK; maintenance releases of GraalVM Native Build Tools and Micronaut; the OmniFish Build of Payara and introducing Vidocq, a new implementation of the Jakarta EE 11 Core Profile and MicroProfile 7.1. By Michael Redlich