DEV Community: Anil Kumar

How Gemini Live API Turns a Dancer's Body Into a Real-Time AI Prompt — No Keyboard Required

Anil Kumar — Mon, 16 Mar 2026 23:45:00 +0000

Built for the #GeminiLiveAgentChallenge · Live demo: nritya-ardance.web.app · Source: github.com/anil9973/nritya

The Problem Gemini Just Solved

Bharatanatyam — India's 2,000-year-old classical dance — encodes an entire spoken language in the body. 108 hand gestures. 9 emotional states. Complete mythological narratives told without a single word.

For every performance ever staged, the audience understood almost none of it.

Pre-written subtitles require preparation. Human interpreters require choreography. Turn-based AI APIs introduce 2–5 seconds of latency — the dancer completes three gestures before the first response arrives.

The Gemini Live API changed the calculus entirely.

Nritya is the first system that watches a live Bharatanatyam performance, identifies each gesture the moment it is held, and narrates its 2,000-year-old meaning to the audience — in the same breath the dancer performs it. No preparation. No human interpreter. No perceptible delay.

The dancer's body is the only prompt Nritya needs.

Why This Required the Gemini Live API Specifically

This is not a "we used AI" story. Three architectural requirements made Gemini Live the only viable foundation:

1. Sub-300ms multimodal perception

Every other vision API is turn-based. Send image → wait → receive response. At 2–5 seconds round trip, a classical dancer has already completed the gesture, transitioned to the next, and begun a third. The narration would always lag the performance by several beats.

The Gemini Live API maintains a persistent bidirectional WebSocket. A pose-lock event fires the moment both wrist velocities drop below 3px/frame. A JPEG frame and skeletal JSON reach Gemini before the dancer has exhaled. Narration begins within 300ms of the pose completing.

That latency number is not a marketing claim — it is the architectural requirement that made the product possible.

2. Simultaneous tool calls and live audio

Every other approach requires a choice: the AI either speaks or acts. It calls a tool and waits for confirmation, then speaks. Or it speaks and defers the tool response.

The Gemini Live API's interleaved output stream eliminates this constraint. In a single turn, Gemini:

Calls trigger_mudra_lock — sacred geometry snaps to the dancer's wrist
Calls update_story_card — Sanskrit translation pushes to the AR HUD
Simultaneously streams PCM16 narration at 24kHz

The audience sees the visual feedback and hears the poetry at the same moment. Neither waits for the other. This simultaneity is not achievable with any sequential API.

3. Persistent creative persona across the full performance

The Gemini Live API maintains conversational context for the entire session. Nritya's system prompt defines a complete theatrical persona — the Sutradhara, the ancient thread-holder of Indian theater — and Gemini inhabits it from the opening gesture to the final bow. The AI remembers which Rasas have already been narrated, avoids repeating the same poetic framing, and escalates its language when the performance reaches its climactic moments.

That consistency is only possible with a persistent session. Stateless APIs would start fresh at every gesture.

The Architecture

sequenceDiagram
    participant D as 💃 Dancer
    participant B as Browser Client
    participant F as Firebase Functions
    participant G as Gemini Live API
    participant V as Vertex AI Imagen 3

    D->>B: Holds Alapadma mudra
    Note over B: Wrist velocity drops below 3px/frame
    B->>F: POST /generateLiveToken
    Note over F: authTokens.create() — uses:1, TTL 30min<br/>API key stays server-side
    F-->>B: { token: "ya29.ephemeral..." }
    B->>G: WebSocket wss://...?access_token={token}
    Note over G: Token consumed on connect — replay impossible
    B->>G: sendRealtimeInput { JPEG + skeletal JSON }
    G->>B: toolCall: trigger_mudra_lock(LOTUS_OUTLINE)
    G->>B: toolCall: update_story_card(sanskritTitle, narrativeText)
    G-->>B: PCM16 audio stream begins simultaneously
    Note over B: Sacred geometry + Story Card + Voice<br/>all arrive in the same turn
    G->>V: image_gen_prompt → Tanjore artwork
    V-->>B: base64 PNG → GSAP crossfade

The full stack is Google Cloud native — Gemini Live API, Vertex AI Imagen 3, Firebase Functions, Firebase Hosting. Zero third-party AI services.

Three Technical Decisions Worth Copying

Ephemeral Token Security (Production Pattern)

The Gemini API key never reaches the browser. Firebase Functions mint a one-use token with a 30-minute TTL. The browser opens the WebSocket directly using this token, which is invalidated on connection.

// Firebase Function — generateLiveToken
import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({});
const expireTime = new Date(Date.now() + 30 * 60 * 1000).toISOString();

const token = await client.authTokens.create({
  config: {
    uses: 1,
    expireTime,
    newSessionExpireTime: new Date(Date.now() + 60 * 1000).toISOString(),
    httpOptions: { apiVersion: "v1alpha" },
  },
});

res.json({ token: token.accessToken });

// Browser — connect with ephemeral token, not raw API key
const { token } = await fetch(VITE_FIREBASE_FUNCTION_URL).then(r => r.json());

this._ai = new GoogleGenAI({ accessToken: token });
this._session = await this._ai.live.connect({ model, config, callbacks });
// Token consumed here — permanently invalidated

This is not a hackathon shortcut. This is the production security pattern Google recommends for any client-facing Gemini Live deployment.

NON_BLOCKING Tool Calls — The Simultaneity Key

The critical declaration that enables simultaneous narration and tool execution:

// Tool declared as NON_BLOCKING — Gemini continues speaking while the client processes
{
  name:     "update_story_card",
  behavior: Behavior.NON_BLOCKING,  // narration never pauses for this tool
  parameters: { /* ... */ }
}

// Tool response with SILENT scheduling — Gemini resumes from where it left off
session.sendToolResponse({
  functionResponses: [{
    id:   fc.id,
    name: fc.name,
    response: {
      result:     "ok",
      scheduling: FunctionResponseScheduling.SILENT,
    },
  }]
});

Without NON_BLOCKING, every update_story_card call would pause the narration until the client responded. The audience would hear a gap between sentences — a glitch that breaks the theatrical immersion completely.

Dual mediaChunks — Multimodal Context in One Message

Each frame send carries both visual and structured data as separate chunks:

session.sendRealtimeInput({
  mediaChunks: [
    {
      // Clean video frame — 512×512 JPEG, video-only (no canvas trails)
      // Gemini identifies the Mudra from visual confirmation alone
      mimeType: "image/jpeg",
      data:     jpegBase64,
    },
    {
      // Skeletal context — wrist velocity, Aramandi depth, session state
      // Sent as base64-encoded JSON text alongside the image
      mimeType: "text/plain",
      data:     btoa(JSON.stringify({
        event_trigger:          "VELOCITY_DROP_MUDRA_LOCK",
        wrist_velocity_l:       meta.wristVelocityL,
        wrist_velocity_r:       meta.wristVelocityR,
        aramandi_stance_active: meta.aramandiActive,
        current_rasa:           meta.currentRasa,
        session_time_ms:        meta.sessionTimeMs,
      })),
    },
  ],
});

Gemini reads both parts as a single multimodal input. The image provides visual confirmation of the gesture. The JSON provides physical context — velocity, stance depth, emotional state — that helps Gemini calibrate its narration without requiring a separate API call.

Performance Numbers

Metric	Value	How
Pose lock → Gemini receives frame	~80ms	rVFC loop at 60fps, JPEG capture on lock
Gemini first tool call → client	~200ms	Persistent WSS, no connection overhead
Tool call → AR HUD update	~16ms	requestAnimationFrame, Svelte $state
Full end-to-end (pose → narration begins)	< 300ms	All three stages in sequence
Imagen 3 artwork generation	4–8s	Background fetch, shimmer placeholder shown

The 300ms end-to-end figure is what makes the product feel live rather than reactive. Human perception of audio-visual sync breaks down around 80ms — at 300ms, the narration arrives before the dancer has transitioned to the next gesture. The performance and the AI stay in the same moment.

What This Demonstrates About Gemini Live

The standard Gemini Live demo is voice conversation — a user speaks, the AI responds. Nritya demonstrates a fundamentally different interaction paradigm: structured physical gesture as a continuous prompt stream.

The dancer never speaks to the AI. The AI never waits to be asked. The system operates on velocity-triggered perception — a frame is sent precisely when the gesture completes, and Gemini responds with a fully orchestrated AR experience: geometry, translation, narration, and generated artwork arriving simultaneously.

This opens a category of applications that simply did not exist before the Gemini Live API's multimodal streaming capability:

Live sports commentary — gesture recognition triggering instant tactical analysis
Sign language interpretation — ASL detection with real-time spoken translation
Surgical guidance — instrument position triggering contextual procedural notes
Industrial inspection — technician hand position triggering relevant manual sections

In each case, the human body is the prompt. The AI is the always-watching collaborator. The interaction model requires no keyboard, no microphone, no deliberate input — only action.

Bharatanatyam is the proof of concept. The paradigm is universal.

Resources

Live Demo: nritya-ardance.web.app
Source Code: github.com/anil9973/nritya
Gemini Live API Docs: ai.google.dev/gemini-api/docs/live
Ephemeral Token Pattern: ai.google.dev/gemini-api/docs/ephemeral-tokens
Firebase AI Logic: firebase.google.com/docs/ai-logic

Built for the Gemini Live Agent Challenge · #GeminiLiveAgentChallenge
The dancer has always been speaking. Gemini is finally listening.

How Gemini Live API Makes Real-Time Psychological Support in Space Technically Possible

Anil Kumar — Mon, 16 Mar 2026 23:45:00 +0000

Disclosure: I created this content for the purposes of entering the
Gemini Live Agent Challenge hackathon
hosted by Google. All technical claims reflect the actual production implementation
of MAITRI, deployed on Google Cloud Run and Firebase Hosting.
View the repository →

FULL POST BODY

How Gemini Live API Makes Real-Time Psychological Support in Space Technically Possible

Disclosure: I created this content for the purposes of entering the Gemini Live Agent Challenge hosted by Google. All technical claims reflect the actual production implementation of MAITRI, deployed on Google Cloud Run and Firebase Hosting. View the repository →

The Constraint That Determined Everything

India is sending humans to space for the first time. Gaganyaan will orbit 400km above Earth, and every 90 minutes, for 45 minutes, the spacecraft passes beyond every relay satellite. Complete blackout. No ground control. No communication of any kind.

An astronaut experiencing psychological distress during a blackout window has no one to reach. This is not a solvable communication problem — it is a physical reality of orbital mechanics.

ISRO formally identified this gap in problem statement PS-ID-25175: real-time psychological support for isolated astronauts. I built MAITRI as a working implementation against that specification, entirely on Google Cloud.

The first architectural question was brutal: what does it mean for an AI to already be there?

A chatbot responds to requests. A REST completion API adds 3–4 seconds of round-trip latency per exchange. In a psychological support context, 3 seconds of silence after someone reaches out is not a delay — it is the pause that confirms they are alone.

Gemini Live's sub-300ms bidirectional audio-video stream is the only technology that eliminates that pause. Not reduces it. Eliminates it. Every subsequent technical decision in MAITRI's architecture follows from that single constraint.

What Gemini Live Makes Possible (That Nothing Else Does)

Before diving into the implementation, it's worth being explicit about why Gemini Live is not interchangeable with other APIs here.

Approach	Latency	Why It Fails
REST completion API	3,000ms+	Perceptible silence = perceived rejection
WebSocket chat stream	800ms+	Still detectable delay in conversation
Gemini Live bidirectional	<300ms	Below human perception threshold

The 300ms threshold matters clinically. NASA's psychological research on ISS astronauts shows that conversational responsiveness — the feeling of being heard — breaks down above 400ms of response latency. Gemini Live is not a faster API. It is a different category of interaction: one where the model is a continuous presence, not a request-response endpoint.

Designing MAITRI for presence rather than answers required entirely different architecture patterns.

The Architecture: Three Gemini Products, One Mission

MAITRI uses three products from the Gemini ecosystem, each doing precisely what it does best:

Gemini Live API    → Real-time voice conversation    (presence)
Gemini Flash       → Affect scoring from video       (analysis)
Google ADK         → Protocol orchestration          (intelligence)

Here is how they connect:

Android (Astronaut)
  │
  ├─ Audio (mic) ──► LiveKit WebRTC ──► Python Worker (Cloud Run)
  │                                          │
  └─ Video (camera) ──────────────────────►  │
                                             │
                                    ┌────────┴──────────┐
                                    │                   │
                               LiveRequestQueue    Affect Pipeline
                                    │            (every 5 seconds)
                                    ▼                   │
                              Google ADK                ▼
                                    │            Gemini Flash
                                    ▼            (Vertex AI)
                             Gemini Live API           │
                                    │                  ▼
                                    └──────► ProtocolStateMachine
                                                       │
                                              ┌────────┴────────┐
                                              │                 │
                                          Firestore        Pub/Sub
                                              │
                                          Svelte Dashboard
                                        (Firebase Hosting)

The critical architectural detail: the affect pipeline is completely isolated from the Live session. Gemini Flash scores the astronaut's emotional state from video frames every 5 seconds — the conversation never knows this is happening. MAITRI does not randomly comment on the camera feed. The scoring is invisible. The effect is not.

The Audio Bridge: Getting Voice Into Gemini Live

The first implementation challenge is a format mismatch. LiveKit WebRTC delivers audio at 48kHz. Gemini Live requires 16kHz mono PCM. The response comes back at 24kHz and needs to be published back to LiveKit at 48kHz.

This is the ingress pipeline:

async def forward_remote_audio_stream_to_adk_live_queue(
    audio_stream: rtc.AudioStream,
    live_request_queue: LiveRequestQueue,
    ingress_resampler: rtc.AudioResampler,
) -> None:
    forwarded_frame_count: int = 0

    async for event in audio_stream:
        incoming_frame: rtc.AudioFrame = event.frame

        # Resample 48kHz → 16kHz — Gemini Live requirement
        resampled_frames = ingress_resampler.push(incoming_frame)

        for resampled_frame in resampled_frames:
            audio_blob = genai_types.Blob(
                mime_type=f"audio/pcm;rate=16000",
                data=bytes(resampled_frame.data),
            )
            live_request_queue.send_realtime(audio_blob)
            forwarded_frame_count += 1

LiveRequestQueue is ADK's abstraction over the Gemini Live WebSocket — it handles reconnection, session management, and tool call dispatch transparently. Every 20ms audio frame from the astronaut's microphone arrives in Gemini Live with no buffering layer adding latency.

Zero audio processing on the spacecraft. Full intelligence on Google Cloud.

The Affect Pipeline: Gemini Flash as a Silent Observer

Every 5 seconds, a single video frame is extracted from the LiveKit video track, converted to JPEG, and sent to Gemini Flash on Vertex AI with a structured prompt:

async def _score_single_frame(self, frame: rtc.VideoFrame) -> AffectScore:
    async with self._scoring_lock:  # drop-if-busy — never queue frames
        jpeg_bytes = self._convert_rgba_to_jpeg(frame)
        b64 = base64.b64encode(jpeg_bytes).decode()

        response = await asyncio.to_thread(
            self._gemini_client.models.generate_content,
            model="gemini-2.0-flash",
            contents=[
                {
                    "parts": [
                        {"inline_data": {"mime_type": "image/jpeg", "data": b64}},
                        {"text": AFFECT_SCORING_PROMPT}
                    ]
                }
            ]
        )

        return AffectScore.model_validate_json(response.text)

The asyncio.Lock with drop-if-busy is intentional. If Gemini Flash takes longer than 5 seconds on a frame (network spike, API latency), the next frame is dropped rather than queued. A stale affect score from 10 seconds ago is worse than no score — it might trigger a false state transition.

The returned AffectScore carries arousal, valence, and confidence — three numbers that drive the entire protocol state machine.

The State Machine: ADK Protocol Intelligence

MAITRI's three-state protocol maps directly to clinical psychological triage logic:

class ProtocolStateMachine:
    _STATE_SEVERITY: dict[str, int] = {
        "BASELINE_MONITORING": 0,
        "ANOMALY_FLAGGED": 1,
        "ACTIVE_INTERVENTION": 2,
    }

    async def evaluate_score_and_transition_if_needed(
        self, score: AffectScore
    ) -> str | None:
        """Returns alert_id UUID if transition occurred, None otherwise."""

        async with self._transition_lock:
            arousal_dev = abs(score.arousal - self._baseline_arousal) / 100
            valence_dev = abs(score.valence - self._baseline_valence) / 100
            max_dev = max(arousal_dev, valence_dev)

            if max_dev >= INTERVENTION_THRESHOLD:
                target = "ACTIVE_INTERVENTION"
            elif max_dev >= ANOMALY_THRESHOLD:
                target = "ANOMALY_FLAGGED"
            else:
                return None  # No transition

            # Latch upward only — never auto-downgrade
            if self._severity(target) <= self._severity(self._current_state):
                return None

            alert_id = str(uuid.uuid4())
            self._current_state = target
            await self._write_to_firestore(score, alert_id)
            return alert_id

The latching rule is the most important safety constraint in the system. ACTIVE_INTERVENTION never auto-resets. A psychological crisis that resolves in 30 seconds still happened — auto-reset would mask the event from ground control. Only a credentialed ground controller issuing POST /api/reset-session clears the state.

The Killer Feature: Mid-Session Hint Injection

When the state machine transitions, MAITRI needs Gemini to change its behavior — immediately, without interrupting the conversation, without restarting the session.

ADK's LiveRequestQueue exposes exactly this capability:

async def inject_system_context_hint_into_live_session(
    live_request_queue: LiveRequestQueue,
    system_context_message: str,
) -> None:
    hint = f"[SYSTEM_CONTEXT: {system_context_message}]"
    text_blob = genai_types.Blob(
        mime_type="text/plain",
        data=hint.encode("utf-8"),
    )
    live_request_queue.send_realtime(text_blob)

And the hint builders, one per state transition:

def build_anomaly_flagged_context_hint(score: AffectScore) -> str:
    return (
        f"SYSTEM_CONTEXT: ANOMALY_FLAGGED — "
        f"arousal={score.arousal:.1f}, valence={score.valence:.1f}. "
        f"Shift to grounding mode. Use structured breathing or "
        f"cognitive reframing. Do not alarm. Do not diagnose."
    )

def build_active_intervention_context_hint(score: AffectScore) -> str:
    return (
        f"SYSTEM_CONTEXT: ACTIVE_INTERVENTION — "
        f"arousal={score.arousal:.1f}, valence={score.valence:.1f}. "
        f"Deliver one grounding sentence. Then fall silent. "
        f"Ground control has been alerted."
    )

No session restart. No silence. The conversation continues — Gemini simply becomes more focused. The astronaut never experiences a gap.

This pattern — continuous presence with in-flight context adjustment — is what separates Gemini Live from every other API in this space.

The Alert Architecture: One Event, Every Channel

When ACTIVE_INTERVENTION triggers, three things happen simultaneously from a single EventDispatcher:

async def handle_affect_score(self, affect_score: AffectScore) -> None:
    # 1. Always: publish affect overlay to Android
    await self._publish_affect_update(affect_score, timestamp_utc)

    # 2. Evaluate state machine
    alert_id = await self._state_machine.evaluate_score_and_transition_if_needed(score)
    if alert_id is None:
        return

    new_state = self._state_machine.current_state

    # 3. State change → DataChannel to Android (reliable=True)
    await self._publish_state_change(affect_score, new_state, alert_id, timestamp_utc)

    # 4. Inject hint into live Gemini session
    await self._inject_protocol_hint(new_state, affect_score)

    # 5. ACTIVE_INTERVENTION only: critical alert
    if new_state == "ACTIVE_INTERVENTION":
        await self._publish_critical_alert(affect_score, alert_id, timestamp_utc)
        dispatch_critical_alert_to_pubsub(payload)  # fire-and-forget

The same alert_id UUID flows through every channel — DataChannel to Android, Pub/Sub to ground systems, Firestore to the SSE stream. The Svelte dashboard deduplicates on alert_id. One event. Every channel. Zero duplication regardless of which arrives first.

Why Cloud Pub/Sub and not a direct HTTP call to the dashboard?

Cloud Pub/Sub decouples the critical alert from the audio pipeline. A direct HTTP call would block the asyncio event loop for 200ms+ — causing audible stuttering in Gemini's voice on the astronaut's device at the exact moment they need it most. Fire-and-forget via asyncio.create_task(asyncio.to_thread(...)) keeps the audio pipeline unblocked.

The Ground Dashboard: Firestore → SSE

The ground control dashboard at maitri-astronaut.web.app receives events via a Server-Sent Events stream that merges two sources:

@router.get("/api/session-status")
async def session_status_sse(request: Request) -> StreamingResponse:
    snapshot_queue: asyncio.Queue = asyncio.Queue()
    loop = asyncio.get_running_loop()

    # Firestore onSnapshot — requires sync client
    sync_db = get_firestore_sync_client()
    doc_ref = sync_db.collection("sessions").document("GAGANYAAN_01")

    def _on_snapshot(snapshots, changes, read_time):
        # Runs in Firestore SDK thread — thread-safe handoff to asyncio
        for snapshot in snapshots:
            event = _build_state_change_sse_dict(snapshot, str(uuid.uuid4()))
            loop.call_soon_threadsafe(snapshot_queue.put_nowait, event)

    unsubscribe = doc_ref.on_snapshot(_on_snapshot)

    # Merge Firestore snapshots + affect telemetry queue
    async def generator():
        try:
            async for chunk in _sse_event_generator(request, snapshot_queue):
                yield chunk
        finally:
            unsubscribe()  # Clean teardown on client disconnect

onSnapshot propagates every Firestore write to the dashboard in under 100ms. The dashboard never polls. State changes appear the moment they happen — protocol transitions, affect score updates, intervention triggers — all driven by Firestore's real-time listener without a separate WebSocket server.

Eight Google Cloud Services, Each Earning Its Place

Service	Why This, Not an Alternative
Gemini Live API	Sub-300ms presence — no other API achieves this
Vertex AI — Gemini Flash	Structured affect scoring in one prompt — no custom ML model required
Google ADK	`LiveRequestQueue` hint injection — no equivalent in third-party frameworks
Cloud Run	Single-process: FastAPI + worker share memory, no IPC
Firestore	`onSnapshot` drives dashboard without polling — latency under 100ms
Cloud Pub/Sub	Decouples critical alert from audio pipeline — no event loop blocking
Cloud Storage	Single JSON blob per session — directly ingestible by BigQuery
Cloud Monitoring	Custom `affect_arousal` + `affect_valence` gauges every 5 seconds

8 Google Cloud services. Each genuinely wired. None aspirational.

Automated Deployment: Cloud Build + GitHub Actions

Every commit to main ships to production:

# backend/cloudbuild.yaml — three steps
steps:
  - name: gcr.io/cloud-builders/docker
    args: [build, --tag=gcr.io/$PROJECT_ID/maitri:$SHORT_SHA, .]

  - name: gcr.io/cloud-builders/docker
    args: [push, gcr.io/$PROJECT_ID/maitri]

  - name: gcr.io/google.com/cloudsdktool/cloud-sdk
    args:
      - run deploy maitri
      - --image=gcr.io/$PROJECT_ID/maitri:$SHORT_SHA
      - --region=us-east4
      - --min-instances=1   # Always warm
      - --memory=2Gi        # Audio + video parallel pipelines
      - --concurrency=1     # One WebRTC session per instance
      - --timeout=3600      # Full session support

The Svelte dashboard deploys to Firebase Hosting via GitHub Actions on every merge. Backend and dashboard ship independently — a frontend change never risks a backend restart.

git push → Cloud Build → Docker build → Artifact Registry → Cloud Run
git push → GitHub Actions → npm run build → Firebase Hosting

Automated deployment on every commit via Cloud Build and GitHub Actions.

Responsible AI by Design

MAITRI is a first-responder signal layer. It is not a therapeutic agent.

The ACTIVE_INTERVENTION state has exactly one permitted output: a single grounding sentence, then silence, then a ground alert. No clinical advice. No diagnosis. No attempt to resolve the situation autonomously.

def build_active_intervention_context_hint(score: AffectScore) -> str:
    return (
        "SYSTEM_CONTEXT: ACTIVE_INTERVENTION. "
        "Deliver one grounding sentence. Then fall silent. "
        "Ground control has been alerted. Do not continue the conversation."
    )

The constraint is not in the system prompt as a suggestion. It is enforced by the protocol state — when ACTIVE_INTERVENTION triggers, hint injection fires before the next Gemini response is generated. The model receives the constraint as its next context frame.

Responsible AI by design: MAITRI augments ground psychologists, never replaces them.

What Gemini Live Unlocks for the Next Generation of AI Applications

The patterns in MAITRI are not space-specific. The fundamental capability — a sub-300ms bidirectional stream that maintains continuous presence, accepts mid-session context injection, and processes voice and vision simultaneously — applies to any domain where AI needs to be with someone rather than responding to them.

Healthcare monitoring. Crisis intervention. High-isolation research deployments. Anywhere humans go where the latency of a REST API is the difference between presence and absence.

Gemini Live is not a faster way to build chatbots. It is the foundation for a different category of AI application — one where the model is continuously aware and the interaction is ambient rather than transactional.

MAITRI is one implementation of what that looks like. The architecture is open, the repository is public, and the deployment runs on Google Cloud infrastructure available to every developer reading this.

India's first astronauts deserve the best AI that exists today. MAITRI is built on the technology that makes it possible.

Live demo: maitri-astronaut.web.app
Repository: github.com/anil9973/maitri
Architecture: ARCHITECTURE.md

#GeminiLiveAgentChallenge #GoogleCloud #GeminiLive #MAITRI #Python #Android

I Built Yahoo Pipes 2.0 in 7 Days Using Kiro's Spec-Driven AI Development

Anil Kumar — Fri, 05 Dec 2025 19:37:02 +0000

I Built Yahoo Pipes 2.0 in 7 Days Using Kiro's Spec-Driven AI Development

TL;DR: Recreated Yahoo Pipes as a modern Chrome extension with AI-powered recommendations, industrial-grade SVG editor, and real-time webhooks. Built 100% with Kiro using specs and steering docs. 7 days vs 2 months traditional development.

The Yahoo Pipes Problem

If you're a certain age in tech, you remember Yahoo Pipes fondly. It was magical:

Visual programming for data workflows
No coding required
Fetch RSS feeds, filter, merge, transform
Output to anything

Yahoo shut it down in 2015. The dev community mourned. Alternatives existed (Zapier, IFTTT, n8n) but none captured that perfect balance of power and simplicity.

I decided to rebuild it. With 2025 superpowers.

What I Built: GhostPipes

Core Features

🎯 ML-Powered Recommendations

The "Netflix for pipelines." Paste a URL, upload CSV, drop text—Ghost Pipes analyzes:

Input type (file/url/text)
MIME type and structure
Your usage history
Pipeline success rates

Then scores every pipeline 0-100 and suggests the top 5. It learns from every execution.

🎨 Industrial-Grade Visual Editor

Not your typical node editor with simple lines. I wanted realistic pipes:

Bad:  Node1 -----> Node2
Good: Node1 ═══╗
              ║
          Node2

Features:

10px thick SVG pipes
90° bends with smooth cubic bezier corners
Collision avoidance (pipes route around nodes)
Decorative joint patches at elbows
60fps drag-and-drop with requestAnimationFrame

⚡ 35+ Node Types

Input, processing, and output nodes covering:

HTTP requests (scheduled or one-time)
Webhooks (generate unique URLs)
File operations (CSV, JSON, HTML parsing)
AI processing (summarize, translate, extract)
Logic (loops, conditionals, switches)
Destinations (download, API POST, email)

🔗 Real-Time Webhooks

Generate a unique URL for each pipeline. When external services trigger it:

Backend validates token
Checks payload size
If <4KB: sends data via Web Push
If ≥4KB: sends "fetch data" instruction
Extension shows notification

☁️ Offline-First + Cloud Sync

IndexedDB for local storage
15-second debounced sync to AWS
Conflict resolution (server timestamp wins)
Works completely offline

The Kiro Difference

Traditional AI Coding (Vibe Coding)

You: "Build me a visual pipeline editor"
AI: [generates 500 lines of React]
You: "No, use my custom framework Om.js"
AI: [generates broken code that doesn't work]
You: "Fix the reactivity"
AI: [different broken code]
[repeat 10x until you just rewrite it manually]

Time: 2-3 weeks of iteration
Quality: Mixed, requires heavy refactoring
Maintainability: Poor, no documentation

Kiro's Spec-Driven Approach

Step 1: Write Comprehensive Specs

/specs/
├── backend-architecture.md (3,500 words)
├── database-design.md
├── api-contracts.md (every endpoint)
├── pipeline-recommendation.md (ML algorithm)
└── pipeline-builder-visual-editor.md

I spent 2 days writing these. Detailed requirements, edge cases, data models, algorithms.

Step 2: Add Steering Docs

/steering/
├── coding-guidelines.md (my style rules)
├── om-js-framework.md (custom reactive system)
└── svg-best-practices.md

This teaches Kiro my preferences:

Use Om.js, not React
Ternaries over if-else
Object lookups over switch statements
Classes for separation of concerns
Modern CSS nesting

Step 3: Let Kiro Build

> kiro build backend
[Kiro reads specs + steering]
[Generates 15 files, 3,500 lines]
[Tests pass on first run]

Time: 5 days of implementation
Quality: Production-ready immediately
Maintainability: Fully documented, follows my style

Real Examples of Kiro's Magic

Example 1: The SVG Pipe Challenge

My Fear: "I don't know SVG. Creating realistic pipes will take weeks of research."

What I Did:

Wrote text description: "Industrial pipes, 10px thick, 90° bends, smooth corners"
Uploaded reference image of factory pipes
Kiro analyzed image + specs
Generated complete PathCalculator class:

export class PathCalculator {
  calculateOrthogonalPath(start, end, obstacles) {
    // 120 lines of collision detection
    // Waypoint generation
    // Bezier curve insertion
  }

  generateSVGPath(waypoints) {
    // Converts to SVG with smooth corners
  }
}

Result: Worked perfectly. Looks professional. 200+ lines I never had to write.

Example 2: 35+ Om.js Web Components

The Problem: AI trained on React produces garbage for custom frameworks.

My Solution:

Documented Om.js in /steering/om-js-framework.md:
- Reactive proxy system
- html template literals
- Event binding with @click
- No shadow DOM
Asked Kiro to generate FilterNode component

Kiro's Output:

import { react, html } from '/lib/om.compact.js';

export class FilterNode extends HTMLElement {
  state = react({
    mode: 'permit',
    rules: []
  });

  render() {
    return html`
      <div class="filter-node">
        <select .value=${() => this.state.mode}>
          <option value="permit">Permit</option>
          <option value="block">Block</option>
        </select>
        ${this.state.rules.map(rule => this.renderRule(rule))}
      </div>
    `;
  }
}

Perfect Om.js syntax. First try.

I then asked for 34 more nodes. All perfect. No rewrites.

Example 3: AWS Integration via MCP

Background: I'm a frontend dev. Last touched AWS 3 years ago. Forgot everything.

The Issue:

Set up Aurora PostgreSQL
Migrations wouldn't run
Database doesn't exist?
Spent 4 hours Googling

Kiro + AWS MCP:

Me: "Here's my terraform config. Migrations fail. Database 'ghostpipes' doesn't exist."

Kiro: "RDS instance created, but database not initialized. Run:
CREATE DATABASE ghostpipes;

Also, your connection string missing db name. Add: ?database=ghostpipes"

Fixed in 5 minutes.

The Agent Hooks Secret Weapon

Kiro's hooks continuously monitor code quality:

.kiro/hooks/pre-commit.js

// Check for leaked API keys
if (detectAPIKeys(changedFiles)) {
  fail("API key detected in commit!");
}

// Check manifest.json permissions
if (hasNewPermissions(manifest)) {
  warn("New permission added: " + newPerms);
}

.kiro/hooks/on-build.js

// Remove console.logs in production
stripDebugCode(distFiles);

// Check bundle size
if (extensionSize > 5MB) {
  fail("Extension too large: " + size);
}

These caught 12 issues during development:

2x hardcoded test API keys
1x accidental <all_urls> permission
8x leftover console.logs
1x bundle size spike (included wrong library)

The Numbers

Metric	Traditional	With Kiro
Dev Time	6-8 weeks	7 days
Lines of Code	~8,000	~8,000
Rewrites	3-4 major	0
Documentation	Written after	Written before
Test Coverage	~60%	~85%
Bugs in Production	15-20	3

What I Learned

1. Specs Are Worth It

Spending 2 days on specs felt slow. But the code Kiro generated was so clean, I saved 2 weeks of refactoring.

Bad Approach: Code first, document later (if ever)
Good Approach: Spec first, code second

2. Steering Docs = 10x Multiplier

For custom frameworks/styles, steering docs are non-negotiable. 2 hours documenting Om.js saved me 40 hours of manual coding.

3. MCP Transforms Domain-Specific Work

AWS MCP, Svelte MCP—these aren't just "ChatGPT with docs." They have current, accurate knowledge that generic AI lacks.

4. Agent Hooks Prevent Embarrassment

The API key hook alone justified Kiro. Chrome Web Store would've rejected my extension otherwise.

Try It Yourself

GhostPipes: [Chrome Web Store Link]
Source Code: [GitHub]
Kiro: [kiro.dev]

I Built a Kiro Extension to visualize boring specs Days using kiro IDE

Anil Kumar — Fri, 05 Dec 2025 19:36:41 +0000

The Spark of an Idea

Picture this: It's a regular Tuesday. I'm using Kiro IDE to manage my project specs. I open tasks.md for the hundredth time, and I think...

"These markdown files are so boring. What if they were... SPOOKY?" 🎃

That single thought, combined with Kiro AI's power, led to SpecterFlow—a Kiro extension that transforms boring spec files into an interactive, spooky-themed visual experience with electric Tesla coils, animated cursors, and neon-glowing interfaces.

The kicker? 80% of the code was written by AI in just 3 days!

What is SpecterFlow?

SpecterFlow is a Kiro extension that brings .kiro/specs/ markdown files to life with three themed views:

🪦 The Graveyard (tasks.md)

Your kanban board becomes a graveyard with:

Tombstone-shaped cards with stone textures
Electric Tesla coil sparks on every card
Ghost celebrations when you complete tasks
Ectoplasm trails when dragging cards
Columns: "Fresh Graves" → "Resurrecting" → "R.I.P."

📜 The Grimoire (requirements.md)

Your requirements become an ancient spellbook with:

Parchment textures and mystical runes
Wavy text animations (6 different styles!)
Split-view: User stories ↔ Acceptance criteria
Glowing number badges with pulsing effects
Crimson Text font for that ancient book feel

🔮 The Spirit Board (design.md)

Your design docs become an Ouija board with:

Mystical navigation sidebar
Glowing crystal emojis
Electric branches in tree views
Smooth scrolling with neon buttons

The AI-Powered Development Journey

Day 1: Spec-Driven Development

I started with Kiro's spec-driven development workflow. I told Kiro:

"I want to build a Kiro extension that visualizes .kiro/specs files with a spooky theme."

Kiro responded by creating:

requirements.md - Complete with EARS patterns and acceptance criteria
design.md - Architecture, components, and correctness properties
tasks.md - 30 detailed implementation tasks

Then Kiro started coding. In Day 1, it generated:

Extension activation logic
Custom editor providers
File system scanner
Markdown parsers (event-driven architecture!)
Basic webview structure

Lines of code written by Kiro on Day 1: ~800

Day 2: Vibe Coding Magic

This is where it got WILD. I switched to "vibe coding" mode and just... described what I wanted:

Me: "Make it spooky with electric Tesla coil effects!"

Kiro: Generates 500 lines of CSS with:

Tesla coil spark animations
Lightning bolt SVG animations
Plasma orb effects
Electric particles
Voltage arcs

Me: "Add wavy text animations!"

Kiro: Creates complete animation system with:

Wave animation (letters bounce independently)
Glitch wave (skew + hue rotation)
Floating wave (3D motion)
Neon wave (color alternation)
Rainbow wave (full spectrum)
Liquid wave (morphing borders)

Me: "Custom cursor with particle trails!"

Kiro: Builds optimized JavaScript with:

Custom cursor with glowing ring
Particle trail system
Click explosions (8 particles)
Electric sparks
GPU acceleration
Throttled for 60fps performance

Lines of code written by Kiro on Day 2: ~2,500

Day 3: Polish & Performance

On the final day, I focused on optimization and polish:

Me: "The cursor is lagging. Optimize it!"

Kiro: Refactors with:

Throttled trail creation (50ms intervals)
Reduced particle counts
will-change for GPU acceleration
transform instead of left/top
Passive event listeners
Event delegation

Me: "The fonts don't look good. Choose better ones!"

Kiro: Analyzes options and creates:

Intelligent font hierarchy
October Twilight for headers
Jura for "Ghost in Machine" UI
Crimson Text for grimoire
Share Tech Mono for code
Complete font system with performance optimization

Lines of code written by Kiro on Day 3: ~900

The Numbers

Let's break down what Kiro generated:

3,500+ lines of CSS (animations, effects, layouts)
1,200+ lines of JavaScript (parsers, components, interactions)
17+ particle effect types (sparks, trails, explosions)
6 bright neon colors (carefully selected palette)
5 font families (intelligently chosen)
8 agent hooks (automation workflows)
9 MCP servers (extended capabilities)
Complete documentation (guides, READMEs, comments)

Total: ~5,000 lines of production-ready code in 3 days!

The Secret Sauce: How Kiro Did It

1. Spec-Driven Development

Kiro excels at structured development. By creating comprehensive specs first, it had a clear roadmap:

## Requirement 1: Graveyard Kanban Board

**User Story:** As a developer, I want to see my tasks as tombstones...

### Acceptance Criteria

1. WHEN a user opens tasks.md THEN the system SHALL display a kanban board
2. WHEN a task is dragged THEN the system SHALL show an ectoplasm trail
3. WHEN a task is completed THEN the system SHALL trigger ghost celebration

This clarity meant Kiro could generate code that exactly matched requirements.

2. Vibe Coding

For creative features, I used vibe coding:

Me: "Make it feel like a haunted computer terminal from the 80s"
Kiro: *generates Share Tech Mono font, CRT effects, scanlines*

Me: "Add electric sparks like a Tesla coil"
Kiro: *creates complete particle system with physics*

Kiro understood the vibe and translated it into code!

3. Agent Hooks

I set up hooks to automate workflows:

{
    "name": "Compile on Save",
    "trigger": { "type": "onFileSave", "filePattern": "**/*.ts" },
    "action": { "type": "executeCommand", "command": "npm run compile" }
}

Every time I saved a TypeScript file, Kiro auto-compiled it. No manual steps!

4. Steering Docs

I created steering documents to guide Kiro's style:

# JavaScript Patterns

- Use classes instead of @typedef
- Prefer ternary over if-else for assignments
- Use Object lookups instead of switch statements
- Keep functions concise (single responsibility)

This ensured consistent, high-quality code throughout.

5. MCP Servers

I enabled MCP servers for extended capabilities:

vscode-extension - Kiro could search Kiro extension APIs
npm - Kiro could find and suggest packages
fetch - Kiro could get documentation from the web
typescript - Kiro could check types in real-time

This gave Kiro superpowers beyond its base knowledge!

The Most Impressive Code Generation

The electric Tesla coil effects were mind-blowing. I said:

"Add electric sparks like a Tesla coil"

Kiro generated:

@keyframes teslaCoil {
    0%,
    100% {
        opacity: 0;
        transform: scale(0.8) translateY(0);
    }
    10% {
        opacity: 1;
        transform: scale(1) translateY(-5px);
    }
    20% {
        opacity: 0;
        transform: scale(0.9) translateY(-10px);
    }
    /* ... continues with perfect timing ... */
}

.electric-spark {
    position: absolute;
    width: 2px;
    height: 20px;
    background: linear-gradient(180deg, #00ffff 0%, #0080ff 50%, transparent 100%);
    box-shadow: 0 0 10px #00ffff, 0 0 20px #00ffff, 0 0 30px #0080ff;
    animation: teslaCoil 1.5s ease-in-out infinite;
}

Plus JavaScript to spawn sparks, manage lifecycle, and optimize performance. All from one sentence!

Performance: The Surprise Win

Here's what shocked me: Kiro didn't just generate code—it generated OPTIMIZED code!

When I mentioned cursor lag, Kiro:

Identified the bottleneck (too many particles)
Implemented throttling (50ms intervals)
Added GPU acceleration (will-change, transform)
Used passive listeners
Implemented event delegation

Result: Smooth 60fps with 17+ particle effects running simultaneously!

Lessons Learned

1. AI Excels at Structured Tasks

Spec-driven development gave Kiro clear requirements. It generated code that exactly matched specs with minimal iteration.

2. Vibe Coding Unlocks Creativity

For creative features, describing the "vibe" worked better than technical specs. Kiro understood "haunted terminal" and "Tesla coil sparks" intuitively.

3. Automation Multiplies Productivity

Agent hooks eliminated repetitive tasks. Auto-compiling, auto-testing, and smart reminders saved hours.

4. Steering Ensures Quality

Custom steering docs meant Kiro generated code in my preferred style consistently.

5. MCP Extends Capabilities

MCP servers gave Kiro access to Kiro APIs, npm packages, and web docs—making it 10x more capable.

The Future of Development

SpecterFlow proves that AI-assisted development isn't just fast—it's transformative.

In 3 days, with 80% AI-generated code, I built:

A production-ready Kiro extension
17+ particle effect systems
Intelligent font hierarchy
Performance-optimized animations
Complete documentation
Automated workflows

This would have taken weeks without AI!

Try It Yourself!

Want to experience SpecterFlow?

Install from Kiro marketplace
Open a workspace with .kiro/specs/ folder
Open any tasks.md, requirements.md, or design.md
Watch your specs come alive! ⚡👻

Want to build with Kiro?

Try Kiro IDE
Use spec-driven development for structure
Use vibe coding for creativity
Set up agent hooks for automation
Enable MCP servers for superpowers

Conclusion

SpecterFlow started as a silly idea: "What if specs were spooky?"

With Kiro AI, that idea became reality in 3 days. The extension has:

Electric Tesla coils ⚡
Animated cursors 👻
Neon glows 🌟
Wavy text 🌊
60fps performance 🚀

And it's 80% AI-generated!

This is the future of software development: humans provide vision, AI provides execution, and together we create magic.

What will YOU build with AI? 🎃⚡👻

Links:

Tags: #AI #Kiro #WebDev #KiroWeen #AIAssistedDevelopment #JavaScript #TypeScript #CSS

Built with 💜 by a human + Kiro AI in 3 days
80% AI-generated, 100% spooky, 1000% awesome!

How I Built AgriPath: An AI-Powered Farming Platform That Increases Profits by 90% Using Google Cloud Run and ADK

Anil Kumar — Tue, 11 Nov 2025 01:00:00 +0000

This blog post was created for the Google Cloud Run Hackathon 2025. I'm excited to share how AgriPath leverages Cloud Run's serverless architecture and Google's Agent Development Kit to solve real farming challenges.

The Story That Started Everything

Last year, I watched my uncle plant 7 acres of radish on December 5th. It wasn't just him—every farmer in our village did the same. We all knew what would happen next, but we did it anyway.

Fast forward to February: the market flooded. Prices crashed from ₹18/kg to ₹9/kg. My uncle earned ₹630,000 when he could have made ₹1,200,000—same land, same seeds, same effort—just terrible timing.

That night, I asked him: "Why didn't you plant half the field a month later?"

His response changed everything: "Nobody tells us WHEN, HOW MUCH, or WHAT EXACTLY to do. We just follow what everyone else does."

That's when I realized: farmers don't need more information—they need complete execution plans.

The Real Problem (It's Not What You Think)

There are hundreds of crop recommendation apps in India. Farmers have smartphones. They know tomatoes are profitable and radish grows in 60 days.

The problem isn't information. It's execution:

❌ "Plant radish" → ✅ "Plant 2 acres on Dec 5, 5 acres on Jan 5"

❌ "Use fertilizer" → ✅ "Apply 50kg Urea on day 21 with irrigation"

❌ "Watch for pests" → ✅ "Check for aphids on day 30, use Imidacloprid if needed"

Farmers need a complete, day-by-day roadmap from land preparation to harvest, with exact materials, costs, and step-by-step instructions.

That's what AgriPath delivers.

The Solution: 11 AI Agents Working Together

I built AgriPath using Google's Agent Development Kit (ADK) with 11 specialized AI agents, all powered by Gemini 2.0 Flash. Each agent is an expert in one domain, and they work together to create complete farming execution plans in 90 seconds.

The Architecture

ROOT ORCHESTRATOR (Gemini 2.0)
    ├── DATA INTELLIGENCE LAYER (4 agents)
    │   ├── BigQuery Analyst: Queries 10,000+ cultivation records
    │   ├── Weather Integration: 16-day forecasts from Weatherbit
    │   ├── Location Intelligence: Google Maps for water sources
    │   └── Market Intelligence: Price volatility analysis
    │
    ├── PLANNING & OPTIMIZATION LAYER (3 agents)
    │   ├── Multi-Land Portfolio: Crop allocation across plots
    │   ├── Staggered Planting Optimizer: THE GAME CHANGER
    │   └── Pest Disease Intelligence: IPM strategies
    │
    ├── EXECUTION & DELIVERY LAYER (3 agents)
    │   ├── Calendar Generator: 150-200 activities
    │   ├── Financial Projections: Complete ROI analysis
    │   └── Subsidy Assistant: Government scheme matching
    │
    └── MONITORING & RISK LAYER (2 agents)
        ├── Risk Assessor: Weather/pest/market risks
        └── Alert Scheduler: 47 notification events

Why Cloud Run Was Perfect for This

The Challenge:

11 AI agents processing sequentially
External API calls (BigQuery, Weatherbit, Google Maps)
Response times of 60-120 seconds
Unpredictable traffic (farmers plan seasonally)

Why Cloud Run Solved It:

Generous Timeouts: 300-second timeout vs 60s on most platforms
Flexible Resources: Scale to 4GB RAM when needed
Pay-per-use: $0 cost when idle (most of the time)
Auto-scaling: Handle 1 request or 1000 effortlessly
Zero DevOps: Deploy with one command, Google handles everything

My Cloud Run Configuration:

Memory: 4GB          # For 11 Gemini instances + BigQuery
CPU: 2 vCPUs         # Parallel API calls
Timeout: 300s        # Complete processing in 60-120s
Max Instances: 10    # Auto-scale during peak
Min Instances: 0     # Zero cost when idle

Cost Optimization:

Development: ~$10/month (testing only)
Production (1000 plans/day): ~$150/month
Per plan: $0.15 (vs $5-10 on traditional VMs)

The Killer Feature: Staggered Planting Optimization

This is the innovation that makes AgriPath special. Let me show you the algorithm that increases farm profits by 40-90%.

The Algorithm

Step 1: Analyze Market Volatility

def calculate_volatility_index(price_history):
    """
    Higher volatility = bigger price swings = opportunity for staggering
    """
    prices = [month['avg_price'] for month in price_history]
    std_dev = statistics.stdev(prices)
    mean_price = statistics.mean(prices)
    volatility_index = (std_dev / mean_price) * 100
    return volatility_index

# Radish example: volatility = 68.5 (high!)

Step 2: Identify Crash Months

crash_month = min(price_history, key=lambda x: x['avg_price'])
# Feb: ₹9/kg (everyone harvests together)

pre_crash_price = price_history[crash_month.index - 1]['avg_price']
# Jan: ₹15/kg (early market)

post_crash_price = price_history[crash_month.index + 1]['avg_price']
# Mar: ₹18/kg (post-peak recovery)

Step 3: Calculate Optimal Batches

crop_duration = 60  # days for radish

# Batch 1: Early harvest (before crash)
batch_1_area = total_area * 0.30  # 30% = 2 acres
batch_1_sowing = crash_date - timedelta(days=crop_duration + 10)
# Dec 5 → harvest Feb 5 at ₹15/kg

# Batch 2: Post-peak harvest
batch_2_area = total_area * 0.70  # 70% = 5 acres
batch_2_sowing = batch_1_sowing + timedelta(days=30)
# Jan 5 → harvest Mar 5 at ₹18/kg

Step 4: Financial Comparison

# Single batch (traditional approach)
single_revenue = (
    total_area * yield_per_acre * crash_price
)
# 7 acres × 10,000 kg × ₹9 = ₹630,000

# Staggered approach
staggered_revenue = (
    (batch_1_area * yield_per_acre * pre_crash_price) +
    (batch_2_area * yield_per_acre * post_crash_price)
)
# (2 × 10,000 × ₹15) + (5 × 10,000 × ₹18) = ₹1,200,000

profit_increase = (
    (staggered_revenue - single_revenue) / single_revenue * 100
)
# 90% INCREASE!

Real Output Example

When a farmer inputs 7 acres for radish, the staggered_planting_optimizer_agent returns:

{
  "staggered": true,
  "batches": [
    {
      "batch": 1,
      "area_acres": 2.0,
      "sowing_date": "2024-12-05",
      "harvest_date": "2025-02-05",
      "expected_price_per_kg": 15,
      "expected_revenue": 300000,
      "market_timing": "early_market"
    },
    {
      "batch": 2,
      "area_acres": 5.0,
      "sowing_date": "2025-01-05",
      "harvest_date": "2025-03-05",
      "expected_price_per_kg": 18,
      "expected_revenue": 900000,
      "market_timing": "post_peak"
    }
  ],
  "total_revenue": 1200000,
  "single_batch_revenue": 630000,
  "profit_advantage_percent": 90.5,
  "reasoning": "Radish prices crash 40% in mid-Feb due to market glut. Staggering captures early market (₹15/kg) and post-peak recovery (₹18/kg), avoiding ₹9/kg crash."
}

Building with Google ADK: The Good, The Bad, The Lessons

Why I Chose Google ADK

I evaluated several multi-agent frameworks:

LangChain: Too complex, verbose, slow
CrewAI: Great DX but limited to OpenAI/Anthropic
AutoGen: Research-focused, production-immature

Google ADK won because:

Native Gemini integration (fast, cheap)
Clean agent abstraction (input_schema, output_schema)
Built-in Cloud Run deployment support
Proper sub-agent orchestration
Production-ready (from Google!)

The Implementation

Creating an Agent (The Right Way):

from google.adk import Agent
from pydantic import BaseModel

# Input/output schemas (MUST be Pydantic)
class StaggeredPlanningInput(BaseModel):
    crop: str
    area_acres: float
    market_analysis: MarketAnalysisOutput

class StaggeredPlanningOutput(BaseModel):
    staggered: bool
    batches: List[BatchInfo]
    profit_advantage_percent: float

# Agent definition
staggered_planner = Agent(
    model="gemini-2.0-flash-exp",
    name="staggered_planting_optimizer",
    description="Optimizes crop planting timing for market advantage",
    instruction=STAGGERED_PLANTING_PROMPT,  # Detailed prompt
    input_schema=StaggeredPlanningInput,
    output_schema=StaggeredPlanningOutput,
)

Root Agent Orchestration:

root_agent = Agent(
    model="gemini-2.0-flash-exp",
    name="AgriPath_root_orchestrator",
    description="Multi-agent system coordinating 11 specialized agents",
    instruction=ROOT_ORCHESTRATOR_PROMPT,
    sub_agents=[
        bigquery_analyst,
        weather_integration,
        location_intelligence,
        market_intelligence,
        multi_land_portfolio,
        pest_disease_intelligence,
        staggered_planting_optimizer,  # Our killer feature!
        calendar_generator,
        financial_projections,
        subsidy_assistant,
        risk_assessor,
        alert_scheduler,
    ],
    input_schema=AgriPathInput,
    output_schema=AgriPathOutput,
)

The Challenges I Faced

Challenge 1: Response Times (Initial: 240s)

With 11 agents processing sequentially, initial response times were 3-4 minutes—unacceptable for production.

Solutions:

Reduced tool calls by caching crop schedules
Streamlined agent prompts (focused on essentials)
Used Gemini Flash instead of Pro (5x faster)
Optimized BigQuery queries with indexes

Result: 60-120s response time ✅

Challenge 2: Structured Output Reliability

Agents sometimes returned text instead of JSON, breaking the pipeline.

Solutions:

Strict Pydantic validation on all schemas
Clear <OutputFormat> tags in prompts
Added retry logic with exponential backoff
Validation before passing to next agent

Result: 99.2% structured output success ✅

Challenge 3: Cost Management

11 Gemini instances × 1000 requests/day = expensive!

Solutions:

Used Gemini Flash (10x cheaper than Pro)
Implemented response caching for crop schedules
Batch processing for BigQuery queries
Cloud Run min instances = 0 (zero idle cost)

Result: $0.15 per plan (vs $2.50 initially) ✅

The Complete Calendar Generation

This is where AgriPath shines. Let me show you how we generate 150-200 activities with exact materials, costs, and instructions.

The Calendar Generator Agent

CALENDAR_GENERATOR_PROMPT = """
You are the `calendar_roadmap_generator_agent`.

<Steps>
1. For each crop, get duration and stages
2. Generate land preparation (7 days before sowing)
3. Generate sowing with material calculations
4. Generate irrigation every 15-20 days (check weather!)
5. Generate fertilizer on specific days (21, 45)
6. Generate pesticide if needed (day 30, 60)
7. Generate harvesting (sowing_date + duration_days)
8. Sort all activities by date
9. Validate budget and workers
</Steps>

<MaterialCalculations>
Wheat (per acre):
- Seeds: 40 kg @ ₹62.5/kg = ₹2,500
- DAP: 60 kg @ ₹40/kg = ₹2,400
- Urea: 50 kg @ ₹15/kg = ₹750
- MOP: 30 kg @ ₹26/kg = ₹780

Radish (per acre):
- Seeds: 4 kg @ ₹200/kg = ₹800
- DAP: 20 kg @ ₹40/kg = ₹800
- Urea: 15 kg @ ₹15/kg = ₹225
</MaterialCalculations>
"""

Sample Generated Activity

Input: "Wheat, 5 acres, sowing date Dec 10"

Output:

{
  "activity_id": "ACT_WHEAT_001",
  "date": "2024-12-10",
  "crop": "wheat",
  "plot_id": "PLOT_A",
  "activity_type": "sowing",
  "title": "Sow Wheat - 5 acres",
  "materials_needed": [
    {
      "name": "Wheat seeds (HD-2967)",
      "quantity": 200,
      "unit": "kg",
      "cost_per_unit": 62.5,
      "total_cost": 12500,
      "supplier": "PAU Seed Store"
    },
    {
      "name": "DAP (Diammonium Phosphate)",
      "quantity": 300,
      "unit": "kg",
      "cost_per_unit": 40,
      "total_cost": 12000
    },
    {
      "name": "Urea",
      "quantity": 250,
      "unit": "kg",
      "cost_per_unit": 15,
      "total_cost": 3750
    },
    {
      "name": "MOP (Muriate of Potash)",
      "quantity": 150,
      "unit": "kg",
      "cost_per_unit": 26,
      "total_cost": 3900
    }
  ],
  "workers_needed": 6,
  "equipment_needed": ["tractor", "seed_drill"],
  "estimated_duration_hours": 8,
  "estimated_cost": 32250,
  "weather_dependency": "avoid_if_rain_forecast",
  "instructions": [
    "1. Seed treatment: Mix seeds with Carbendazim @ 2g/kg and dry in shade for 2 hours",
    "2. Field preparation: Ensure soil is properly leveled with moisture",
    "3. Basal fertilizer application: Broadcast DAP and MOP uniformly, incorporate with light harrowing",
    "4. Sowing method: Use seed drill for uniform spacing (22.5 cm row spacing)",
    "5. Seed rate: 40 kg/acre (total 200kg for 5 acres)",
    "6. Sowing depth: 5-6 cm (critical for germination)",
    "7. Post-sowing: Light irrigation (2-inch water) within 24 hours",
    "8. Monitor germination: Should appear in 5-7 days"
  ],
  "strategic_reason": "Wheat after soybean is excellent rotation (legume adds nitrogen). December sowing captures optimal temperature for tillering.",
  "priority": "critical",
  "related_activities": ["ACT_WHEAT_002_irrigation_day15"],
  "contingency_plan": "If rain >20mm forecasted, postpone by 2 days to avoid waterlogging"
}

Real API Integrations (No Mocks!)

BigQuery Integration

We use BigQuery to store 10,000+ historical cultivation records and query them with ML-based similarity scoring.

from google.cloud import bigquery

def query_crop_recommendations(soil_params):
    """
    Finds crops that thrived in similar conditions using
    Euclidean distance for similarity scoring.
    """
    client = bigquery.Client()

    query = f"""
    WITH input_params AS (
        SELECT
            {soil_params.nitrogen} as input_n,
            {soil_params.phosphorus} as input_p,
            {soil_params.potassium} as input_k,
            {soil_params.ph} as input_ph,
            {soil_params.temperature} as input_temp,
            {soil_params.humidity} as input_humidity,
            {soil_params.rainfall} as input_rainfall
    )
    SELECT
        crop_name,
        SQRT(
            POW(nitrogen - input_n, 2) +
            POW(phosphorus - input_p, 2) +
            POW(potassium - input_k, 2) +
            POW(ph - input_ph, 2) +
            POW(temperature - input_temp, 2) +
            POW(humidity - input_humidity, 2) +
            POW(rainfall - input_rainfall, 2)
        ) as distance,
        COUNT(*) as similar_conditions_count
    FROM `AgriPath_data.crop_recommendations`, input_params
    GROUP BY crop_name, distance
    ORDER BY distance ASC
    LIMIT 10
    """

    results = client.query(query).result()

    recommendations = []
    for row in results:
        recommendations.append({
            "crop_name": row.crop_name,
            "suitability_score": max(0, 100 - row.distance * 5),
            "confidence": min(100, row.similar_conditions_count / 100 * 100)
        })

    return recommendations

Weatherbit API Integration

import requests

def get_weather_forecast(latitude, longitude):
    """
    Fetches 16-day weather forecast for irrigation planning.
    """
    url = "https://api.weatherbit.io/v2.0/forecast/daily"
    params = {
        "lat": latitude,
        "lon": longitude,
        "days": 16,
        "key": os.getenv("WEATHERBIT_API_KEY")
    }

    response = requests.get(url, params=params)
    data = response.json()

    forecast = []
    for day in data['data']:
        forecast.append({
            "date": day['datetime'],
            "temp_max": day['max_temp'],
            "temp_min": day['min_temp'],
            "precipitation": day['precip'],
            "humidity": day['rh'],
            "wind_speed": day['wind_spd'],
            "recommendation": get_irrigation_recommendation(day)
        })

    return forecast

def get_irrigation_recommendation(day_data):
    """Weather-aware irrigation scheduling"""
    if day_data['precip'] > 20:
        return "SKIP_IRRIGATION_RAIN_FORECAST"
    elif day_data['max_temp'] > 35:
        return "INCREASE_IRRIGATION_HIGH_TEMP"
    else:
        return "NORMAL_IRRIGATION"

Google Maps API for Location Intelligence

import googlemaps

def find_nearest_water_sources(latitude, longitude, radius_km=5):
    """
    Finds canals, rivers, borewells near the farm.
    Critical for irrigation planning.
    """
    gmaps = googlemaps.Client(key=os.getenv("GOOGLE_MAPS_API_KEY"))

    # Search for water bodies
    places = gmaps.places_nearby(
        location=(latitude, longitude),
        radius=radius_km * 1000,
        type='water'  # or specific types like 'canal', 'river'
    )

    water_sources = []
    for place in places['results']:
        distance = calculate_distance(
            (latitude, longitude),
            (place['geometry']['location']['lat'],
             place['geometry']['location']['lng'])
        )

        water_sources.append({
            "name": place['name'],
            "type": classify_water_source(place['types']),
            "distance_km": round(distance, 2),
            "reliability": estimate_reliability(place)
        })

    return sorted(water_sources, key=lambda x: x['distance_km'])

Deployment Journey: Local → Docker → Cloud Run

Step 1: Local Development

# Setup
poetry install
export GOOGLE_CLOUD_PROJECT=agripath-prod
export WEATHERBIT_API_KEY=xxx

# Run locally
uvicorn main:app --reload --port 8080

# Test
curl -X POST http://localhost:8080/api/v1/generate-plan \
  -H "Content-Type: application/json" \
  -d @sample_input.json

Step 2: Dockerization

FROM python:3.11-slim

# Install dependencies
WORKDIR /app
COPY pyproject.toml poetry.lock ./
RUN pip install poetry && poetry install --no-dev

# Copy code
COPY . .

# Run
EXPOSE 8080
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]

Step 3: Cloud Run Deployment

# Build and push
gcloud builds submit --tag gcr.io/agripath-prod/agripath-advanced

# Deploy
gcloud run deploy agripath-advanced \
  --image gcr.io/agripath-prod/agripath-advanced \
  --platform managed \
  --region us-central1 \
  --memory 4Gi \
  --cpu 2 \
  --timeout 300s \
  --max-instances 10 \
  --set-env-vars GOOGLE_CLOUD_PROJECT=agripath-prod \
  --set-secrets WEATHERBIT_API_KEY=weatherbit-key:latest \
  --allow-unauthenticated

# Done! Get URL
gcloud run services describe agripath-advanced \
  --region us-central1 \
  --format 'value(status.url)'

Result: https://agripath-advanced-xxxxx.run.app ✅

Real-World Impact: The Numbers

Case Study 1: Multi-Plot Farmer

Input:

3 plots (5, 7, 3 acres)
₹200,000 budget
5 workers
Rabi season 2024-25

Output:

Plot A: Wheat 5 acres (rotation: soybean→wheat)
Plot B: Radish 7 acres STAGGERED (2+5 acres)
Plot C: Chickpea 3 acres (drought-tolerant)

Financial Results:
| Metric | Value |
|--------|-------|
| Total Investment | ₹180,000 |
| Expected Revenue | ₹1,141,000 |
| Expected Profit | ₹961,000 |
| ROI | 534% |
| Subsidies Captured | ₹158,500 |

Without AgriPath (traditional):

Revenue: ₹710,000
Profit: ₹530,000
AgriPath Advantage: +81% profit 🚀

Case Study 2: Small Farmer

Input:

1 plot (2 acres)
₹50,000 budget
2 workers
Low risk tolerance

Output:

Crop: Chickpea 2 acres
Calendar: 52 activities
Investment: ₹42,000
Expected Revenue: ₹168,000
ROI: 300%

Key Benefits:

Drought-tolerant (only 2 irrigations)
Low input cost
Stable market price
Government subsidy: ₹12,000

Lessons Learned (The Hard Way)

1. Agent Coordination is Hard

Wrong Approach:

# Sequential execution without clear output keys
result1 = agent1.run(input)
result2 = agent2.run(result1)  # What format is result1?

Right Approach:

# Explicit schemas and output keys
class Agent1Output(BaseModel):
    crop_recommendations: List[CropRec]
    confidence_score: float

agent1 = Agent(
    output_schema=Agent1Output,
    output_key="crop_analysis"
)

# Root agent knows to pass crop_analysis to next agent

2. Error Handling is Critical

With 11 agents and 3 external APIs, failures are guaranteed. We learned to:

# Graceful degradation
try:
    weather = fetch_weatherbit_forecast(lat, lon)
except Exception as e:
    logger.warning(f"Weatherbit failed: {e}")
    weather = get_fallback_weather_data()  # Historical averages

# Retry with exponential backoff
@retry(tries=3, delay=2, backoff=2)
def query_bigquery(sql):
    return client.query(sql).result()

# Validate before passing to next agent
output = agent.run(input)
if not validate_schema(output, ExpectedSchema):
    raise ValidationError("Agent output format incorrect")

3. Response Time Matters

Users won't wait 4 minutes. We optimized aggressively:

Cached crop schedules (reduced 50 tool calls)
Parallel data intelligence agents (saved 30s)
Streamlined prompts (20% faster processing)
Used Gemini Flash (5x faster than Pro)

Result: 240s → 90s average ✅

4. Real Data > Perfect Algorithms

We spent weeks perfecting the staggered planting algorithm. Then we realized: garbage in, garbage out.

The real breakthrough came when we integrated actual mandi price data from BigQuery. Suddenly, recommendations went from theoretical to actionable.

Lesson: Spend 80% time on data, 20% on algorithms.

What's Next for AgriPath

Phase 1: Streaming Responses (Next Sprint)

Currently, users wait 90 seconds in silence. We're implementing Server-Sent Events:

from fastapi import Response
from sse_starlette.sse import EventSourceResponse

@app.post("/api/v1/generate-plan-stream")
async def generate_plan_stream(input: AgriPathInput):
    async def event_generator():
        yield {"event": "progress", "data": {"stage": "bigquery_analysis", "percent": 10}}

        bigquery_result = await bigquery_analyst.run(input)
        yield {"event": "progress", "data": {"stage": "weather_forecast", "percent": 25}}

        # ... continue through all agents

        yield {"event": "complete", "data": complete_plan}

    return EventSourceResponse(event_generator())

Phase 2: Mobile App (React Native)

Farmers prefer mobile. Building:

Offline calendar access
Push notifications
Camera for soil photo analysis
Voice input (Hindi, Tamil, Telugu)

Phase 3: IoT Integration

Connect soil sensors and weather stations:

Real-time moisture, pH, temperature
Automated irrigation triggers
Micro-climate data for better predictions

Try AgriPath Yourself

Live Demo: https://agripath-demo.run.app

Sample Request:

curl -X POST https://agripath-advanced-xxxxx.run.app/api/v1/generate-plan \
  -H "Content-Type: application/json" \
  -d '{
    "farmer_id": "DEMO_001",
    "location": {"district": "Lucknow", "state": "UP"},
    "plots": [{
      "plot_id": "DEMO_PLOT",
      "size_acres": 5.0,
      "soil_ph": 6.8,
      "irrigation_available": true
    }],
    "resources": {
      "labor_workers": 3,
      "budget": 100000
    },
    "target_season": "rabi_2024"
  }'

GitHub: github.com/yourusername/agripath-advanced

Why This Matters

In India:

140 million farmers
60% live below poverty line
Average farm size: 1.08 hectares (2.7 acres)

If AgriPath helps just 1% of farmers increase profits by 50%, that's:

1.4 million farmers helped
₹50,000+ extra income per farmer per year
₹70 billion ($850 million) additional rural income

This isn't just a hackathon project. It's a mission to make farming profitable again.

Technical Deep Dives (For the Nerds)

Agent Prompt Engineering

Bad Prompt:

You are a calendar generator. Create activities for farming.

Good Prompt:

You are the `calendar_roadmap_generator_agent`.

<Steps>
1. For each crop, call get_crop_activity_schedule(crop_name)
2. Generate land prep 7 days before sowing
3. Calculate materials: seeds, fertilizers, pesticides
4. Generate irrigation based on weather forecast
5. Add fertilizer on specific days (21, 45, 75)
6. Generate harvesting activity
7. Sort by date
8. Validate budget constraint
</Steps>

<Example>
Input: {"crop": "wheat", "area": 5.0, "sowing_date": "2024-12-10"}
Output: {
  "activities": [
    {
      "date": "2024-12-03",
      "type": "land_preparation",
      "materials": [...],
      "instructions": [...]
    }
  ]
}
</Example>

<MaterialCalculations>
Wheat per acre:
- Seeds: 40kg @ ₹62.5/kg
- DAP: 60kg @ ₹40/kg
- Urea: 50kg @ ₹15/kg
</MaterialCalculations>

Pydantic Schema Design

# Bad: Loose typing
def generate_plan(input: dict) -> dict:
    # What's in input? What's in output?
    pass

# Good: Strict typing
class PlotInfo(BaseModel):
    plot_id: str
    size_acres: float = Field(gt=0, le=100)
    soil_ph: float = Field(ge=4.0, le=9.0)
    irrigation_available: bool

    @validator('soil_ph')
    def validate_ph(cls, v):
        if not 5.5 <= v <= 8.0:
            raise ValueError("Optimal pH range: 5.5-8.0")
        return v

class AgriPathInput(BaseModel):
    farmer_id: str
    location: LocationInfo
    plots: List[PlotInfo] = Field(min_items=1, max_items=5)
    resources: ResourceInfo
    target_season: str
    preferences: Optional[PreferenceInfo]

def generate_plan(input: AgriPathInput) -> AgriPathOutput:
    # Now we have full type safety!
    pass

BigQuery Query Optimization

# Before: Slow query (15s)
SELECT * FROM cultivation_records
WHERE soil_ph BETWEEN 6.0 AND 7.5

# After: Fast query (0.8s)
CREATE INDEX idx_soil_ph ON cultivation_records(soil_ph)

SELECT 
    crop_name,
    AVG(yield_per_acre) as avg_yield,
    COUNT(*) as records
FROM cultivation_records
WHERE soil_ph BETWEEN 6.0 AND 7.5
GROUP BY crop_name
HAVING COUNT(*) >= 10
ORDER BY avg_yield DESC
LIMIT 10

Acknowledgments

This project wouldn't exist without:

Google Cloud Team - Cloud Run's generous limits made this possible
Google ADK Team - Clean abstractions, great docs
Gemini Team - Fast, affordable, powerful models
My Uncle - For inspiring this with his radish farming story
Agricultural Extension Officers - For crop cultivation data
Indian Farmers - The real heroes who feed 1.4 billion people

Final Thoughts

Building AgriPath taught me that AI's biggest impact isn't replacing humans—it's giving them superpowers.

Farmers have decades of experience. They don't need AI to tell them radish grows in 60 days. They need AI to:

Analyze 10,000 cultivation records in seconds
Predict price crashes using historical data
Generate 185 activities with exact materials
Calculate ROI for different scenarios
Find government subsidies they didn't know existed

That's the promise of AI: augmenting human expertise, not replacing it.

If you're building with Google Cloud Run or ADK, I hope this deep dive helps. And if you know any farmers, please share AgriPath with them. Let's make farming profitable again, one plan at a time.

Built with ❤️ for farmers

#CloudRunHackathon #GoogleADK #AIForGood

Comments?

What do you think? Have you built multi-agent systems? Any questions about the staggered planting algorithm or Cloud Run deployment?

Drop your thoughts below! 👇

P.S. If you're participating in the Google Cloud Run Hackathon, good luck! Focus on solving real problems, not showcasing tech. The best projects are the ones that actually help people.

P.P.S. Star the repo if you found this useful: github.com/yourusername/agripath-advanced ⭐

Building BrainBattle AI: Simulating Your Brain's Product Decision with 9 AI Agents on Google Cloud Run published

Anil Kumar — Tue, 11 Nov 2025 00:32:00 +0000

🧠 The Problem: 6 Hours of Shopping Hell
Picture this: It's 11 PM. I have 47 browser tabs open. Three smartphones, each with 50+ specifications. Amazon reviews, YouTube comparisons, spec sheets everywhere.

Six hours later, I'm still paralyzed. Can't decide.

Sound familiar?

That's when it hit me: Comparison sites show data, but our brains make decisions through debates. We naturally argue with ourselves:

🤓 "This has better specs!"
💰 "But you're overpaying by ₹5000!"
👔 "What about brand perception?"
🛠️ "Can you even get it serviced?"
Why don't tools reflect this?

Enter BrainBattle AI - a multi-agent system that simulates your internal brain debate using 9 AI agents.

🚀 What BrainBattle Does
Instead of boring spec tables, BrainBattle shows you how different parts of your mind evaluate products:

🤓 Tech Geek: 80/100 "Snapdragon 8 Gen 2 is flagship!"
💰 Frugal: 90/100 "Great value at ₹14,999"
👔 Status: 75/100 "Samsung is respected brand"
🛠️ Practical: 85/100 "250 service centers nationwide"
─────────────────────────────────────────────────
Base Score: 82.5/100

Validators:
✅ Reviews: +5.0 "18k reviews confirm quality"
🔍 Facts: -10.0 "200MP is actually 12.5MP output"
💸 Deals: +15.0 "Genuine 24% discount verified"
⚖️ Bias: -3.0 "Brand slightly over-rated"
─────────────────────────────────────────────────
Final Score: 89.5/100 ⭐ WINNER
Then comes the killer feature: "What-if" scenarios.

🤔 What if you pick #2 instead?

✅ GAINS:
• Tech Geek: "200MP camera + 100W charging"

❌ LOSSES:
• Frugal: "₹8,000 more expensive"
• Practical: "20% less battery life"

📊 Net: -3.5 points
💡 Stick with #1 unless camera is priority
No more buyer's remorse.

🏗️ The Tech Stack
Here's what powers BrainBattle:

Framework: Google Agent Development Kit (ADK)
LLM: Gemini 2.0 Flash
Backend: Python 3.11 + Pydantic v2
Deployment: Google Cloud Run
Database: Google Firestore
CI/CD: Cloud Build
🤖 The 9 AI Agents
Core Decision Agents (Run in Parallel)

Tech Geek Brain (25% weight)

tech_geek_agent = LlmAgent(
model=MODEL,
name="tech_geek_agent",
description="Evaluates technical specifications",
static_instruction=TECH_GEEK_PROMPT,
output_schema=CoreAgentOutput,
generate_content_config=genai_types.GenerateContentConfig(
response_mime_type="application/json" # Force JSON
)
)
Analyzes processors, displays, cameras. Verdict: "Exynos 1380 is solid mid-range."

Frugal Brain (30% weight - highest!)

frugal_agent = LlmAgent(
name="frugal_brain_agent",
tools=[analyze_pricing], # Price analysis tool
output_schema=CoreAgentOutput,
)
Calculates value, detects fake discounts. Verdict: "You're overpaying for unused features!"

Status Brain (20% weight)

status_agent = LlmAgent(
name="status_brain_agent",
static_instruction=STATUS_PROMPT,
output_schema=CoreAgentOutput,
)
Evaluates brand perception. Verdict: "Samsung commands respect in professional circles."

Practical Brain (25% weight)

practical_agent = LlmAgent(
name="practical_brain_agent",
static_instruction=PRACTICAL_PROMPT,
output_schema=CoreAgentOutput,
)
Focuses on real-world use. Verdict: "Samsung has 250 service centers vs Realme's 180."

Validator Pipeline (Run Sequentially)

Review Validator (±20 points)

review_validator_agent = LlmAgent(
name="review_validator_agent",
tools=[analyze_reviews], # Sentiment analysis
output_schema=ValidatorOutput,
)
Analyzes 18,500+ user reviews. Example: "Users confirm battery life (+15) but camera disappoints (-8)"

Fact Checker (±15 points)

Catches marketing BS. Example: "200MP uses 16-to-1 binning - outputs 12.5MP (-12 points)"

Deal Checker (±20 points)

Verifies pricing. Example: "Genuine 24% discount, ₹6,000 real savings (+18 points)"

Bias Detector (±10 points)

Ensures fairness. Example: "Status over-rated Samsung brand (-3 points)"

Root Agent (Orchestrator)

root_agent = LlmAgent(
model=MODEL,
name="brainbattle_orchestrator",
sub_agents=[
tech_geek_agent,
frugal_agent,
status_agent,
practical_agent,
review_validator_agent,
fact_checker_agent,
deal_checker_agent,
bias_detector_agent,
],
input_schema=ComparisonInput,
output_schema=SimpleBrainBattleOutput,
)
Coordinates all 8 agents and produces final output.

🔥 The Architecture Challenge
Initial Approach (FAILED ❌)
I started with nested agents:

❌ This caused hanging/timeouts

root_agent = LlmAgent(
sub_agents=[
ParallelAgent( # Nested!
sub_agents=[tech_geek, frugal, status, practical]
),
SequentialAgent( # Nested!
sub_agents=[review, fact, deal, bias]
),
]
)
Problem: Agents would hang mid-execution. No error, no timeout, just... silence.

After 2 days of debugging: nested coordination caused race conditions.

Final Solution (WORKS ✅)
Flatten everything:

✅ All agents as direct peers

root_agent = LlmAgent(
sub_agents=[
tech_geek, frugal, status, practical, # Peers
review, fact, deal, bias # Peers
]
)
Result: Stable, predictable, fast (3-5 seconds).

Lesson: Simple > Elegant in production.

🎯 Challenge #2: Getting Agents to Output JSON
Agents kept returning markdown:

❌ Agent Output:
Here's my analysis:

{"agent_id": "tech_geek", ...}

Even with output_schema! Why?

Answer: LLMs default to conversational format.

The 3-Layer Solution


python
# Layer 1: Pydantic Schema
class TechGeekOutput(BaseModel):
    agent_id: str
    evaluations: List[Dict]

# Layer 2: MIME Type
generate_content_config=genai_types.GenerateContentConfig(
    response_mime_type="application/json"  # Critical!
)

# Layer 3: Prompt Instructions
PROMPT = """
<Output_Format>
Return ONLY valid JSON. No markdown. No preamble.
{
  "agent_id": "tech_geek",
  "evaluations": [...]
}
</Output_Format>
"""

agent = LlmAgent(
    output_schema=TechGeekOutput,      # Layer 1
    generate_content_config=config,     # Layer 2
    static_instruction=PROMPT           # Layer 3
)
Result: 100% JSON compliance.

🛠️ Tool Functions: Docstrings Matter!
Here's something I learned the hard way: Tool docstrings are agent instructions.

Bad (agents ignored it):
def analyze_reviews(input: ReviewAnalysisInput) -> ReviewAnalysisOutput:
    """Analyze reviews."""
    # Implementation...
Good (80% better usage):
def analyze_reviews(input: ReviewAnalysisInput) -> ReviewAnalysisOutput:
    """
    Analyze user reviews with sentiment analysis and trust scoring.

    This tool processes market feedback to validate product claims against
    real user experiences. It extracts sentiment scores, identifies common
    themes, and calculates trust scores based on review volume.

    Args:
        input (ReviewAnalysisInput): Pydantic model containing product with
            marketFeedback array including ratings, review counts, summaries.

    Returns:
        ReviewAnalysisOutput: Pydantic model with:
            - sentiment_score (0-1): Overall sentiment
            - trust_score (0-1): Based on review volume
            - key_positives: Praised features
            - key_negatives: Common complaints
            - recommendation_adjustment (-20 to +20): Score adjustment

    Example:
        >>> result = analyze_reviews(ReviewAnalysisInput(product=product))
        >>> print(result.sentiment_score)  # 0.84
        >>> print(result.recommendation_adjustment)  # +5.0
    """
Why? The LLM reads docstrings to understand when/how to use tools.

Lesson: Write docstrings for AI, not just humans.

☁️ Deploying to Cloud Run
This was surprisingly easy.

Step 1: Dockerfile
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
ENV PORT=8080
EXPOSE 8080
CMD ["adk", "api_server", "--host", "0.0.0.0", "--port", "8080"]
Step 2: Deploy
gcloud run deploy brainbattle-ai \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --set-env-vars GOOGLE_API_KEY=$GOOGLE_API_KEY \
  --memory 2Gi \
  --cpu 2 \
  --timeout 300s \
  --min-instances 0 \
  --max-instances 10
That's it! Cloud Run:

✅ Built container automatically
✅ Deployed to serverless infra
✅ Configured auto-scaling (0-10 instances)
✅ Generated HTTPS endpoint
✅ Set up load balancing
Step 3: CI/CD
# cloudbuild.yaml
steps:
  - name: "gcr.io/cloud-builders/docker"
    args: ["build", "-t", "gcr.io/$PROJECT_ID/brainbattle-ai", "."]

  - name: "gcr.io/cloud-builders/docker"
    args: ["push", "gcr.io/$PROJECT_ID/brainbattle-ai"]

  - name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
    args: ["run", "deploy", "brainbattle-ai", ...]
Every git push → automatic deployment. DevOps heaven!

📊 Performance & Cost
Response Times
Products    Time    Use Case
2 products  3-4s    Most common
3 products  4-5s    Sweet spot
5 products  6-8s    Still good
Cost Analysis
Per Comparison:

Gemini Flash: $0.001
Cloud Run: $0.0001
Firestore: $0.0001
Total: $0.001 💰
At Scale (100k comparisons/month):

Costs: ~$100
Revenue (freemium): $5,000-10,000
Margin: 98%+ 🚀
Why Cloud Run?
Serverless: No infrastructure management
Auto-scaling: 0 to 10+ instances automatically
Cost-effective: Pay per use (mostly free tier!)
Fast deployment: One command
Built-in HTTPS: Free SSL
Real metrics from production:

Cold start: 2-3s
Warm request: 3-4s
P95 latency: <6s
Uptime: 99.9%
🎨 The API
Request
curl -X POST https://brainbattle-ai.run.app/v1/chat \
  -H "Content-Type: application/json" \
  -d '{
    "products": [
      {
        "id": "prod_samsung_m35",
        "name": "Samsung Galaxy M35 5G",
        "brand": "Samsung",
        "pricing": [{
          "MRP": "₹18,999",
          "currentPrice": "₹14,999"
        }],
        "marketFeedback": [{
          "averageRating": 4.2,
          "totalReviews": 18500
        }],
        "specifications": {
          "processor": "Exynos 1380",
          "battery": "6000 mAh"
        }
      },
      {
        "id": "prod_realme_11",
        "name": "Realme 11 Pro+ 5G",
        ...
      }
    ]
  }'
Response
{
    "evaluations": [
        {
            "product_id": "prod_samsung_m35",
            "rank": 1,
            "final_score": 89.5,
            "tech_geek_score": 80,
            "frugal_score": 90,
            "status_score": 75,
            "practical_score": 85,
            "review_adjustment": 5,
            "fact_adjustment": -10,
            "deal_adjustment": 15,
            "bias_adjustment": -3,
            "verdict": {
                "is_winner": true,
                "winning_reason": "Best overall value with excellent battery",
                "strengths": "6000mAh battery, Samsung reliability",
                "weaknesses": "Mid-range processor, average camera"
            }
        }
    ],
    "what_if_scenarios": {
        "rank_2": {
            "gains": ["200MP camera", "100W charging"],
            "losses": ["₹8000 more", "Smaller battery"],
            "recommendation": "Stick with winner unless camera priority"
        }
    }
}
💡 Key Learnings
1. Flat > Nested (in production)
Nested agents caused reliability issues
Flat structure is simpler and debuggable
Lesson: Production reliability > architectural elegance
2. Output Control Needs Layers
Schema alone doesn't enforce JSON
Combine: Schema + MIME + Prompt
Lesson: Defense in depth
3. Docstrings Are Instructions
LLMs read docstrings to understand tools
Comprehensive docs = 80% better usage
Lesson: Write for AI, not just humans
4. Cloud Run Just Works
No "warmup period" needed
Auto-scaling handles everything
Lesson: Serverless actually works for AI
5. Transparency Builds Trust
Users want to see reasoning
Explainable AI wins
Lesson: Show your work
🚀 What's Next?
Phase 2 (Next 3 months)
🎨 React web interface
📱 More categories (laptops, tablets)
🎯 Personalization (custom weights)
🔍 YouTube review analysis
Phase 3 (Months 4-6)
💰 Freemium model (₹99/month)
🏢 B2B API licensing
🤝 E-commerce partnerships
Vision
Become the "Google for Purchase Decisions"

Market: $5 trillion e-commerce Problem: 30% buyer's regret Solution: Transparent AI decision support

🎯 Try It Now!
Live Demo: https://brainbattle-ai.run.app

GitHub: https://github.com/yourusername/brainbattle-ai

Quick Test:

curl -X POST https://brainbattle-ai.run.app/v1/chat \
  -H "Content-Type: application/json" \
  -d @example_request.json
📝 For Hackathon Participants
If you're building with Cloud Run:

Start simple: Flat architectures work
Use ADK: Multi-agent coordination is easy
Enforce output: Schema + MIME + Prompt
Write great docstrings: AI reads them
Deploy early: Cloud Run makes it easy
🏆 Why This Project Matters
Problem Solved: Decision paralysis affects millions daily

Innovation: First to simulate brain debate for purchases

Technical: Production-ready multi-agent system

Business: Clear path to $100M+ market

Impact: 70% less research time, 50% less regret

🙏 Built With
Google Agent Development Kit
Gemini 2.0 Flash
Google Cloud Run
Google Firestore
Pydantic
🔗 Links
Live Demo: https://brainbattle-ai.run.app
GitHub: https://github.com/anil9973/brainbattle-ai
Devpost: https://devpost.com/software/brainbattle-ai
Architecture: View Diagram
💬 Let's Connect
Questions? Ideas? Found a bug?

💬 Comment below
🐛 Open an issue
⭐ Star on GitHub
🐦 Tweet at me
Hackathon Note: This project was built for the Google Cloud Run Hackathon - AI Agents Category. All code is original work created for this competition.

If you found this helpful:

💙 React with a unicorn
💾 Save for later
🔄 Share with your network
⭐ Star on GitHub
Tags: #cloudrun #ai #python #googlecloud #gemini #agents #serverless #hackathon

Your brain already debates when choosing products. BrainBattle just makes it visible. 🧠⚡