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.

In One Sentence

An agent is a software system in which a model can influence the next step toward a goal (by selecting a tool, proposing a sub-task, interpreting an observation, or deciding whether to continue) inside a runtime that still enforces schemas, permissions, budgets, and approvals.

That definition is deliberately architectural rather than promotional. It does not require a particular vendor, framework, model size, or user interface. It also leaves room for a continuum: a direct model call sits at one end, and an open-ended, tool-using loop sits at the other.

The design patterns in this article are working labels for common control loops. They are not a universal standard, and they are not mutually exclusive.

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.

The Abstraction Shift: How Software Keeps Moving Up

The shift is from application code specifying every next operation to application code creating a bounded environment in which a model may propose the next operation.

The contrast between a conventional path and an agentic path is shown in the control-loop diagram below.

The runtime may call the model repeatedly. It may provide tools, retrieve context, retain observations, and ask the model to reassess the task after each step. Some platforms host parts of this loop, such as search or code execution, inside their own runtime. The boundary still needs an owner for permissions, budgets, state, and outcomes.

That is the control-loop boundary. The model influences the path, but it should not silently own the whole system.

The model can propose the next step; the runtime still owns schemas, permissions, budgets, and approvals.

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.

What Changes Because of It?

Architecture

The architecture must represent a model-mediated decision as a first-class event. A request trace should show the goal, context version, model proposal, validation result, tool call, observation, and final outcome.

The system also needs a clear separation between proposal and execution. The model can suggest issue_refund, but the runtime owns whether that operation is available, authorized, within limits, and safe to repeat.

This separation makes it possible to replace a model, add a verifier, replay a trace, or move a task from autonomous execution to human approval without rewriting the entire application.

Engineering

Engineers need to test trajectories, not only final text. Useful tests include:

selects the correct tool when several tools are available;
stops when the goal is complete;
recovers from a transient tool failure;
does not repeat a side effect after a timeout;
refuses an unauthorized operation;
preserves important state without growing context indefinitely;
escalates when evidence is incomplete or contradictory;
produces an outcome that matches the claimed result.

The last point matters. A successful-looking final message is not proof that the environment changed. An evaluation should inspect the actual outcome: the file was changed, the refund exists, the reservation was created, or the policy gate rejected the action.

Product / UX

Users need to understand what the system is doing and where they still have authority. A progress indicator should not imply certainty. An approval prompt should explain the proposed action, scope, amount, and evidence, not merely ask “Allow agent?”

Products should also support interruption, correction, and partial completion. If the user changes the goal after three tool calls, the system should not quietly continue the old plan.

Business / Operations

Agents trade predictable latency and cost for flexibility. The trade can be worthwhile when tasks have variable step counts, meaningful tool use, and clear success criteria. It is usually a poor trade for a fixed lookup, a simple CRUD operation, or a process that must be completely reproducible.

Operational ownership also changes. Someone must own tool contracts, prompt and model changes, evaluation suites, permissions, trace retention, incident response, and the policy for when a human takes over.

Security / Governance

Model-directed flexibility turns tools, data, and state into policy surfaces. The system must separate the user’s identity from the model’s proposal, instructions from authorization, and a human approval decision from a conversational acknowledgment. Every consequential path needs an owner, an audit trail, and a way to reconstruct what the model saw and what the runtime allowed.

Failure Modes

Agent label inflation: a fixed prompt chain is called an agent, obscuring the actual control flow and making comparisons difficult.
Runaway loops: the system keeps acting because completion is vague or observations are not represented clearly.
Premature stopping: the first plausible answer is treated as completion before required evidence or checks exist.
Planner drift: the original plan becomes invalid after an observation, but executors continue following stale sub-tasks.
Bad fan-out: a planner creates too many workers, duplicate work, or subtasks that cannot be safely combined.
Self-critique theater: a reflexive pass produces more text without improving the measurable quality of the result.
Verifier correlation: the generator and verifier share the same blind spot, model, context error, or malicious instruction.
Side-effect duplication: a timeout makes the agent retry an operation that actually succeeded, creating a duplicate charge, message, or record.
Context pollution: irrelevant history, tool output, or reflective notes crowd out the evidence needed for the next decision.
Permission confusion: a tool description, retrieved page, or user message is treated as authorization.
Hidden escalation: the system asks a human only after an irreversible action instead of before it.
Outcome mismatch: the final message says the task succeeded even though the external system rejected or never completed the operation.

The pattern does not remove these failure modes. It changes where they appear and how quickly they can compound.

KNOW / UNDERSTAND / BUILD

KNOW

Recognize that an agent is a model-mediated control loop, not simply a chatbot with a new name. Know the difference between a direct model call, an iterative loop, a planner–executor design, a reflexive quality loop, and a verifier gate.

UNDERSTAND

Understand how the pattern changes control flow, state, tool use, evaluation, cost, latency, and risk. Be able to explain which decisions belong to the model and which must remain deterministic application responsibilities.

BUILD

Build a small agent only when the task has genuine uncertainty about its next step. Give it two or three narrow tools, a typed action schema, an explicit state object, a maximum step budget, a trace, and a deterministic stop condition. Add a verifier or approval gate before any meaningful side effect.

Recommended depth: UNDERSTAND

Build It Once

A useful first experiment can be implemented without a large agent framework. The important part is making the boundary visible:

state = { goal, constraints, observations, status }

while budget.allows_more_steps() and state.status != "complete":
    context = assemble_context(state, available_tools)
    proposal = model.propose(context)

    decision = runtime.validate(
        proposal,
        schema=true,
        permissions=true,
        policy=true,
        budget=true
    )

    if decision.requires_approval:
        return request_human_approval(proposal, state)

    if decision.is_final:
        return verifier.check(proposal, state)

    observation = executor.run_idempotently(decision.action)
    state = update_state(state, observation)
    trace.record(proposal, decision, observation)

return escalate_or_stop(state)

Then compare three versions of the same task:

a direct model call;
the smallest iterative loop;
the iterative loop with verification or approval.

Measure task success, tool-selection accuracy, unnecessary steps, latency, cost, recovery from errors, and unsafe proposals. The point is not to prove that the most elaborate architecture wins. It is to learn whether each added loop earns its complexity.

The durable implementation lesson is simple: let the model propose, let the runtime enforce, and let the evaluation inspect both the path and the outcome.

Will This Term Survive?

Terminology durability: Agent: HIGH but overloaded. Named patterns: MEDIUM. Underlying control-loop patterns: HIGH.

“Agent” is already a common category for model-mediated, multi-step behavior. The word is broad enough to include systems with very different levels of autonomy, so the label is less useful than the control loop it describes.

“ReAct” is a durable name for a specific research pattern: interleaving reasoning-oriented steps and actions while using observations from the environment. The broader idea may appear under other names.

“Planner–executor,” “reflexive,” and “verifier-gated” are useful descriptive labels, but their exact boundaries will vary across vendors and frameworks. The underlying decisions (decompose, adapt, critique, verify, and control side effects) are more durable than the labels.

The right unit of understanding is therefore not the name “agent.” It is the control loop and the boundary around it.

Where It Fits in the Map

The agent runtime is the decision point; orchestration and execution carry the patterns and controls around it.

This article gives the series a working definition of an agent. The next questions follow naturally: how does a model invoke a capability, what should the capability contract contain, and where does a tool call stop looking like RPC?

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.