When Commerce Needs an Agent, and When a Workflow Is Enough

A customer wants a replacement laptop delivered before a trip. They give an assistant a budget and several preferences, then ask it to find a suitable option. The team building the service has a design choice: a fixed shopping workflow, a workflow with a few model-assisted steps, or an agent that decides which tools to use as it searches.

Those choices should follow the task. A familiar reorder with a known product and approved seller presents a different problem from an ambiguous request that requires comparing unfamiliar offers. Adding agents to both does not establish that either service will work better.

The laptop scenario in this article is fictional. The architecture and tests are proposed design examples, not results from a deployed commerce system.

Decide which part of the task needs judgment

Anthropic's 2024 architecture guide distinguishes predefined workflows from agents whose models dynamically direct their process and tool use. A workflow can still contain model calls. The page now warns that its tooling discussion has changed and points to newer guidance, so the distinction is useful without treating its old implementation examples as current recommendations. Building effective agents

Start with the customer's task rather than the number of agents. If the instruction is to reorder a specific approved consumable, a fixed sequence may retrieve the item, check current terms, apply the permission rules and submit the order. A model is not necessary merely to move between those known steps.

If the customer instead asks for a "light laptop suitable for travel," the service may need to clarify what light means, examine specifications and compare tradeoffs. A model could help interpret that request within a fixed workflow. Dynamic tool choice becomes a separate option when the next useful step depends on what the investigation finds.

These are candidates for comparison. They are not a ranking in which greater autonomy is automatically better.

Separate interpretation from permission

Suppose the customer sets an illustrative £900 total limit including delivery. A recommendation that fits the listed item price may still fail the actual budget once taxes or delivery are added. The purchase step should check the final offer against the current permission, using authoritative values from the merchant or transaction system.

The model's statement that an item is suitable does not grant permission to buy it. In this proposed design, a separate execution service checks the allowed seller, selected item, amount, timing and any required user confirmation. A previously granted delegation can be used within its documented limits; a material change outside those limits needs another decision.

Keep the permission record separate from the shopping conversation. The assistant may misunderstand a request or encounter a merchant page containing instructions directed at the model. Product descriptions can supply evidence about an offer, but they cannot expand the customer's authority or change the system's controls.

The agent-roles guide maps the participants. This article asks where model-directed choices are useful within that arrangement. It does not prescribe one current protocol or assume that every merchant supports agent checkout.

Give uncertain outcomes a stable record

An agent can choose another search after an unhelpful result. A timed-out order submission needs different treatment. The executor should retain the original attempt and retrieve its outcome before considering another submission under the provider's supported process.

The assistant's memory of the conversation should not be the only place where that attempt exists. A lost session or a repeated instruction should still lead to the same purchase record. Keep the original request, accepted offer, permission and resulting order/payment references available to the components that need them, with access scoped to the customer.

Anthropic's April 2026 Managed Agents article describes its own separation of the session log, agent harness and execution environment. That is a useful current implementation example of separating responsibilities, not evidence that a commerce integration inherits purchase authority or duplicate protection. Managed Agents architecture

Choose the simplest candidate that meets the task

Compare complete outcomes rather than persuasive answers

Build a small set of synthetic cases that exercise the intended service. Run all three candidates, the fixed workflow, the workflow with model-assisted steps and the bounded dynamic agent, against the same available information and permitted actions. Define the expected outcome before seeing any response.

Also test ordinary successful cases. A system that refuses everything may avoid an unauthorised purchase while failing the customer's task. Record completion quality, time and cost alongside control violations and unresolved cases. Choose thresholds for the particular service; this article supplies no universal pass percentage.

NIST's AI Risk Management Framework Playbook recommends selecting measurements for the intended context and documenting limits in what can be measured. Its current site notes that the framework is being updated. The guidance informs evaluation design; it does not certify these proposed tests or a particular agent. NIST Measure guidance

Keep the decision reviewable as the service changes

Record the task set, candidate versions, tools, permissions and observed failures. A new model, merchant interface or fulfilment route can change the comparison. Repeat the affected cases when those dependencies change, rather than assuming that a previous demonstration still covers the current service.

The customer eventually needs a valid purchase and a usable support trail. The purchase-to-refund guide follows those records across the later handoffs. If a fixed workflow meets the task, keep it. If a bounded agent adds useful coverage, retain the evidence for that choice and the controls around what it can execute.