DEV Community: Amit Maraj

Agent Factory Recap: Building with Gemini 3, AI Studio, Antigravity, and Nano Banana

Amit Maraj — Thu, 04 Jun 2026 13:04:00 +0000

Welcome back to The Agent Factory! This week, we went beyond the hype to dissect the technical details of Google's massive wave of AI releases. We were joined by Paige Bailey, the UTL for Developer Relations at DeepMind, to break down everything from the new Gemini 3 model to the Antigravity IDE.

Google has been shipping at a breakneck pace—literally a new model or feature nearly every day—and this episode is all about how developers can harness these tools right now.

This post guides you through the key ideas from our conversation. Use it to quickly recap topics or dive deeper into specific segments with links and timestamps.

The Tech Stack - What is it?

We tossed around a few new names in this episode. Here is a quick primer on the tech discussed:

Gemini 3: The latest iteration of Google's model family. While Gemini 1 was about understanding and Gemini 2 was about reasoning, Gemini 3 is designed for acting and coding. It features improved tool use and function calling.
Antigravity: Google's new AI-native IDE (Integrated Development Environment) designed to integrate Gemini 3 directly into the coding workflow, allowing for multimodal inputs like screenshots to drive code changes.
Nano Banana Pro: The newest iteration in the media generation series, capable of creating high-fidelity images, voxel art, and game assets.

The Factory Floor

The Factory Floor is our segment for getting hands-on. Here, we moved from high-level concepts to practical code with live demos.

Building "Nordic Shield" with Gemini 3

Timestamp: 11:20

Paige demonstrated the "Build" feature in AI Studio to create a complex React application from scratch. The goal was to test the model's ability to self-correct and handle specific design constraints.

The Prompt: Create an insurance cataloging app using the webcam and microphone. It needed a "Nordic/IKEA" design theme, an inventory list, and the ability to estimate item value using Google Search grounding.
The Process: Gemini 3 generated a React Native app, set up the directory structure, and wrote its own prompts for the agents.
The Result: The app, named "Nordic Shield," successfully cataloged items (like a Pixel 7 and a soda can) via video. When it encountered audio issues, it generated a reasoning trace to debug the problem live. It successfully utilized Gemini Live for the conversation and executed a secondary "agentic" step to search Google for the estimated value of the items.

Redesigning a Website with Antigravity

Timestamp: 30:27

We shifted gears to look at Google's new IDE, Antigravity. The goal was to update an existing, text-heavy website to match a new, vibrant "neo-brutalist" design aesthetic using only screenshots as a guide.

The Input: The existing codebase plus two screenshots of the desired visual style (doodly, pastel, notebook-esque).
The Implementation: Antigravity analyzed the images to understand the design philosophy. It created a task list and an implementation plan to ensure it stayed grounded.
The Outcome: The IDE successfully refactored the site to match the brand guidelines, introducing "jiggling pill" UI elements and updating the color palette to match the provided screenshots perfectly.

Paige Bailey on The Evolution of Gemini

We sat down with Paige to understand how DeepMind is approaching the rapid evolution of their models and what it means for developers building agents today.

The Three Stages of Gemini

Timestamp: 2:49

Paige outlined the clear evolutionary path of the Gemini family. She explained that the original Gemini was focused on multimodal understanding (video, text, audio). Gemini 2 introduced thinking—the ability to reason and plan step-by-step. Gemini 3, the current iteration, is all about acting. This model is optimized for acting on its reasoning, specifically through coding and tool use, allowing for composite architectures where models work together rather than in isolation.

Pre-Training vs. Post-Training

Timestamp: 4:55

We discussed the "schooling" of these models. Paige used a great analogy:

Pre-training is like sending the model to school. It involves giving Gemini access to massive amounts of tokens (internet data, synthetic data, video game footage) to learn the basics.
Post-training is "on-the-job experience." This is where DeepMind provides specific, hand-curated examples of complex workflows, such as multi-turn conversations that involve editing websites or using multiple tools to accomplish a single task.

The "Vending Bench"

Timestamp: 6:48

Benchmarks are changing. Paige introduced us to a fascinating new evaluation metric called Vending Bench. This test gauges a model's ability to run a passive business—specifically, a vending machine. The model must figure out stock, reorder items, deploy restockers, and do long-range planning to maximize uptime. The score is determined by how much profit the model generates in a year. Currently, Gemini 3 Pro is generating around $5,462 per machine, showing significant improvements in long-term strategic decision-making.

Creative Multimodality with Nano Banana

Timestamp: 28:34

We also touched on the creative side of the stack. Paige highlighted that when you combine reasoning with multimodal outputs, the possibilities explode. She shared examples of Nano Banana Pro being used to generate game assets, orthographic blueprints for 3D modeling (like castles), and detailed physics explainers. The key takeaway is the power of combining these media models with search grounding to create accurate, high-fidelity visual assets.

Conclusion

It is incredible to see not just the models, but the entire ecosystem Google is building—from the hardware to the IDEs like Antigravity. The ability to deploy these agents directly to Google Cloud with a single click bridges the gap between a cool demo and a production-ready application.

As Paige mentioned, the trajectory is exponential. Whether you are building passive businesses or complex coding agents, the tools are ready.

Your turn to build

If you haven't yet, head over to AI Studio or try out the Gemini API.

Try the "Vending Bench" challenge yourself—can you build an agent that runs a better business than Gemini 3?

Let us know what you build!

Connect with us

Amit Maraj → LinkedIn, X, TikTok
Paige Bailey → LinkedIn, X

Agent Factory Recap: Cracking Open an Open Model

Amit Maraj — Fri, 06 Feb 2026 19:10:28 +0000

Welcome back to The Agent Factory! In this episode, we’re joined by Ravin Kumar, a Research Engineer at DeepMind, to tackle one of the biggest topics in AI right now: building and training open-source agentic models. We wanted to go beyond just using agents and understand what it takes to build the entire factory line—from gathering data and supervised fine-tuning to reinforcement learning and evaluations.

Agent Industry Pulse

Timestamp: 2:00

Before diving into the deep research, we looked at the latest developments in the fast-moving world of AI agents.

Gemini 2.5 Computer Use: Google's new model can act as a virtual user, interacting with computer screens, clicking buttons, typing in forms, and scrolling. It’s a shift from agents that just know things to agents that can do tasks directly in a browser.
Vibe Coding in AI Studio: A new approach to app building where you describe the "vibe" of the application you want, and the AI handles the boilerplate. It includes an Annotation Mode to refine specific UI elements with simple instructions like "Change this to green."
DeepSeek-OCR and Context Compression: DeepSeek introduced a method that treats documents like images to understand layout, compressing 10-20 text tokens into a single visual token. This drastically improves speed and reduces cost for long-context tasks.
Google Veo 3.1 and Flow: The new update to the AI video model adds rich audio generation and powerful editing features. You can now use "Insert" to add characters or "Remove" to erase objects from existing video footage, giving creators iterative control.

Ravin Kumar on Building Open Models

We sat down with Ravin to break down the end-to-end process of creating an open model with agent capabilities. It turns out the process mirrors a traditional ML lifecycle but with significantly more complex components.

Defining Agent Data

Timestamp: 14:55
Ravin explained that training data for agents looks vastly different from standard text datasets. It starts with identifying what users actually need. The data itself is a collection of trajectories, complex examples of the model making decisions and using tools. Ravin noted that they use a mix of human-curated data and synthetic data generated by their own internal "teacher" models and APIs to create a playground for the open models to learn in.

Training Techniques: SFT and Reinforcement Learning

Timestamp: 17:14

Once the data is ready, the training process involves a two-phase approach. First comes Supervised Fine-Tuning (SFT), where frameworks update the model's weights to nudge it into new behaviors based on the examples. However, to handle generalization—new situations not in the original trainin data—they rely on Reinforcement Learning (RL). Ravin highlighted the difficulty of setting rewards in RL, warning that models are prone to "reward hacking," where they might collect intermediate rewards without ever completing the final task.

The Stakes of Evaluation

Timestamp: 20:10

Ravin emphasized that evaluation is the most critical and high-stakes part of the process. You can't just trust the training process; you need a rigorous "final exam." They use a combination of broad public benchmarks to measure general capability and specific, custom evaluations to ensure the model is safe and effective for its intended user use case.

Conclusion

This conversation with Ravin Kumar really illuminated that building open agentic models is a highly structured, rigorous process. It requires creating high-quality trajectories for data, a careful combination of supervised and reinforcement learning, and, crucially, intense evaluation.

Your turn to build

As Ravin advised, the best place to start is at the end. Before you write a single line of training code, define what success looks like by building a small, 50-example final exam for your agent. If you can't measure it, you can't improve it. We also encourage you to try mixing different approaches; for example, using a powerful API model like Gemini as a router and a specialized open-source model for specific tasks.

Check out the full episode for more details, and catch us next time!

Connect with us

Ivan Nardini → LinkedIn, X, Bsky
Amit Maraj → LinkedIn, X, TikTok
Ravin Kumar → LinkedIn

Building a Multi-Agent Deep Research Tool with Google ADK, A2A, & Cloud Run

Amit Maraj — Tue, 30 Dec 2025 03:29:32 +0000

"Research" is a loaded word. It’s not just Googling a keyword. It’s reading papers, verifying facts, finding that one perfect diagram, and synthesizing it all into something coherent.

Asking a single AI agent to do all of that sequentially is not very efficient. They’ll hallucinate, they’ll get stuck, and they’ll definitely be slow.

(TL;DR: Want the code? Check out the Deep Research Agent code on GitHub.)

I wanted a system that could take a topic—say, "The History of Recurrent Neural Networks"—and produce a comprehensive, illustrated report. Additionally, I wanted to learn how to build a Deep Research Tool from scratch.

The first attempt? A single loop. It researched, then it looked for images, then it checked its work. It took forever.

So I asked: Can I make this faster?

In this post, we’re going to build a Parallel Research Squad. Instead of one agent doing everything, we’ll spin up three specialized agents that run simultaneously, coordinated by a central Orchestrator. We’ll use Google’s Agent Development Kit (ADK) for the brains, the Agent-to-Agent (A2A) Protocol for communication, and Google's Cloud Run to let them scale infinitely.

Part 1: Agentic Design Patterns

We aren't just writing prompts anymore; we are doing System Engineering. To build a robust system, we leverage three key design patterns:

1. The Orchestrator Pattern

Instead of a "God Agent" that decides everything, we have a central Orchestrator. Think of it as the Editor-in-Chief. It doesn't write the articles; it assigns stories to reporters. It manages the state, handles errors, and ensures the final product meets the deadline.

2. Parallelization

This is our speed hack. Most agent frameworks run sequentially (Step A -> Step B -> Step C). But "Reading Arxiv Papers" and "Searching for Images" are independent tasks. By running them in parallel, we reduce the total latency to the duration of the slowest task, not the sum of all tasks.

3. The Evaluator-Optimizer

We don't trust the first draft. Our system includes a Judge agent. The Orchestrator sends the research to the Judge, who returns a strict Pass/Fail grade with feedback. If it fails, the Orchestrator loops back (Optimizer) to fix the gaps.

Part 2: The Need for Speed (Parallel Execution)

The biggest bottleneck in AI agents is latency. Waiting for a model to "think" and browse the web takes time.

With ADK, we implement a ParallelAgent. This isn't just a concept; it's a primitive in the framework that handles the async complexity for us. ParallelAgents run in parallel, and the Orchestrator waits for all of them to finish before moving on. This is a simple way to parallelize your agents and improve performance within agents that don't depend on each other.

# orchestrator/app/agent.py
from google.adk.agents import ParallelAgent

# The "Squad" runs together
research_squad = ParallelAgent(
    name="research_squad",
    description="Runs the researcher, academic scholar, and asset gatherer in parallel.",
    sub_agents=[researcher, academic_scholar, asset_gatherer],
)

This one change cut our total processing time by 60%. While the Scholar is reading a dense PDF, the Asset Gatherer is already validating image URLs.

Part 3: The Universal Language (A2A Protocol)

How do these agents talk? They are separate microservices. The Researcher might be on a high-memory instance, while the Orchestrator is on a tiny one.

We use the Agent-to-Agent (A2A) Protocol. It’s like a standardized API for AI agents, built on top of JSON-RPC.

Why A2A?

Decoupling: The Orchestrator doesn't need to know how the Researcher works, just where it is.
Interoperability: You could write the Researcher in Python and the Judge in Go. As long as they speak A2A, they can collaborate.
Service Discovery: In development, we map agents to localhost ports. In production, we map them to Cloud Run URLs.

# orchestrator/app/agent.py
from google.adk.agents.remote_a2a_agent import RemoteA2aAgent

# The Orchestrator calls the remote Scholar service
academic_scholar = RemoteA2aAgent(
    name="academic_scholar",
    # In prod, this is an internal Cloud Run URL
    agent_card="http://scholar-service:8000/.well-known/agent.json",
    description="Searches for academic papers."
)

Part 4: Infrastructure as a Superpower (Cloud Run)

We deploy this system on Google Cloud Run. This gives us the "Grocery Store" scaling model.

The "Grocery Store" Model

Imagine a grocery store with one checkout lane. If 50 people show up, the line goes out the door.
In our system, each agent is a checkout lane.

Monolith: One lane. 50 requests = 50x wait time.
Microservices on Cloud Run: 50 requests = Cloud Run instantly spins up 50 instances of the Researcher. Everyone gets checked out at once.

Scale to Zero

When no one is using the app, we have 0 instances running. We pay $0. This is crucial for cost-effective AI applications. Note, when a Cloud Run service is not in service, it is automatically scaled to zero, which means that it will require a cold start when the next request comes in. You can keep your Cloud Run services warm by using a health check.

Part 5: The Frontend (Next.js + Real-Time)

We didn't want a CLI tool. We wanted a product.

We built a Next.js frontend that connects to the Orchestrator. Because we know the architecture, we can visualize it. When the research_squad starts, our frontend shows three pulsing indicators side-by-side. You actually see the parallelism happening.

It creates a sense of "liveness" and transparency that builds user trust.

Conclusion

By breaking our monolith into a Parallel Research Squad, we built a system that is:

Faster: Parallel execution cuts wait times by >50%.
Better: Specialized agents (Scholar, Gatherer) do deeper work than one generalist.
Scalable: Microservices on Cloud Run handle infinite load.

Want to build this yourself?