From 4,000+ Applications to 250 Builders: Building a Multi-Agent Video Pipeline at the Google DeepMind Bangalore Hackathon

Karthik Unnikrishnan — Mon, 03 Aug 2026 17:18:56 +0000

TL;DR

Got selected out of 4,000+ applicants for the Google DeepMind Bangalore Hackathon 2026 (250 builders made it in). My teammate and I merged two hackathon tracks — Conversational Video & Motion with Omni Flash and Local-First Agents with Gemma 4 — into one pipeline: a multi-turn conversational video orchestration agent that asks clarifying questions and iteratively refines its output, backed by on-device reasoning for state management. No trophy this time, but a working prototype and a lot of lessons. Here's the build.

The selection

Google DeepMind and Cerebral Valley ran this hackathon in Bangalore, and the numbers alone made it feel different from the college-circuit events I'd been doing: 4,000+ applications, 250 seats. Getting the acceptance email didn't fully register until I was actually in the room — this wasn't a campus event anymore, it was a room full of people who build for a living.

The idea: merging two tracks instead of picking one

The hackathon offered several tracks. Two stood out to me and Rohan:

Conversational Video & Motion with Omni Flash — generate and iterate on video through natural conversation
Local-First Agents with Gemma 4 — on-device reasoning and autonomous decision-making

Instead of choosing one, we asked: what if the video generation system was the agent? So we built a pipeline where:

Gemini Omni Flash + NB2 Lite handle multi-turn conversational video orchestration — the system doesn't just take a prompt and spit out a video. It asks clarifying questions, holds context across turns, and iteratively refines the output based on what the user actually meant.
Gemma 4 runs on-device for state management and decision-making — tracking where the conversation is, what's already been generated, what still needs clarifying, and deciding the next action locally instead of round-tripping everything through a heavier model.

The result was an agent that blends reasoning, local intelligence, and multimodal generation into a single loop, rather than three separate systems bolted together.

What building under a deadline like this actually felt like

Tight deadlines are a hackathon constant, but the density of the room changes the pressure. Every table around us was shipping something legitimately interesting, which is equal parts motivating and intimidating. Having a partner who's good at both brainstorming and debugging (thanks, Rohan) mattered more here than in any hackathon I'd done before — there wasn't time to context-switch between "figuring out the architecture" and "fixing why the state manager is out of sync."

The outcome

We didn't place. No trophy this round. But we left with:

A working end-to-end prototype of the conversational video + local agent pipeline
Direct exposure to how a team like DeepMind's frames the "agentic + multimodal" problem space
Genuinely useful conversations with other builders working on adjacent problems
Insights from Amit Vadi and Ray Del Vecchio, who spoke at the event

Why I'm writing this up

Hackathons are noisy — you build for 24-48 hours, present, and the artifact usually dies in a GitHub repo somewhere. Writing it up is partly documentation for myself (what worked, what I'd do differently) and partly a way of tracking how the kind of problems I'm choosing to work on has shifted — from single-model chatbots to multi-agent, multimodal, local-first systems.

If you're building anything similar — conversational video generation, on-device agent state management, or just curious about how Omni Flash and Gemma 4 play together — I'd genuinely like to compare notes. Drop a comment or find me on GitHub.

This is part of an ongoing hackathon log — you can find the earlier entries (including two first-place wins and a near-miss with a legal-aid kiosk built on a multi-agent swarm) on my blog.

I Had Never Touched a Mobile Core Network. Then I Shipped a PR to Magma's Production Codebase

Karthik Unnikrishnan — Sun, 05 Jul 2026 17:40:13 +0000

A few weeks ago I had never touched a mobile core network. I didn't know what an EPC was, what AGW stood for, or why anyone would run a 4G stack on their laptop.

Today I've deployed one, fixed a production bug in it, and shipped a PR that's now part of the codebase. Here's how that happened.

What is Magma?

Magma is a Linux Foundation Networking project — an open-source mobile core network platform that lets you deploy 4G and 5G infrastructure without expensive proprietary hardware. Think of it as the software that sits between your phone and the internet when you're on a cellular network.

I joined as a mentee with basically zero telecom knowledge. What followed was one of the most intense technical learning experiences I've had.

Deploying the stack

The first challenge was just getting the thing running. Magma's Access Gateway (AGW) runs inside Docker containers, and the setup involves coordinating a lot of moving parts — orchestration, subscriber databases, the gateway itself. Getting through that process from scratch forced me to actually understand what each component does, not just follow steps.

Finding the Ubuntu 24.04 breakage

Once the environment was running, I started auditing the Dockerfiles. The project had accumulated dependencies that silently broke on newer Ubuntu:

python3-distutils — removed in Ubuntu 24.04, so installs fail quietly
libssl1.1 — not available on 24.04, replaced by libssl3

These aren't the kind of errors that scream at you. You have to actually check whether what the Dockerfile is requesting still exists in the target OS.

The fix: 14 files, one PR

The fix wasn't just swapping package names:

Updated the subscriberdb Dockerfile to use Ubuntu 24.04 as base
Replaced deprecated packages with their 24.04 equivalents
Updated the GitHub Actions CI workflow to test against a matrix of ubuntu-20.04 and ubuntu-24.04
Traced the breakage across 14 files where OS assumptions were baked in

The CI matrix means future contributors will catch OS-specific breakage before it ships — that felt meaningful. Not just fixing something, but making it harder to break again.

What surprised me

Open-source maintenance is a lot of archaeology. Code accumulates assumptions — about the OS, about which packages exist, about the Python version installed — and nobody documents them because at the time they were obvious. Finding them means reading carefully and asking what the code expects, not just what it does.

The second surprise: telecom infra sounds intimidating, but it's just software running in containers, with logs you can read like anything else.

What's next

I recently graduated from the Magma mentorship program (spring 2026 cohort) — credential here. Continuing to contribute to Magma while going deeper on the ML side — agentic AI frameworks, research papers, and projects connecting both worlds.

Originally posted on my blog — I write about ML, systems, and open source there.

DEV Community: Karthik Unnikrishnan