AI Race Coach (Antigravity + Gemini/Gemma)

A Google Developers Blog write-up of a live demo: Google Developer Experts built a real-time AI driving coach and ran it at Sonoma Raceway (23 May 2026). The car streams telemetry; the system reads it and feeds the driver split-second advice — the pitch is that it produces coaching a driver can act on, grounded in physics, rather than the vague suggestions that lose a driver’s trust (“the AI trust gap”). Its one concrete win: the system spotted a new mid-corner throttle zone in Turn 2 worth about 0.1 s, a call that came from the telemetry, not a human coach’s intuition.

For this spoke the interesting part isn’t the racing — it’s that the piece is a worked production deployment of two things the wiki tracks from the vendor/docs side: Antigravity as an orchestration engine and ADK running a team of agents in the field. T3: a first-party Google case study, promotional in tone, with the technical specifics reported rather than independently verified.

What ran where — the edge/cloud split

The system leans on a hybrid model split rather than one model doing everything:

• Antigravity is cast here not as the developer IDE the spoke already paged, but as a “domain-bridging engine” — it “handled stateful orchestration and telemetry ingestion from the race cars,” so the engineers could work at the level of system behaviour without knowing racing. That reframes Antigravity as a runtime orchestration surface, a second face beyond its coding-IDE persona.
• ADK orchestrated “a collection of agents” doing the actual coaching functions — the spoke’s orchestrator → agents pattern, running live in production.
• Gemma 4, local, did the latency-critical work: “zero-latency, offline audio coaching alerts” computed at the edge on the device.
• The Gemini API, cloud, did the heavy, non-real-time reasoning: “complex post-session driver modeling and cloud reasoning.”

So the design routes work by latency budget and depth — cheap/fast/local for the in-the-moment alert, big/slow/cloud for the after-the-fact modelling. That is the spoke’s route-to-the-right-model idea (tokenmining, tail-control-agentic-workflows‘s downshift lever) shown in a setting where the “latency” isn’t a metaphor — the driver is mid-corner.

The rest of the stack

The reported pipeline: a Pixel 10 ingests telemetry over a custom USB interface (built by community member Brian Luc) that pulls a 10 Hz stream off the car’s hundreds of sensors; an Android app (Jetpack Compose dashboard) does real-time processing; Gemma 4 reasons at the edge; the Gemini API reasons in the cloud; and feedback reaches the driver via text-to-speech audio plus the visual dashboard. Backend telemetry processing is in Python.

Why it matters here

Two notes for the synthesis. First, it’s the first source pinning a concrete production use on Antigravity and putting ADK orchestration in the field rather than in a docs example — evidence the big-tech harness stack ships, not just demos. Second, it’s the spoke’s closest brush with the embodied / physical-agent corner flagged as a blind spot in the EvoMap taxonomy: a real-time agent reading physical-sensor telemetry and acting inside a hard latency deadline. It’s not robotics, but it’s the same edge-AI-in-the-loop shape, and it’s here mostly because the tooling (Antigravity + ADK) is the spoke’s subject.

Related

google-antigravity · adk · agent-orchestration · google · tokenmining · tail-control-agentic-workflows · awesome-agent-evolution