Use code for control flow, agents for reasoning

Canonical version: Use code for control flow, agents for reasoning.

Give deterministic code everything it can handle (routing, scheduling, data transformation, file writes), and reserve the Large Language Models (LLMs) for the parts that need judgment (interpreting ambiguous, unstructured input).

Why it works:

• Reliability — code doesn't hallucinate a branch or loop forever. The failure modes that kill agent prototypes in production are mostly orchestration failures, not reasoning failures.
• Security — fixed execution boundaries blunt Prompt injection: injected instructions can't impact execution paths that aren't in the graph.
• Cost and latency — every decision you move out of the model is tokens you stop paying for.
• Context hygiene — passing only necessary data between steps prevents context bloat, the quiet killer described in Agentic Context Management and Orchestrator tax.

Independent implementations keep converging on it. ADK 2.0 built its whole workflow runtime around it. Gray Box applies it to PKM: the LLM extracts entities, deterministic Python writes the files. My own skills follow the same split: CLI commands and scripts do the heavy lifting; the model does the interpretation.

If the logic can be written down as rules in advance, it's a workflow step. If it requires reading something messy and deciding what it means, it's an agent step. Most systems need both. This sharpens the Distinction between AI Agents and Automation Workflows: the answer to "agent or workflow?" is usually a workflow that CONTAINS agents, not an agent that improvises a workflow.

References

• Why we built ADK 2.0 (Google): https://developers.googleblog.com/why-we-built-adk-20

Related

• Google Agent Development Kit (ADK)
• Distinction between AI Agents and Automation Workflows
• Gray Box
• Agentic Context Management
• Orchestrator tax
• Prompt injection
• LangGraph
• Faster coding shifts the bottleneck to the outer loop

About Sébastien

Ready to get to the next level?