Put reasoning at the workflow's uncertain decisions

TL;DR: This ADK workshop develops an agent from a large prompt toward tools and explicit workflow control. My design rule is to reserve model reasoning for decisions that need interpretation. Fixed calculations and required sequencing should have an implementation whose behaviour can be checked directly.

The recording is useful for engineers whose agent prompt contains both judgment and a long list of mechanical instructions. A race-planning example exposes the limitations of asking one model call to supply information, calculate results and follow a process. The workshop then introduces tools and different orchestration shapes. Saved workshop.

Around 15:00, the speaker discusses the difficulty of relying on a prompt for an exact sequence. Around 25:30, the example adds tools for external information and deterministic logic. Around 29:30, the slides distinguish sequential, parallel and loop arrangements. I inspected these transcript sections and representative code and diagram frames, not every minute of the workshop.

Decide what should be allowed to vary

For a hypothetical document workflow, I would let a model interpret which passage answers a question and explain an ambiguous exception. I would not ask it to improvise the rules for joining records, checking required fields or calculating a known total.

Those operations can be expressed with ordinary code and explicit inputs. If the same input should always receive the same validation result, the implementation should make that expectation inspectable. The model can still help write the code, but the running workflow does not need to reason the rule out afresh.

I would also put prerequisites in control flow. A step that requires a validated identifier should not execute because the assistant narrates that validation probably succeeded. It should receive the validated value or a failure result from the preceding component.

This is an illustrative design, not a benchmark comparing ADK with other frameworks. Deterministic code can contain bugs, and explicit sequencing does not solve every reliability problem. It gives the team a smaller, clearer place to test each obligation.

Keep the uncertain decision visible

Once the mechanical work is separated, the model's judgment becomes easier to evaluate. The test can ask whether it chose the right interpretation given the supplied evidence, rather than whether it also remembered arithmetic and process rules in the same response.

For the document example, I would keep a case with two plausible passages and an unresolved conflict. The model should expose that conflict or select a defined escalation path. A neatly completed output is not success if the uncertainty was silently discarded.

The recording spans versioned ADK material, and the exact original workshop upload remains unresolved. I would check current documentation before copying any API or code shown. The transferable part is the division of responsibilities, not a claim that one orchestration version makes all previous approaches obsolete.

Sketch one workflow before adding another agent. Mark the steps that should be exact and the decisions that can legitimately depend on interpretation. That drawing tells you where model reasoning is buying something.

Use code to carry known obligations and model reasoning to handle the uncertainty that remains.