Inside Google DeepMind's Messy Reality of AI

Google is one of the most compute-rich organizations on earth. They own TPU clusters. They basically invented the transformer architecture that powers this whole AI moment. And yet, if one of their own engineers runs too many agents at once and spikes a cluster, someone will literally pick up the phone and call them.

I cannot stop thinking about that.

KP Sawhney — a software engineer on DeepMind's AI platform team — told an audience at an AI Engineer panel that this isn't a bug in how Google manages internal compute. It's the policy. Paying customers get priority. Googlers get deprioritized. And if a power user goes too hard? "They do just like reach out to you and say, 'Can you just like stop this job running on this one cluster, please?'" Ballantyne recalled a colleague explaining the system to him when he first joined: just use whatever you need. "How do you know when too much is too much?" his colleague replied: "Oh, they'll tell you."

The SRE team monitoring 24/7 is the rate limiter. At Google. In 2025.

I find this genuinely delightful, not because it's a failure — it's not — but because it so perfectly captures where we actually are with agentic AI versus where the marketing says we are. The production-ready agent platforms are real and advancing fast. The unglamorous reality behind them is quota caps, brute-force enforcement, and humans manually shutting down runaway jobs. Both things are true simultaneously, and the gap between them is where all the interesting engineering is happening right now.

Antigravity, and the demo that almost wasn't

The panel, featuring Sawhney and Ian Ballantyne (a developer relations engineer at Google DeepMind), opened with a live demo of Antigravity — DeepMind's internal VS Code-style IDE with a multi-agent management layer baked in. Ballantyne tried to demo it. The model errored out. He restarted. It worked on the second try, spinning up an agent that took control of a browser, inspected the DOM, rewrote a game entirely from scratch, and left behind a scratchpad of notes documenting its reasoning as it went.

It's a capable tool. The human-in-the-loop piece — where you can interrupt an agent mid-task, edit its implementation plan, and send it back with revised instructions — is the part I'd actually want to use. The gap between "agents that run autonomously" and "agents that run usefully" often comes down to exactly that feedback surface.

But the real substance of the panel was less about Antigravity the product and more about what DeepMind has learned trying to scale it across Google's thousands of engineers.

The Darwinian skills library (and why it exists)

One of the more interesting structural details Sawhney described is what they're calling a "skills" library — a shared repository of reusable agent capabilities that engineers across Google can contribute to and draw from. The idea is elegant: an expert in debugging raw logs writes a skill for it, and suddenly every engineer (and every agent) gets that expertise for free.

The catch is organizational gravity. In a company as large as Google, a shared library that anyone can contribute to tends to sprawl. Sawhney was candid about this: "There's a risk of skills really sprawling out of control... making sure that only the best ones survive, really — almost Darwinian nature." Agents using skills that other agents wrote, evaluated by... what exactly? The panel touched on this when an audience member asked about evaluation, and Sawhney acknowledged it's genuinely hard: "The trickiest part is coming up with new data sets... people are also experimenting with the agents designing that as well. So it's a little bit meta."

I love "a little bit meta" as a description for "agents evaluating whether agents are writing good tests for agents." That's not self-deprecating understatement — that's an accurate description of a genuinely unresolved research problem dressed in casual language. The multi-agent coordination challenges here are real, and DeepMind is navigating them in production, not in a lab.

Deep Research's context problem

Sawhney's current focus is rearchitecting Deep Research — the research agent that ships in the Gemini app — to stop passing "huge blobs of text" through a single giant context window and instead have different components of the pipeline collaborate through a shared file system. His framing: make each element of the system "more like a collaborator as part of a workspace... which is kind of how it would work if humans were researching something deeply."

I think this is a genuinely promising direction, and not just for the efficiency reasons Sawhney cited (though saving on context costs at Google's scale is not trivial). The bigger deal is what it unlocks architecturally. If research components can read from and write to a shared workspace rather than inheriting one giant prompt chain, you get the ability to produce real supporting artifacts — infographics, structured documents, things that require coordination between components rather than a single model trying to hold everything in its head.

Whether that architecture actually delivers on its promise depends on how well agent-to-agent communication gets solved. Sawhney was honest that this is still fuzzy territory: the current multi-agent setup isn't "a massively parallel system" so much as agents working different tracks on a project that can overlap a bit. "The future is how do we make agent-to-agent communication efficient," he said — which suggests the collaborative workspace vision is more design intent than current reality.

The assembly line thing, and why it's not a neutral metaphor

Late in the panel, Ballantyne described the coming human role in AI-heavy workflows as acting "like a supervisor on a digital assembly line." He used the phrase twice. The room received it as a forward-looking observation about workflow design.

I want to push on it a little, because I think people my age hear "digital assembly line supervisor" very differently than it might be intended. The original assembly line replaced skilled craftspeople with specialized, repetitive tasks distributed across many workers. The "supervisor" on that line wasn't elevated — they were management-adjacent labor with precarious standing. Applying that frame to knowledge workers navigating a workforce being rapidly automated is doing a lot of quiet work.

I'm not saying Ballantyne meant it that way — he clearly didn't. The tone was optimistic, almost utopian ("then we can all go sit on the beach"). But the metaphor leaks. If the future of engineering is humans providing direction, reviewing outputs, and catching failures from agents who do the actual building — what does career development look like? What does expertise accumulation look like when the thing you're supposedly supervising is faster, cheaper, and increasingly more capable than you?

These aren't rhetorical questions. They're the actual stakes underneath a panel about quota management and skills libraries.

On MCP, and institutional non-answers

When the skills vs. MCP debate came up, Sawhney was direct: he's team skills, thinks MCP might be "a flash in the pan" except for its auth model, and finds the skills-plus-CLI-guardrails combo genuinely transformative for his day-to-day work. Ballantyne, representing the platform side, said: "We support both of them, and I think that's the intention going forward... whatever you guys keep using, we'll probably still be supported."

That's the correct institutional answer for a developer relations engineer to give. It's also not really a position. What's interesting is that Sawhney — the one actually building on this stack daily — had a take. The tension between "we support everything the community uses" and "here's what actually works" is going to become more visible as the tooling landscape consolidates. Platform-layer agnosticism is a reasonable posture now; it becomes harder to maintain as certain approaches demonstrate clear advantages in production.

The quota problem nobody has solved

The underlying theme connecting all of this is resource scarcity — which should not be the dominant theme of a panel from the world's best-resourced AI lab, and yet here we are. Token quotas, per-user limits, SRE phone calls, mock TPUs for testing so you don't burn real compute evaluating whether your eval setup works. Ballantyne floated the idea that graceful model degradation — automatically falling back from Gemini Pro to Flash to a local model when you hit limits — will become standard harness behavior, so quota exhaustion stops silently killing long-running jobs.

Someone at the event mentioned, unverified, a figure suggesting GitHub is now receiving agent-generated code at a scale measured in trillions of lines. I can't confirm that number, and I'd want to before treating it as anything other than conference floor talk. But even if it's off by orders of magnitude, the direction is right: the volume of AI-generated code is outpacing the review infrastructure built to evaluate it. Agents writing code, agents reviewing code, humans supervising from above while the line keeps moving.

The SRE team will be very busy.

Yuki Okonkwo is Buzzrag's AI & Machine Learning Correspondent.