18.2 Workflows and Agents: Tools, Loops, and Permission Boundaries

A fixed workflow is determined by code; an Agent lets the model dynamically choose the next step based on goals and environmental feedback. The latter is well-suited for tasks where paths can't be enumerated in advance, but it increases latency, cost, and unpredictability.

Start with the simplest structure that meets the task: a single model call, retrieval augmentation, a fixed chain, or a branching workflow. Use evaluation results to decide whether an open loop earns its additional complexity.

Common Workflows

Prompt chaining

Chain tasks that are clearly decomposable and add programmatic checks in between:

Extract facts → schema validation → draft generation → citation check

Routing

First categorize, then hand off to dedicated prompts, tools, or models. Evaluate misrouting costs separately and provide fallbacks for low confidence.

Parallelization

Independent subtasks can be processed in parallel and then aggregated; multiple samples from the same task can be used for candidate comparison. Additional calls are only worthwhile if they genuinely improve the target metric.

Evaluator–optimizer

The generator revises its output using explicit criteria. Maximum iteration limits and stopping conditions must be set to avoid treating "the evaluator can still provide feedback" as a justification for endless improvement.

An Agent is a controlled loop

Runtime in concept:

Goal + Current State
      ↓
Model chooses an answer or a tool call
      ↓
Policy check / Approval when required
      ↓
Run the tool and document the observations
└──────────→ Next round

The ReAct paper demonstrates a paradigm of alternating reasoning and action. In engineering implementation, it's not necessary to expose or permanently store the model's private reasoning traces; instead, preserve only necessary, auditable plan summaries, redacted tool arguments and results, approval records, and final artifacts.

Loops must have an exit condition: success, explicit failure, user input required, insufficient permissions, reaching a step/time/cost budget, or no progress for consecutive iterations. Confirm success against the intended artifact or authoritative state; the model choosing to say "done" is not sufficient.

Tool definitions determine the agent's capability boundaries

Tools should have:

• Distinct purposes, clear parameter schemas, and preconditions;
• Structured return values and categorizable errors;
• Minimum permissions and caller identity propagation;
• Idempotency keys or queryable operation status;
• Timeout, rate limiting, and audit logs;
• A mechanism that considers existing authorization and action risk before requiring additional approval.

Unrestricted SQL execution or arbitrary URL access grants broad authority. Narrow tools such as getOrder(id) and requestRefund(orderId, amount, reason) let application code enforce authorization, limits, and invariants.

A proposed tool call is not authorization. The server must check the user, tenant, resource, and action. When approval is required, bind it to the exact resource, arguments, permission scope, and expiry. Changing the amount from 100 to 1000 after approval creates a different action.

For a refund, persist the operation ID and intent before execution, then record the tool receipt. If the refund succeeds but the process crashes before recording the receipt, recovery must query or retry idempotently with that same ID. Generating a fresh ID can repeat the financial action. Persisting chat messages alone does not provide recoverable execution.

Prompt Injection is a control flow attack

Text in web pages, emails, and retrieved documents might require the Agent to disclose secrets or invoke tools. External content is data, not trustworthy system instructions.

Protection requires a layered approach:

• Clearly separate trusted instructions from untrusted content;
• Apply least privilege and parameter validation to tools;
• For high-risk actions needing new authorization, show the actual parameters during confirmation;
• Don't include unnecessary keys in the model context;
• Tiered authorization for capabilities such as reading, writing, sending, and paying;
• Continuously validate with adversarial testing, rather than relying on a single statement like "ignore malicious instructions."

State, memory, and context are not synonyms

• Run state: Current step, tool results, approval, and budget;
• Session context: information provided to the model for this interaction;
• Long-term memory: information retained and retrievable across conversations;
• Business Truth: Official system records such as orders, permissions, and balances.

Long-term memory needs sources, scope, update and deletion mechanisms, and privacy policies. Resuming a run also requires checking whether saved approvals expired or user permissions changed. Yesterday's context is not today's access pass. Summaries generated by a model cannot automatically become business truth.

Use multiple agents only when responsibilities are clearly defined

Adding more Agents increases handoffs, context loss, loops, and evaluation combinations. Signals that warrant splitting are different tool permissions, domain-specific instructions, or distinct result ownership, not "the more roles, the smarter."

Whether using handoff or treating the Agent as a tool call, always clarify: who owns the final answer, who can execute side effects, and where control returns upon failure.

The next lesson establishes evaluation and runtime governance, enabling quantitative comparison of model, prompt, retriever, or tool changes.

References

• Anthropic, Building effective agents
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models
• OpenAI, Agents SDK