Patterns: Act Safely and at Scale

What you'll learn: five patterns for systems that do more than answer (tool calling with approval, workflow versus agent, asynchronous batch processing, a human review queue and an AI gateway), and how to finish the project's pattern shortlist.

At a glance

Figure 1. The act patterns in phase 2 of the Order and Policy Assistant

How to read this: the model only proposes; a person approves; the Tool server makes the one write, with an idempotency key (a unique id that makes a repeat change nothing); model calls pass through one gateway to the LLM (large language model) provider.

• A model proposes actions; code and a person decide whether they run.
• Prefer a workflow of fixed steps; use an agent loop only when steps cannot be known in advance.
• One AI gateway gives one place for keys, limits and logs.

Scenario

Composite scenario, not a real company. The first release of the Lumen Order and Policy Assistant, a fictional distributor's tool for its 24 customer-operations agents, is read-only. For phase 2 the Head of Customer Operations wants three actions: change a delivery address, apply a discount exception, create a return authorisation. Team leads approve exceptions up to their limit; only Finance releases a credit hold.

What you will be able to do

• Choose among the five act patterns for a requirement.
• Put a human approval and an idempotency key in front of every write.
• Explain why a workflow beats an agent when steps are known.

Prerequisites

• Patterns: retrieval, hybrid search, documents.
• AI Architect agents, tools and MCP for the architecture.

Core ideas

Pick a pattern from the requirement

Figure 2. Which act pattern fits

How to read this: the first questions pick how the work runs; the last two add a review queue and a gateway.

Pattern 7: Tool calling with approval

• When to use: the system must change data elsewhere (an address, a discount) and a mistake costs money or trust.
• When not to: the task only reads; fetch in code instead.
• Structure: the Orchestrator, Approval service and Tool server path in Figure 1. The application runs the call (tool-use documentation).
• Failure modes: invented arguments; approval of a summary, not the real arguments; a write sent twice; a tool with more access than the user.
• How to evaluate: golden requests (fixed test requests with known right outcomes); tests that a bad argument or unauthorised tool is refused and that replaying a key writes once.
• Cost profile: one extra model turn per call plus people's time.
• Minimal build: one tool with a strict argument schema; code checks arguments and permission; a person approves the exact arguments; the write carries an idempotency key (approval gate, retries and keys).
• Used in the Order and Policy Assistant: not in the read-only MVP (minimum viable product, the first release). Phase 2 uses it for address changes, discount exceptions and return authorisations.

Pattern 8: Workflow versus agent

• When to use a workflow: the steps are known, so code fixes the order. Anthropic's article describes workflows as orchestrated "through predefined code paths" (source).
• When to use an agent: the next step depends on what the last found, and a step limit and tool allow-list can bound it. The article describes agents as models that "dynamically direct their own processes and tool usage".
• Structure: the Orchestrator in Figure 1, as a fixed sequence of calls.
• Failure modes: a workflow too rigid for odd cases; an agent that loops or picks the wrong tool.
• How to evaluate: run both on the same golden set; compare success, steps, cost and latency; adopt the agent only if it clearly wins.
• Cost profile: a workflow makes a predictable number of calls; an agent's count varies.
• Minimal build: a workflow in plain code first (workflow or agent); a loop only for the step that needs it.
• Used in the Order and Policy Assistant: a workflow, yes; an agent, no. Every step is known: extract, route, fetch, retrieve, explain.

Pattern 9: Asynchronous batch processing

• When to use: nobody is waiting, volume is high and the work can finish later (evaluation reruns, bulk classification).
• When not to: an agent is waiting on the screen.
• Structure: the Worker in Figure 1, calling the model gateway off the request path.
• Failure modes: failures found hours later; one bad item stopping the run; duplicates after a retry.
• How to evaluate: counts in and out; a status per item; a rerun of failures matches a clean run.
• Cost profile: the gain is keeping slow work off the user's path; check your provider's published terms before assuming a price difference (cost economics).
• Minimal build: a queue of items, a worker handling one at a time with an idempotency key, a status per item and a report.
• Used in the Order and Policy Assistant: not on the agent's path. Design proposal, not in the brief: rerun the golden set nightly as a batch.

Pattern 10: Human-in-the-loop review queue

• When to use: some outputs need a person's judgment, a limit or a signature before they take effect.
• When not to: code can verify the check, or nobody has the authority and time to review.
• Structure: the Approval service in Figure 1.
• Failure modes: a queue that grows until people click through; an approver shown a summary, not the action; no owner or record of the decision.
• How to evaluate: time to decision, share approved unchanged, share rejected, a sample re-checked by a second person.
• Cost profile: people's time dominates.
• Minimal build: proposals showing the exact action, an owner per size, approve or reject with a reason, an audit record (review queues).
• Used in the Order and Policy Assistant: phase 2. Design proposal: the queue holds discount exceptions above 5 percent and changes after picked, approved by a team lead, a director or the warehouse (P-DSC-03, P-ORD-04).

Pattern 11: AI gateway

• When to use: several features or teams call models and you want one place for keys, limits, logging and provider changes.
• When not to: a single prototype with one call; a gateway is another service to run.
• Structure: the Model gateway in Figure 1; "AI gateway" is this catalog's name for it. It is not the customer's API gateway, which authenticates agents.
• Failure modes: a single point of failure; logs capturing personal data; a silent retry that hides a failure.
• How to evaluate: failure tests with the provider down; a check that logs hold no customer personal data.
• Cost profile: one more component to host and watch (gateway architecture).
• Minimal build: one internal endpoint adding the key, a timeout, a retry limit and a request id, with logs free of customer personal data.
• Used in the Order and Policy Assistant: yes: the design already reaches the hosted model through a model gateway.

In the interview: "Would you build an agent for this?" A strong answer asks whether the steps are known, proposes a workflow first, names the evidence that would justify an agent and keeps writes behind approval.

Worked example

Assumptions: illustrative phase 2 requests under P-DSC-03 and P-ORD-04; the system proposes, a person approves. An address change while the order is confirmed or allocated needs only the agent's confirmation.

Spot the flaw. The approval screen shows the model's sentence, "Apply a small discount to order 48213", with an Approve button; the tool then runs with the model's arguments. What is wrong?