Graph Engineering with Google Antigravity and ADK 2.0

Google now has two agent systems that are easy to collapse into one mental model.

Do not.

Google Antigravity is a coding-agent platform with an alpha Python SDK and a fast-moving CLI. Google ADK is a general agent development framework whose 2.0 generation includes a GA graph workflow engine. Temporal is a durable execution platform that can preserve process history and recover work after failures.

They solve three different problems:

Antigravity performs bounded coding work. ADK defines the agent graph. Temporal makes the business process survive.

This is the final implementation guide in the Graph Engineering Field Guide. Read it beside the three coupled graphs model, the orchestration pattern guide and the four hard-to-reverse architecture decisions.

TLDR

• Antigravity SDK: alpha coding harness, stateful loop, tools, MCP, policies and triggers; depends on a bundled compiled runtime.
• ADK 2.0: GA workflow graph with typed nodes, validated edges, routes, fan-out/fan-in, conditional loops, retries, state and interruption.
• Temporal: durable history, deterministic replay, timers, task queues and activity recovery.
• Use ADK to model the graph, not Antigravity.
• Use Temporal when losing the process would lose business truth.
• Put Antigravity inside a bounded coding node with explicit artifacts and approval gates.

The freshness picture

Freshness is not a single score. Antigravity is current but alpha. ADK is GA but only months into a breaking 2.x architecture. Temporal is older and operationally mature. The architect's job is to map maturity to responsibility.

Antigravity: a loop behind an SDK

The Antigravity SDK README describes a three-layer Python architecture:

The useful capabilities are concrete. Agent is an async context manager. Conversation accumulates step history and turn count. ChatResponse streams text; separate streams expose thoughts and typed tool calls. Custom Python functions and MCP connections extend tools. Policies can deny, allow, ask_user or enforce. Triggers can push scheduled or file-change events into a live conversation. The official examples make the loop straightforward to embed.

The decisive boundary appears in the installation note: the SDK relies on a compiled runtime binary included in platform-specific wheels. Cloning the repository is not enough to run it. The package metadata still classifies the project as Development Status 3 — Alpha.

That does not invalidate the SDK. It changes the trust model. The open Python surface is not the whole executable runtime. You can inspect configuration, types, adapters and policy wiring while the inner loop remains coupled to a binary release. Pin wheels, record hashes, inventory supported platforms and test policy enforcement after every upgrade.

Triggers also need correct framing. They inject events into one stateful loop; they are not a durable distributed scheduler. Current trigger documentation does not promise automatic restart or ordering across failures. Use them for responsive local behavior, not for business-critical timers.

ADK 2.0: the actual graph engine

ADK 2.0 made graph structure a first-class runtime object. The official ADK 2.0 documentation marks the generation generally available, while the release page shows continued active maintenance.

The graph workflow guide defines the exact model:

The syntax can express sequential chains, parallel fan-out, fan-in and conditional branches. Conditional routes may form loops. Unconditional cycles fail validation. Compilation also checks unique node names, one START, reachability, duplicate edges, default-route constraints and compatible schemas.

That validation is not a cosmetic feature. It moves graph correctness out of a prompt and into an executable contract. An LLM can select a route by emitting an event, but the workflow defines which route names and targets are legal.

ADK's wider framework adds workflow agents, tools, sessions and runtime event processing. The 2.0 Task API adds structured agent-to-agent delegation, including multi-turn and human-in-the-loop patterns. These are agent graph primitives, not merely a coding UI.

The freshness warning is migration. ADK 2.0 changed the Agent API, Event schema and session model; BaseAgent became BaseNode, and custom legacy run overrides can bypass new behavior. Session compatibility has version boundaries. Broad exception handling can also swallow retry or interruption signals. Treat a 1.x-to-2.x move as a runtime migration, not a dependency bump.

Temporal: durability is a different contract

ADK can model loops and retries. That does not automatically make every business process durable across host loss, deployments or multi-day waits.

Temporal records a Workflow's commands and external events in an append-only Event History. On recovery, deterministic Workflow code replays that history. Side effects run as Activities with retries, timeouts and heartbeats. Child Workflows, durable timers, Signals, Queries, Updates, task queues and continue_as_new support long-lived coordination. The official architecture explanation and Python message-passing guide define these guarantees.

This is not “ADK but more enterprise.” It is a separate substrate.

Temporal's Python SDK now advertises optional integrations for agent frameworks, including Google ADK, in its package configuration. Treat any specific bridge at its documented maturity level; the underlying architectural separation remains valid even when integration code changes.

The exact adoption topology

Use this topology for a production Google agent platform:

The event sequence is equally important:

1. Temporal receives an idempotent business request.
2. A Temporal Activity invokes one bounded ADK Workflow transaction.
3. ADK compiles and validates the graph before execution.
4. ADK fans independent analysis nodes out and joins their typed outputs.
5. If coding is required, a bounded Antigravity node receives an isolated workspace, fixed base revision and tool policy.
6. Deterministic verification evaluates the returned patch or artifact.
7. ADK returns a typed decision and evidence bundle.
8. Temporal records that result, waits for approval when required and executes the consequential Activity.
9. Failures retry at the narrowest safe layer: node, activity or whole graph transaction—never all three blindly.

This topology separates three meanings of “state”: Antigravity conversation state, ADK graph state and Temporal process history. Persist identifiers between them rather than copying entire transcripts into every layer.

Practical adoption plan

Phase 1: ADK graph conformance

Implement one workflow with a deterministic node, one agent node, parallel branches, a conditional repair loop, schema validation and a human interruption. Test invalid graphs as deliberately as valid ones. Capture the exact ADK package version because 2.x is moving quickly.

Phase 2: Antigravity boundary test

Run ten isolated coding tasks through the SDK wheel. Verify read-only defaults, capability escalation, policy callbacks, MCP failure, process termination and source-to-wheel provenance. Inspect the Antigravity SDK license and deployment platforms before procurement approval.

Phase 3: Temporal envelope

Wrap one high-value workflow with an idempotency key, Activity timeout, retry policy, durable timer, Signal or Update, worker restart and deployment version test. Keep non-deterministic model/tool calls in Activities.

Phase 4: promotion gate

Promote only when traces can answer: Which business request created this run? Which ADK graph and node versions executed? Which Antigravity wheel and binary were used? Which evidence authorized the side effect? Can the process recover after each component is killed?

Use the agent observability stack to define those receipts before production traffic.

Failure drills before production

Drill 1: Antigravity binary mismatch

Deploy an unsupported or changed wheel to one worker. The node must fail closed, report its package and platform identity and avoid leaving a claimed task indefinitely.

Drill 2: Invalid ADK graph

Add an unreachable node, duplicate edge or unconditional cycle. Compilation should reject the workflow before any external tool receives authority.

Drill 3: Interrupted node with side effects

Pause for human approval after a node has prepared an external action. Resume twice. The side effect must execute once through an idempotent Temporal Activity, not once per ADK replay or resume.

Drill 4: Temporal worker loss

Kill the worker after ADK returns but before the consequential Activity completes. Temporal history should recover the process without repeating a recorded successful action.

Drill 5: Poisoned parallel branch

Return a schema-valid but evidentially weak result from one ADK branch. Fan-in must retain provenance and reject the aggregate rather than letting majority agreement substitute for proof.

Adoption decision

The strongest Google architecture is not the one with the most Google components. It is the one with the clearest ownership boundaries.

The AI Architect's call

ADK 2.0 is the strategic graph primitive here. Its Workflow, nodes, edges, routes, validation, fan-out, conditional loops, state and interruption form an inspectable execution contract. It deserves a serious pilot and can become the default graph layer for Google-native teams.

Antigravity is a different bet: an ergonomic coding loop with promising tools, policies, triggers and session primitives, delivered through an alpha SDK around a compiled runtime. Use it where that exact harness creates value. Do not promote its conversation state into business process truth.

Temporal completes the topology when work must survive. It should own time, recovery and consequential activity history. ADK should own legal agent transitions. Antigravity should own bounded coding work. Policy and humans should own irreversible authority.

Verification receipt

I inspected the Antigravity SDK README and package metadata, ADK 2.0 graph guide and release record, and Temporal’s current architecture and Python release pages. The publishing environment did not include the Antigravity wheel, ADK, or a Temporal worker, so this is a source-level architecture inspection rather than a performance run. Antigravity stays pilot, and ADK promotion remains conditional on the conformance and failure tests above.

FAQ

Is Google Antigravity the same as ADK 2.0?

No. Antigravity is a coding-agent harness with a Python SDK and CLI. ADK is a general agent framework with an explicit graph workflow engine. They can integrate, but their runtime contracts are different.

Is Antigravity fully inspectable from source?

Not end to end. The Python SDK is public and Apache-2.0, but its official README states that execution depends on a compiled runtime binary included in platform-specific wheels. A source clone alone cannot run the SDK.

Is ADK 2.0 ready to adopt?

It is GA and actively released. For new Google-native systems, pilot it with production-shaped graphs and promote after validation, retry, interruption, session migration and observability tests. Existing 1.x systems need a deliberate migration.

Does ADK replace Temporal?

No. ADK gives agents graph semantics. Temporal gives long-running processes durable event history, deterministic replay, timers, task queues and worker recovery. Use both when those responsibilities coexist.

Can Antigravity run inside an ADK graph?

Google’s official ADK Python API reference exposes the integration under google.adk.labs.antigravity, including the single-use subagent constraint. Keep the input, artifact, timeout and tool authority explicit, and retain pilot status while that labs bridge matures.

What should own the final side effect?

A deterministic policy gate and, where required, a human approval should authorize it. Execute the effect as an idempotent Temporal Activity. Neither an Antigravity conversation nor an ADK model route should silently deploy, pay or publish.