Skip to lesson

Google CloudProfessional Agentic Architect2026-093.3 Orchestrating and coordinating agentic workflows

Choose dynamic routing or explicit orchestration

Completed by the knowledge check

Learning objective

Choose model-driven dynamic routing or explicit orchestration according to how predictable, repeatable, and enforceable the workflow path must be. This lesson focuses on who selects the next step, not on the internal reasoning of each agent.

Core idea

Treat control-flow authority as a determinism budget. Give a model authority to choose the next specialist only where semantic flexibility is worth the risk of a variable route. Keep authority in code or a declared workflow where the same validated facts must activate the same path.

This boundary is more precise than choosing between “agentic” and “deterministic” systems. An explicitly orchestrated workflow can contain models inside its steps. A model-driven coordinator can also be limited to a declared set of destinations. The key question is: Does a model interpretation or an explicit rule select the next transition?

Google Cloud describes the coordinator pattern as a central agent that uses an AI model to decompose requests and dynamically route tasks. The same guidance classifies predefined sequential and parallel patterns as deterministic workflows that don’t require model orchestration.

How it works

Use model-driven routing for semantic uncertainty

A model-driven router reads the request and available context, then selects or creates the next task at runtime. In Agent Development Kit (ADK), an LlmAgent can generate a transfer_to_agent function call. ADK then switches execution to the selected agent. Clear coordinator instructions and distinct subagent descriptions help the model choose among them, as described in ADK’s delegation guidance.

Choose this approach when:

  • the input is varied, ambiguous natural language;
  • the relevant specialist cannot be selected reliably with stable business rules;
  • useful task decomposition depends on meaning discovered at runtime; and
  • a wrong or uncertain route is detectable and recoverable.

Dynamic routing buys adaptability. It also adds a model call, latency, token cost, and another behavior to evaluate. More importantly, the same request can take a different route after prompt, model, context, or sampling changes. Vertex AI states that even a fixed seed makes a best effort rather than a guarantee of deterministic model output.

Use explicit orchestration for required paths

Explicit orchestration uses code, rules, or declared graph edges to select the next step. Choose it when:

  • policy maps validated facts to one required path;
  • ordering, mandatory checks, approvals, or joins are correctness conditions;
  • an audit must explain the route from recorded inputs and rule versions;
  • a misroute could cause financial, security, legal, or irreversible impact; or
  • tests must assert the exact transition for each case.

Explicit control improves route predictability and usually avoids coordinator model calls. Its cost is maintenance: developers must enumerate routes and update the workflow as requirements change. Google Cloud’s custom logic pattern uses code for complex branching when fine-grained execution control is needed.

Combine both at a controlled boundary

Many production systems need semantic understanding at intake but strict control before side effects. Use a model to produce a small routing decision, then let deterministic code validate and apply it:

  1. Define an allowlist such as ORDER_STATUS, RETURN, REFUND, and UNKNOWN.
  2. Ask the model for one value and the structured fields needed downstream.
  3. Validate the response against a schema and reject missing or unknown values.
  4. Map the valid value to a declared specialist or graph edge in code.
  5. Send ambiguity and policy exceptions to a safe fallback, such as human review.
  6. Record the input, route value, selected destination, and model and prompt versions for evaluation.

A response schema can make the output conform to a defined JSON structure, as shown in Vertex AI’s controlled-generation sample. It does not prove that the selected route is semantically correct. Test the router on representative, ambiguous, and adversarial inputs, and monitor misroutes separately from specialist answer quality.

Key distinctions and trade-offs

QuestionModel-driven dynamic routingExplicit orchestration
Who chooses the next step?A model interprets context at runtime.Code, rules, or declared edges evaluate known state.
Best fitVaried inputs and semantic ambiguityStable policy and required transitions
Main benefitFlexibility without enumerating every phrasingRepeatable, testable, auditable paths
Main riskMisrouting and behavior driftRigidity and growing rule complexity
Typical costExtra inference latency and tokensMore workflow implementation and maintenance

“Explicit” does not mean that outputs are deterministic. A graph can always invoke a generative agent inside a node. Conversely, “dynamic” does not mean that every agent can call every other agent. Constrain destinations, permissions, budgets, and termination even when a model chooses the route.

Architecture / decision scenario

A retailer receives support requests phrased in many languages and styles. Customers ask for order status, returns, refunds, and sometimes several things in one message. A model-driven coordinator is useful at intake because the route depends on semantic intent, not a stable field supplied by the customer.

The team does not let that coordinator approve a refund. It returns an allowlisted intent and extracted identifiers. Code validates the result and invokes the declared specialist. An UNKNOWN or multi-intent result goes to a clarification path. Inside the refund path, explicit rules require identity verification, order lookup, eligibility evaluation, and approval before the payment API can run.

This hybrid places flexibility where a misroute can be corrected and determinism where a transition authorizes money movement. Making the whole process model-driven would weaken enforcement and auditability. Hardcoding the initial intent route would create a large, brittle set of language rules.

Common exam traps

  • Choosing a model coordinator merely because a workflow has several agents.
  • Treating low temperature or a fixed seed as guaranteed deterministic routing.
  • Assuming a structured route value is necessarily the correct route.
  • Using model judgment for a branch already determined by policy or typed data.
  • Assuming explicit control flow makes model-generated node outputs deterministic.
  • Giving a dynamic router unrestricted destinations, permissions, or retries.
  • Forcing ambiguous inputs down a route instead of defining an UNKNOWN, clarification, or human-review path.

What to remember

  • Put route authority in code when the same validated facts must produce the same path.
  • Use a model router when semantic judgment is necessary and misroutes are recoverable.
  • Separate deterministic control flow from the variability of work inside a step.
  • Constrain model routes with allowlists, schemas, validation, and safe fallbacks.
  • Evaluate routing accuracy and drift, not only final-answer quality.

Knowledge check

References