Gemma 3n Impact Challenge: Stigmergy ODEA, Edge AI Drone Swarms, and the $462.18 YOLO Mode Doom Loop

In the summer of 2025, Google launched The Gemma 3n Impact Challenge on Kaggle (running from June 26 through August 6, 2025). This marked my second official Kaggle competition, following my first Kaggle hackathon experience at Google Cloud Next 2024 in Las Vegas.

Having previously experimented with wearable edge form factors for the Google I/O Gemini API Developer Competition—where I deployed OpenMMPA on a Full Android Watch (FAW)—that project still relied on cloud-hosted LLMs for heavy cognitive lifting, using the device primarily for local vector storage, audio processing, and tool routing. For the Gemma 3n challenge, I wanted to take edge intelligence to its logical conclusion: 100% on-device, disconnected, multi-modal generative AI running on ultra-compact physical hardware.

The result was Stigmergy ODEA (On-Device Edge Agents): an autonomous, decentralized drone swarm system engineered to support search-and-rescue teams during catastrophic natural disasters.

Building it turned out to be an incredible technical journey—complete with local multi-modal vision models, peer-to-peer ad-hoc networking, Byzantine-resistant failovers, and one unforgettable AI coding war story: an autonomous coding agent that burned $462.18 in API tokens in a single holiday weekend while trapped in a recursive Gradle build “doom loop.”

The Mission: Stigmergy ODEA for Disaster Zones

When major earthquakes, flash floods, or wildfires strike, critical infrastructure collapses almost immediately:

• Cell towers lose power or backhaul connectivity.
• GPS signals are degraded by urban canyon multipath or atmospheric disturbances (such as solar storms).
• Roads are impassable, leaving first responders blind to structural integrity and survivor locations in the critical first 72 hours.

Under these conditions, cloud-tethered AI is completely useless. A search-and-rescue drone swarm cannot rely on 5G uplinks, centralized cloud orchestration, or even persistent satellite navigation.

To solve this, I designed Stigmergy ODEA around the biological principle of stigmergy—the mechanism of indirect, decentralized coordination observed in ant colonies and termite mounds, where individual agents respond to local environmental signals and shared cues without centralized control.

Core Architectural Pillars:

1. Pocket-Sized Compute Nodes: I purchased two Unihertz Jelly Star phones—billed as the world’s smallest Android 13 smartphone. Despite its tiny 3.0-inch display, the Jelly Star packs an octa-core MediaTek Helio G99 processor and 8 GB of RAM. That 8 GB RAM headroom is the golden threshold: it provides just enough memory to load and execute quantized Gemma 3n E2B (Gemma-3n-E2B-it-int4, ~3.1 GB) entirely in local RAM and on-device CPU/GPU. The device also includes an arm strap that can be easily adapted into a drone payload mount or wearable wrist terminal.
2. Peer-to-Peer Ad-Hoc Connectivity: Instead of relying on Wi-Fi routers or cellular data, the swarm communicates locally via the Android Nearby Connections API using a dynamic Star/Cluster topology.
3. Decentralized Leader Election & Failover: Swarm nodes designate a temporary “Commander” hub that coordinates group broadcasts. If the Commander drone is destroyed, jammed, or knocked offline, the subordinate agents detect the absence after a brief grace period, elect a new coordinator among themselves, and continue the mission without human intervention.
4. Cryptographic Identity & Sybil Attack Defense: In chaotic tactical environments, malicious adversaries might attempt electronic intrusion. Every drone is provisioned with asymmetric cryptographic key pairs. Broadcast messages are signed and verified against pre-installed public keys. If an adversary attempts an identity duplication or Sybil spoofing attack, the internal verification logic immediately drops the packet before it ever reaches the LLM context.
5. Cognitive Guardrails & Prompt Injection Defense: Because LLM agents in a swarm receive peer broadcasts, an adversary could try indirect prompt injection to derail the mission. Each node’s local Gemma 3n model acts as an internal cognitive filter, evaluating incoming directives against hardcoded humanitarian mission parameters and rejecting contradictory or harmful instructions (such as rogue “self-destruct” commands).
6. Multi-Modal Visual Landmark Grounding: When GPS fails, drones use their onboard cameras and Gemma 3n’s multi-modal vision capabilities to cross-reference real-time visual feeds against stored mission imagery—distinguishing between target structures and unrelated buildings to maintain accurate navigation.

The Vision: JetBrains Koog and Kotlin Multiplatform

When architecting the project, I initially aimed for maximum cross-platform purity. I envisioned a Kotlin Multiplatform (KMP) codebase that could compile both as an Android payload app for the drones and as a desktop/embedded dashboard for base-station operators.

For the agent orchestration layer, I chose JetBrains Koog, an idiomatic Kotlin-native framework designed for building structured AI agent workflows. Koog already had built-in support for Ollama as a local model provider, so my plan was to build an official LiteRT (Google’s upgraded successor to TensorFlow Lite) provider for Koog that mimicked the Ollama interface while binding directly to Google’s on-device Gemma 3n runtimes.

My working hypothesis was straightforward: Kotlin, Android, and KMP are foundational to Google’s engineering ecosystem. Surely, Google’s flagship AI models—specifically Gemini CLI and the then-preview Google Jules coding agent—would have exceptional training and proficiency in modern Android and Kotlin development.

That hypothesis was about to collide violently with the reality of the Android build ecosystem.

The $462.18 YOLO Mode “Doom Loop”

Over the 4th of July Independence Day holiday, my family visited my sister-in-law in New York. While family gatherings filled the days, I spent late evenings coding and testing features. Because I needed the application to compile and deploy to the physical Jelly Star test devices plugged into my USB ports, cloud-hosted coding agents like Google Jules (which run in remote sandboxes without access to physical ADB hardware) weren’t suitable for deployment validation.

Enter the Gemini CLI.

I configured Gemini CLI locally, connected it to my Google Cloud Platform (GCP) project, and invoked it in autonomous mode (--yolo). The prompt was straightforward:

“Here is the repository with our Kotlin Multiplatform scaffold, JetBrains Koog, and the LiteRT integration. Fix any compilation, Gradle, or dependency errors so that ./gradlew assembleDebug succeeds and the app can deploy to the connected Android device.”

I closed my laptop lid and went to sleep, expecting a compiled APK by morning.

The Volatility Trap of Modern Android

What I didn’t fully account for was the combinatorial explosion of breaking changes across recent Android Gradle Plugin (AGP) and Kotlin releases:

• Manifest vs. Namespace: In AGP 8+, setting package="com.google.ai.edge.gallery" in AndroidManifest.xml was deprecated and later removed in favor of android { namespace = "..." } in Gradle build scripts.
• Groovy to Kotlin DSL: The entire Gradle ecosystem migrated from Groovy scripts (build.gradle) to Kotlin Script (build.gradle.kts), altering syntax for plugins, compiler flags, and source sets.
• Version Catalogs: Modern projects define dependencies in gradle/libs.versions.toml, requiring different plugin resolution mechanics than legacy buildscript { dependencies { ... } } blocks.
• Kotlin Compiler Churn: Flags like -Xcontext-receivers were superseded by -Xcontext-parameters, while options like jvmTarget shifted under the compilerOptions DSL.
• Native JNI & C++ Bindings: Binding LiteRT native shared libraries (liblitert_runtime.so) alongside Protobuf code generation (protoc-gen-java) and ObjectBox bytecode transformers added another layer of build-time fragility.

When an LLM searches its training weights for Android solutions, it encounters a vast historical record of conflicting answers: 2018 StackOverflow threads using Groovy, 2021 blogs using early build.gradle.kts, 2023 docs using AGP 7 namespace migrations, and 2024 AGP 8 TOML catalogs.

Night 1: The First Descent

Instead of systematically diagnosing the build error, the autonomous CLI agent fell into a classic “doom loop”:

1. It encountered a Version Catalog TOML mismatch with the ObjectBox Gradle plugin.
2. It attempted to fix it by converting the syntax to an older Groovy-style snippet inside build.gradle.kts.
3. The Kotlin compiler rejected the syntax, triggering a plugin resolution error.
4. The agent then suspected the AndroidManifest was missing a package attribute, re-added the deprecated package tag, and ran the build again.
5. AGP rejected the deprecated attribute.
6. The agent reverted the manifest change, tried a third syntax variation, failed, and then reverted its own revert.

Cycle after cycle, prompt after prompt, the agent executed thousands of LLM inference calls overnight. When I woke up on July 5th, the project still failed to compile, and my GCP dashboard showed an initial hit of approximately $50 in token consumption.

Night 2: Doubling Down

Believing that the agent had simply gotten hung up on a minor plugin issue, I spent the afternoon cleaning up the source code, adding features, and manually smoothing out the dependencies. That night, convinced that the agent was only a few tweaks away from a green build, I launched Gemini CLI in --yolo mode again before going to bed.

History repeated itself. The agent encountered another cyclic conflict between the Protobuf code generator and KMP multi-platform source sets, looping through hundreds of trial-and-error edits. By morning, another large chunk of tokens had vanished, and the build remained broken.

The Bill Arrives

Due to the reporting latency of Google Cloud Billing, the full usage data trickled in over the following days. Because I had previously elevated my GCP spending caps for multi-agent hackathons, the circuit breaker didn’t trip.

When the dust settled, the token bill for those two nights and surrounding development came out to exactly $462.18 USD!

[Billing Alert] Google Cloud Platform
Project: Multi-Modal Agent Development
Total Vertex / Gemini API Charges: $462.18
Status: Ingestion finalized

[!WARNING] The Hard-Learned Lesson of “YOLO Mode” Autonomous agent execution (--yolo in Gemini CLI, or its modern successor --dangerously-skip-permissions in tools like the Google Antigravity agy CLI) can be a phenomenal tool for linear, verifiable edits. But running an unconstrained agent overnight on a non-converging build loop is a recipe for massive token drain.

If an agent fails to resolve a build error within 3–5 iterations, stop the agent. Do not raise spend limits without setting hard circuit breakers or strict loop-detection hooks!

The Pragmatic Pivot: LiteRT Gallery Foundation

Faced with a $462.18 lesson and a fast-approaching competition deadline, I stepped back and re-evaluated. Fighting the bleeding-edge combination of KMP, custom Koog LiteRT providers, and native Android plugins from scratch was a classic case of unnecessary accidental complexity.

I pivoted to a pragmatic engineering strategy:

1. I pulled down Google’s official, proven Google AI Edge Gallery sample application—which already had stable Gradle build files, native LiteRT runtime bindings, and proper GPU delegate acceleration.
2. I created the Open-Distributed-Edge-Agents/EdgeGenAI repository as a dedicated fork.
3. I built the Stigmergy ODEA architecture directly into this foundation:
   • Added the NearbyConnectionsManager for peer-to-peer Star topology coordination.
   • Built the Group Chat subsystem with role switching (Commander vs. Agents 1–3).
   • Integrated ObjectBox on-device vector storage for chunking and retrieving mission-specific disaster briefings.
   • Implemented asymmetric key signature generation and verification to reject spoofed/Sybil broadcasts.
   • Added cognitive guardrail filters to screen prompts before forwarding them to the Gemma model.

Even modifying this working gallery app required careful navigation around modern Android tooling quirks—such as deprecated protoc Java plugins, AGP namespace requirements, and Kotlin context parameters:

> Task :app:processDebugMainManifest
package="com.google.ai.edge.gallery" found in source AndroidManifest.xml:
Setting the namespace via the package attribute in the source AndroidManifest.xml is no longer supported, and the value is ignored.
Recommendation: remove package="com.google.ai.edge.gallery" from AndroidManifest.xml.

w: Experimental context receivers are superseded by context parameters.
Replace the '-Xcontext-receivers' compiler argument with '-Xcontext-parameters'.

Once those were resolved, the app compiled cleanly, deployed to the dual Unihertz Jelly Star handsets over USB, and ran flawlessly.

On-Device Performance: Gemma 3n E2B on 8 GB RAM

Watching a full multi-modal generative AI model run locally on a 3-inch phone held in the palm of your hand is nothing short of magical.

On the Unihertz Jelly Star’s MediaTek Helio G99 processor:

• Model: Gemma-3n-E2B-it-int4 (4-bit quantized, 4096 context length, 3.1 GB disk footprint).
• Time to First Token: ~9.05 seconds.
• Prefill Speed: 58.36 tokens/sec.
• Decode Speed: 9.90 tokens/sec.
• Total Latency: ~14.0 seconds for a full multi-modal visual comparison.

In our visual validation test, we fed the agent an aerial photograph of a sprawling modern corporate headquarters and asked whether it matched the mission objective image (which depicted a medieval fortress). The on-device model accurately responded:

“No, the mission objective building’s image does not match the currently depicted building photo. The mission objective image shows a medieval castle, while the photo shows a modern, sprawling corporate campus. These are fundamentally different architectural styles.”

The model performed this image-to-text semantic comparison completely offline—with airplane mode enabled, zero Wi-Fi, zero cellular data, and zero cloud calls.

Video Production: Prompting Google Flow in 8-Second Slices

For the Kaggle challenge submission, we needed a compelling cinematic demonstration illustrating the disaster response scenario, drone swarm failover, and cryptographic defense.

At that time, Google had just introduced Google Flow, its experimental AI generative video tool. However, Flow had a strict technical constraint: it could only generate video clips up to 8 seconds at a time.

To produce a coherent 2-minute narrative, I used Gemini to script out the storyboard into exact 8-second increments. Each prompt was engineered with consistent aesthetic anchors, lighting directives, and camera motions so that consecutive clips could blend together:

Prompt 1 (0:00-0:08): Wide cinematic aerial shot of a devastated earthquake zone, 
dust rising, cracked highways, dramatic golden hour lighting, slow forward camera track.

Prompt 2 (0:08-0:16): Close-up of a high-tech quadcopter drone launching into the air, 
carbon fiber chassis, glowing status LEDs, autonomous swarm formation visible in background.

Prompt 3 (0:16-0:24): Futuristic heads-up display showing dynamic star topology network 
between 4 drones, sudden red warning indicator showing central hub offline, 
instant green rerouting showing automatic failover leader election.

Flow generated two alternative takes for each prompt, allowing me to review the candidate pairs and pick the rendition with the best spatial continuity. I then imported the selected takes, screen recordings from the Jelly Star handsets, and voiceover audio into Shotcut (the open-source, cross-platform video editor) to produce the final competition submission video:

Project Repositories

• EdgeGenAI (Stigmergy ODEA Android App): github.com/Open-Distributed-Edge-Agents/EdgeGenAI
• Google AI Edge Gallery (Upstream Base): github.com/google-ai-edge/gallery
• JetBrains Koog Framework: jetbrains.com/koog
• Kaggle Challenge Overview: kaggle.com/competitions/google-gemma-3n-hackathon

Retrospective & Takeaways

1. Edge LLMs Are Ready for Practical Robotics: Running Gemma 3n E2B on an $80, 8 GB micro-smartphone demonstrates that autonomous drones and field robots no longer need to be simple sensors piping telemetry back to a mothership. They can possess genuine on-board cognitive reasoning, visual comprehension, and local language understanding.
2. Beware Autonomous Coding Doom Loops: Autonomous AI coding tools are revolutionary productivity multipliers, but they must be managed like junior developers with high-speed internet access and an unlimited corporate credit card. Never leave an autonomous agent unattended on open-ended build debugging without hard loop limits, cost alerts, and strict circuit breakers.
3. Pragmatism Beats Purity: While building a pure Kotlin Multiplatform architecture with custom Koog LiteRT bindings was an elegant vision, pivoting to an established, working sample app allowed me to deliver a fully functional, winning demo before the competition deadline. In hackathons as in production engineering, working software always trumps architectural perfection.