Journal / Agent SystemsField note

Choosing an agentic architecture without starting with agents

Agent count is an implementation consequence, not a starting requirement. The architecture should begin with the workload: how predictable it is, what must be orchestrated, how much iteration is useful, what latency and cost are acceptable, and where human judgement is mandatory.

Published
7 Aug 2026
Reading
9 min
Published by
Brittek Digital
In this note
  1. Begin with workload characteristics
  2. A single agent is a useful default for bounded autonomy
  3. Use simple multi-agent patterns when the workflow is already known
  4. Dynamic orchestration should pay for its own complexity
  5. Iteration needs exit conditions and control points
  6. Human-in-the-loop is an architecture pattern, not a disclaimer
  7. Source basis

Begin with workload characteristics

Google Cloud’s pattern guidance starts with task characteristics, latency and performance expectations, inference cost and the need for human involvement. That ordering matters. If a task is predictable, highly structured or can be completed with a single model call, an agentic workflow can add cost and failure modes without adding useful autonomy.

The practical question is therefore not “which multi-agent pattern should we use?” It is “what part of this workflow genuinely requires model-directed planning or tool selection?” Deterministic code should remain responsible for deterministic work.

A single agent is a useful default for bounded autonomy

For structured multi-step work that needs external tools, one agent can interpret the request, plan a sequence and select from a defined tool set. The source guidance recommends starting here when agent development is early because prompts, tools and core logic can be refined before orchestration complexity is introduced.

A single agent becomes less effective as responsibilities and tool sets grow. Warning signs include incorrect tool choice, rising latency, context overload and repeated failure to complete distinct kinds of work. Those are architectural signals to decompose responsibilities—not reasons to create a swarm by default.

Use simple multi-agent patterns when the workflow is already known

Sequential and parallel patterns are useful when the process path is predefined. Sequential composition passes output from one specialised step to the next. Parallel composition runs independent tasks concurrently to reduce elapsed time. Iterative refinement trades latency for quality by repeating generation and evaluation until an exit condition is satisfied.

These patterns can involve multiple agents without requiring a model to invent the orchestration plan. That distinction is important: specialisation does not automatically imply dynamic coordination.

  • Sequential for fixed dependencies
  • Parallel for independent work
  • Iterative refinement when quality improves through bounded repetition

Dynamic orchestration should pay for its own complexity

A coordinator pattern routes varied requests to appropriate specialists. Hierarchical task decomposition adds multiple levels of model-directed decomposition for ambiguous problems. A swarm allows specialists to exchange work more freely and iteratively converge.

Each step up this ladder adds model calls, communication paths, latency, operational cost and debugging surface. Hierarchical and swarm designs are justified when ambiguity or collaborative synthesis is itself the hard problem. They are poor substitutes for a workflow that could have been expressed explicitly.

Iteration needs exit conditions and control points

ReAct-style systems repeatedly reason about the current state, take an action and observe the result. Review-and-critique patterns add explicit validation. Loop patterns repeat a predefined action until a condition changes. These structures are useful because they make iteration an architectural element rather than an accidental behaviour.

Every loop needs a termination rule. Maximum iterations, time budgets, confidence thresholds, validation gates and error states prevent an otherwise capable agent from becoming an unbounded process.

Human-in-the-loop is an architecture pattern, not a disclaimer

For high-stakes, subjective or compliance-sensitive work, the source guidance treats human intervention as a deliberate workflow checkpoint. The agent pauses and an external interaction surface allows a person to approve, correct or add information before execution continues.

This should be designed around decision rights. Human review is most useful where a person has information, accountability or judgement the system does not—not as a generic approval step attached to every action.

Source basis

Primary source: Google Cloud Architecture Center, “Choose a design pattern for your agentic AI system”. Canonical source: https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system . Source capture reviewed 7 August 2026.

This note is an editorial synthesis. Pattern names and workload trade-offs follow the source; the recommendations about deterministic boundaries and escalation of complexity are interpretive conclusions derived from that guidance.