Graph Engineering with ADK

Summary

The presentation opens by addressing why single-prompt AI implementations fail and how graph engineering provides the necessary architectural fix. Using the scenario of a marathon runner requesting a race strategy, the video examines an initial single-agent approach driven by one large prompt. Although the model outputs detailed numbers regarding start conditions, elevation grades, and pacing zones with high confidence, every metric is completely hallucinated because the model has no connection to weather APIs or course databases. When every step is crammed into one model call, data cannot be fetched, tested, or trusted. Fixing this requires architectural structure rather than refined prompts.

Graph engineering represents the next evolutionary layer beyond prompt engineering, context engineering, and loop engineering. It structures workflows into nodes representing units of work and edges representing the wiring between them. Using Google's Agent Development Kit 2.0 (ADK 2.0), the presenter demonstrates a minimal two-node graph. The first node is a plain Python function that fetches weather conditions without incurring LLM token costs, while the second node is an agent that consumes those conditions to generate strategy advice in a single model call. Within ADK 2.0, functions and LLM agents operate as architectural peers using identical wiring conventions, embodying the principle that predictable work belongs in deterministic functions while reasoning belongs in models.

The workflow is then expanded to handle multiple independent data streams, specifically race weather, course elevation profiles, and runner fitness logs. Because these inputs do not depend on each other, the graph executes them concurrently through a fan-out pattern. For scenarios where the exact number of parallel tasks is unknown ahead of time, ADK 2.0 supports dynamic fan-out generated at runtime. Downstream from the parallel fetchers, a join node acts as a system synthesizer, waiting for all branches to complete before assembling their outputs into a single dictionary keyed by node name, eliminating the need to write custom aggregator agents.

To tailor advice based on race conditions, the architecture introduces a router pattern to choose among three specialist agents configured for hot, normal, or cold weather. The video contrasts two routing approaches: an LLM router, which uses model calls to classify inputs at the expense of extra tokens and non-deterministic variability, and a deterministic code router, which routes via standard conditional statements. For open-ended natural language requests lacking clear signals, an LLM router is appropriate, but for structured data over closed sets, deterministic routers are cheaper and more reliable. In the complete race strategy graph, three data fetches, a join node, a deterministic router, and a single strategy agent execute with only one LLM call.

The presentation concludes with a decision framework for selecting system architectures. If a workflow's structure can be determined prior to receiving user input, developers should implement a static graph workflow. If the workflow structure depends on runtime inputs, such as in deep research tasks, developers should deploy dynamic workflows using ADK 2.0. Fully autonomous agents should be reserved strictly for scenarios where no structured workflow can be defined in advance.