Forem: Amit Maraj

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?