Agent and Agent Design Patterns

When a Model Becomes a Control Loop

The important question is not whether a system is called an agent. It is whether a model can influence what happens next, and what keeps that influence within safe, testable boundaries.

This is Post 02 in The Abstraction Shift: How Software Keeps Moving Up.

Two questions guide this article: When does a model become an agent, and which control-loop pattern is it using?

A model becomes meaningfully agentic when it can select or revise the next step at runtime. The pattern depends on how that loop handles action, observation, planning, refinement, and verification.

Why This Exists

A model can answer a question in one invocation. Many useful applications need more than an answer.

They need to find an account, inspect a policy, compare several documents, write a file, run a test, ask for approval, or recover from an error. The number and order of those steps may depend on what the system discovers along the way.

Before models could participate in application control flow, engineers usually represented that sequence explicitly. A workflow engine, service method, scheduler, or state machine selected the next operation. A model might produce content inside one of those steps, but it was not normally responsible for choosing the next capability from a semantic goal.

The agent label appeared as applications began placing the model closer to that decision point. The model could interpret a goal, choose among tools, generate arguments, react to results, and decide that another step was necessary.

This created a new vocabulary:

Agent describes the broader system or runtime.
ReAct describes an interleaved reason-orient-and-act loop.
Planner–executor describes a split between decomposition and execution.
Reflexive describes a draft, critique, and refinement loop.
Verifier-gated describes an independent check before an output or action is released.

The vocabulary is useful only if it helps us choose architecture. If it merely makes a fixed workflow sound autonomous, it is adding marketing language rather than engineering clarity.

What We Did Before

Agents have a long lineage.

Procedures and APIs

Traditional software exposes operations through functions, services, APIs, and RPC. A caller supplies structured arguments, the operation runs, and a result comes back.

The contract is explicit. The caller is usually selected by code written before the request arrives.

State machines and workflow engines

Workflow systems represent a process as states, transitions, retries, timers, approvals, and failure paths. They are good at making the allowable sequence visible and repeatable.

They can be dynamic in the ordinary software sense. A transition may depend on a database value, a queue event, or a business rule. The important point is that the transition logic is still defined by the system rather than inferred from a natural-language goal at runtime.

Planners and schedulers

Planning systems have long decomposed goals into sub-goals, allocated work, and ordered operations. Schedulers then assigned those operations to workers or resources.

The planner may be symbolic, optimization-based, heuristic, or probabilistic. None of this began with language models.

Feedback and control loops

A controller observes a system, compares the state with a desired condition, and adjusts its next action. Robotics, process control, operating systems, and distributed systems all use versions of this idea.

The old systems already had goals, state, observations, actions, retries, and stopping conditions. The new ingredient is that a model can help interpret the goal and propose the next operation using natural-language context and learned generalization.

Agent patterns are composable control-loop choices, not mutually exclusive types or guarantees of correctness.

What’s Actually New?

Four changes matter more than the label.

1. Control flow can be generated at runtime

The system no longer needs to know the exact sequence of steps before the request arrives. A model can infer that a request requires a search, a database lookup, a calculation, or a human decision.

This makes the application more flexible. It also means that the same input may produce different execution paths, especially when the model sees different context, tool results, or model versions.

2. Natural-language goals become operational inputs

The system can accept a goal such as “prepare a recommendation from these sources” rather than requiring the caller to name every API operation in advance.

That is not the same as understanding the goal perfectly. It means the model can translate a semantic request into a proposed sequence of structured operations. The translation is now part of the system’s behavior and must be evaluated.

3. Observations become part of the next decision

An agent does not only generate an answer. It receives information from the environment: a search result, a database row, a test failure, a permission denial, or a human correction.

That observation becomes new context or state. The next decision depends on the path already taken. This creates feedback, but it also creates the possibility of compounding errors.

4. Control-loop design becomes an explicit choice

“Build an agent” is too vague to guide architecture. A direct model call, an iterative tool loop, a planner with workers, a critique-and-refine cycle, and a verification gate have different cost, latency, observability, and failure characteristics.

The first architecture decision should therefore be the smallest control loop that can handle the task.

Where the Analogy Breaks

The historical analogies are useful, but each stops somewhere.

An agent is not a person in software

The word suggests autonomy, intention, and independent judgment. A production agent is a runtime with model calls, context, tools, state, policies, and stopping conditions. It does not have a human-like objective outside the one represented by its inputs and constraints.

Calling a system autonomous does not remove the need to specify what it may do, what it must not do, and when it must stop.

An agent is not simply a workflow with a more interesting name

A workflow can contain model calls and still be a workflow if the application defines the path in advance. An agent becomes meaningfully different when the model can select or revise the next step at runtime.

The distinction is a continuum, not a court ruling. Many production systems combine fixed workflow stages with model-directed loops inside one stage.

A tool call is not a safe action

The model may produce a valid function name and valid JSON while still choosing the wrong operation, using stale context, or acting on an untrusted instruction.

Schema validation answers “is this shaped like a permitted request?” It does not answer “should this request happen now?” Authorization, policy, idempotency, rate limits, and human approval remain application responsibilities.

Memory is not learning

An agent can retain conversation history, task state, summaries, retrieved facts, or reflective notes. That gives the system more context on a later step or later trial.

It does not necessarily update the model’s weights or acquire a reliable new capability. A memory can be wrong, stale, irrelevant, or manipulated. “The agent remembers” is not the same as “the model learned.”

A verifier is not a proof

A second model can catch errors that the first misses, and a deterministic rule can enforce a narrow constraint. Neither one makes an arbitrary output correct.

An independent verifier should have a meaningfully different failure mode where possible: a database constraint, a unit test, a policy engine, a typed parser, a separate model, or a human decision. Repeating the same model call with a different prompt may add diversity, but it should not automatically be called independent verification.

Under the Hood

A useful agent runtime has at least seven responsibilities:

Goal and constraints: represent the user’s request, task scope, permissions, and budget.
Context assembly: provide the model with relevant history, tool descriptions, retrieved material, and current state.
Proposal generation: ask the model for an answer, tool call, sub-task, clarification, or stop decision.
Deterministic validation: check schema, authorization, policy, cost, rate limits, and required approvals.
Execution: run the approved operation with timeouts, isolation, idempotency, and error handling.
Observation and state update: record the result, update the task state, and preserve the trace.
Evaluation and termination: decide whether the goal is complete, another step is worthwhile, or a human should take over.

The agent pattern determines how the proposal and evaluation stages interact:

Pattern	The model or system decides	Best fit	Main risk
Single-shot	Produce one answer or proposal	Bounded, low-risk requests	The answer lacks needed evidence or action
Iterative / ReAct	Choose the next action from observations	Unknown step count; tool use	Runaway loops and compounding errors
Planner–executor	Decompose the goal and allocate sub-tasks	Complex, separable work	Stale plans, coordination overhead, bad fan-out
Reflexive	Critique and improve a draft	Clear quality criteria	Self-critique can reinforce the same mistake
Verifier-gated	Permit or reject release of an output/action	High-risk boundaries	Correlated or incomplete verification

These patterns compose. A planner can create several ReAct executors. A reflexive pass can improve a draft after retrieval. A verifier can gate the final action regardless of how the result was produced.

The cross-cutting shell matters as much as the loop:

State keeps the current task, observations, approvals, and evidence coherent.
Tracing records proposals, tool calls, results, retries, latency, and cost.
Guardrails constrain instructions, capabilities, data access, and side effects.
Human approval provides a deliberate boundary when the cost of a wrong action is high.
Budgets cap steps, elapsed time, context, tokens, tool calls, and money.

A Concrete Example

Consider a support request:

“Please refund my order if it qualifies under the policy.”

The same user-facing request can produce several architectures.

Single-shot baseline

If the application already has the order, the policy, and the required facts in structured form, a model can classify the request and return a proposed decision. A deterministic policy engine can then evaluate eligibility.

This is not necessarily an agent. It may be a model-assisted decision step inside a conventional workflow, and that may be exactly the right design.

Iterative / ReAct

If the facts are spread across systems, the model may need to retrieve the order, inspect shipment status, check the applicable policy, and ask for missing information. The runtime can return each result to the next model step.

The loop needs a maximum number of steps, a narrow tool set, and a rule for what happens when the facts conflict. “Keep looking until satisfied” is not a production stopping condition.

Planner–executor

For a complex case involving several line items, a planner might split the task into order verification, policy analysis, shipping status, and refund calculation. Executors can handle independent subtasks and return structured results for aggregation.

The planner should not be allowed to invent permissions through decomposition. Each executor still operates within the same authorization and data-access boundaries.

Reflexive pass

After eligibility is established, a draft response can be checked for clarity, missing conditions, or contradictory explanations. The critic should use explicit criteria such as “states the policy basis,” “does not disclose internal signals,” and “clearly explains the next step.”

The reflexive pass improves communication. It should not be treated as the authority that approves the refund.

Verifier gate

Before the side effect, a verifier can check that the order ID, amount, policy result, currency, and idempotency key match. A larger refund or an exception can require human approval.

The final action then follows the governed path shown below.

A coherent proposal still passes through typed, authorized, verified, and repeat-safe execution steps.

The model may participate in every step. It should not own the final authority merely because it proposed a coherent explanation.

Choose the smallest pattern that handles the task’s uncertainty and risk; add a verification gate for high-impact side effects.

Failure Modes

Agent label inflation: a fixed workflow is called an agent, hiding the actual control flow and its limits.
Runaway or stale planning: the system loops, follows an invalid plan, or keeps executing after an observation changes the task.
Bad fan-out: a planner creates duplicate work or subtasks that cannot be safely combined.
Verifier correlation: the generator and verifier share the same blind spot, context error, or malicious instruction.
Side-effect duplication: an uncertain timeout causes an operation that already succeeded to run again.
Permission and outcome confusion: a description is treated as authorization, or the final message claims success without a verified external state.

Explicit state, bounded control flow, idempotency, authorization, and outcome checks remain necessary in every pattern.

Sources

Building effective agents, Anthropic: distinguishes predefined workflows from agents and describes common composable patterns including orchestrator–workers and evaluator–optimizer.
ReAct: Synergizing Reasoning and Acting in Language Models: introduces the research pattern of interleaving reasoning-oriented steps and actions while using environmental observations.
Reflexion: Language Agents with Verbal Reinforcement Learning: describes using verbal feedback and reflective memory across trials; related to, but more specific than, the reflexive pattern used here.
Demystifying evals for AI agents, Anthropic: explains why multi-turn agent evaluation must consider traces, graders, and the actual outcome in the environment.