Skip to lesson

Google CloudProfessional Agentic Architect2026-090 Prerequisites

Separate workflow control from model decisions

Completed by the knowledge check

Learning objective

Separate deterministic workflow control from model-directed decisions. This lesson focuses on deciding where each kind of control belongs, not on selecting a specific orchestration product.

Core idea

Use code to enforce what must happen, and use a model to choose what could happen when the choice depends on language or incomplete information.

Deterministic control follows explicit rules: the same relevant state produces the same permitted transition. Model-directed control interprets context and selects a likely next action. It is useful but probabilistic. A reliable agentic system combines them: the model proposes within a bounded choice set, while the workflow validates and executes.

How it works

Classify each decision by its consequence and by whether it can be expressed as a test.

Keep a decision in deterministic control when it involves:

  • authorization, data residency, or another hard policy;
  • a required order, such as validate before charge;
  • deadlines, retry counts, quotas, or iteration limits;
  • transaction state, idempotency, or exactly-once business intent;
  • schema validation and required approvals;
  • routing based on known structured fields.

Use a model-directed decision when it involves:

  • interpreting a natural-language request;
  • classifying ambiguous intent;
  • selecting among safe tools based on semantic fit;
  • decomposing an open-ended task;
  • judging whether evidence is relevant or an answer is adequately supported.

The boundary should follow a proposal–validation–execution pattern:

  1. The controller builds the allowed action set from policy and current state.
  2. The model proposes an action and structured arguments from that set.
  3. Deterministic code validates the proposal, authorization, budget, and current preconditions.
  4. The controller executes or rejects the action and records the transition.
  5. The model receives the result only if another semantic decision is needed.

Google’s Agent Development Kit (ADK) reflects this split. Its workflow agents control subagent execution through sequential, parallel, and loop patterns without using a large language model for the orchestration itself. In contrast, LLM agents use a model for dynamic reasoning and tool use.

Deterministic does not mean inflexible or entirely static. A rules engine may read configuration, policy, and state at runtime. The important property is that its transition can be tested and explained from those inputs. Likewise, model-directed does not mean uncontrolled: the model can choose only among capabilities that the controller exposes.

Key distinctions and trade-offs

Business workflow versus reasoning strategy: A refund workflow might require identity verification, eligibility checking, approval, and payment in that order. The model may decide how to interpret the request or what evidence to gather, but it should not reorder the required business states.

Routing versus authorization: A model can recommend the tool that best matches the request. Authorization determines whether the caller may use that tool on the target resource. A routing choice never grants permission.

Flexible versus nondeterministic: A deterministic graph can have many branches. It remains deterministic when explicit conditions select the branch. A model can also produce a repeatable answer in one test, but that observation is not a hard guarantee.

Explicit workflows cost more engineering effort and can become cumbersome for unstructured tasks. Model-directed routing adapts to varied language and new combinations of work, but it needs evaluation, fallbacks, and tighter limits as consequences increase. Choose the narrowest model decision that provides useful flexibility.

Architecture / decision scenario

A purchasing assistant receives: “Replace the broken design workstation this week.” A model extracts the requested category, urgency, and business reason. It selects a catalog-search tool and compares suitable products.

The purchase workflow remains explicit. Code verifies the employee, checks the department budget, routes purchases above the configured amount to a manager, and creates the order only after approval. The model may summarize the comparison for the manager, but it cannot bypass the approval state or raise its own spending limit.

This split preserves conversational flexibility while making the financially consequential path testable. If policy changes, the team updates the workflow rule instead of hoping revised instructions produce the required behavior.

Common exam traps

  • Assuming an instruction such as “always ask for approval” enforces a hard control. Put the approval gate in deterministic execution logic.
  • Using a model to evaluate conditions that already exist as trusted structured fields.
  • Treating deterministic orchestration as a workflow with no branches.
  • Treating a model’s tool selection as authorization to execute the tool.
  • Placing every choice in code and losing the semantic flexibility that makes an agent useful.
  • Placing the entire workflow in the prompt, which makes state transitions hard to test, audit, and recover.

What to remember

  • Code enforces invariants; models interpret ambiguity.
  • Let the model propose and let deterministic controls validate and execute.
  • Keep policy, approvals, budgets, and required ordering outside probabilistic model behavior.
  • A dynamic rule engine can still be deterministic.
  • Increase explicit control as the consequence of a wrong action increases.

Knowledge check

References