You Ask a Shopping Agent to Find a Jacket. How Does It Actually Place the Order?

A shopper opens a store’s chat window on Tuesday. “I need a waterproof jacket before Friday. Medium, under $200. Can you find one that will arrive in time?”

It is an ordinary request, the kind a sales associate might hear several times a day. For an AI agent, it presents a small investigative assignment. The answer depends on facts that a language model cannot establish from its training: what the store sells today, what is available in medium, and what a carrier can deliver to this customer’s address.

The agent replies, “I’ll check.”

What happens next?

That brief interval, between a promise to check and an answer grounded in a business system, is where tool calling happens. Following it closely reveals how an agent moves from conversation to action—and why each move requires more than a convincing sentence.

What does the model receive before it can act?

The shopper sees a chat window. The model receives a package assembled by the application: the conversation, relevant instructions, and descriptions of the tools available for this task.

A tool is a capability the application makes available through a defined interface. It might search a catalog, check stock, estimate delivery, or create a cart. Behind that interface is ordinary software that performs the work.

For this shopping request, the application might initially offer three tools: search_products, check_inventory, and estimate_delivery.

Each description explains what the tool does and which inputs it accepts. The inventory tool, for example, might require a product identifier and a size. Those requirements are expressed in a schema: a formal description of the expected fields, their types, and any constraints.

The application keeps these definitions in a tool registry. Its internal record also connects each tool to the code that implements it, along with permissions, time limits, and rules for handling results. The model sees the information it needs to request an operation. The application retains the information it needs to carry it out.

This separation matters. Giving a model a description of an inventory tool does not give the model a database connection. It gives the model a way to ask the application for an inventory check.

The application should expose tools appropriate to the user and the task. Our shopper needs product information, not the ability to change prices across the store. If the business has hundreds of tools, the application can search its catalog and load relevant definitions as needed.

With those definitions in view, how does the model turn the shopper’s words into a request?

How does “find me a jacket” become a tool call?

The model first needs a product to investigate. It can request a catalog search using the shopper’s stated requirements: waterproof, medium, below $200.

In a typical model-directed workflow, the model selects a tool from the available definitions and generates arguments for it. Applications can also restrict or require particular tool choices. Either way, the output at this stage is a structured request, not the result of a search.

Suppose the application executes the search and returns a candidate: the Harbor Rain Jacket, priced at $149, with product identifier jacket_104. The model now has a concrete product to check.

Its next request might look like this. The examples here use a simplified format; exact message formats differ across platforms.

{
  "call_id": "call_17",
  "name": "check_inventory",
  "arguments": {
    "product_id": "jacket_104",
    "size": "M"
  }
}

Three details do the work. The name identifies the operation. The arguments identify the product and size. The call identifier lets the application match a later result to this particular request.

The product identifier came from the catalog result. The size came from the shopper. Neither needs to be invented.

The delivery destination, however, is still missing. Unless the application already has an appropriate destination available, the agent must ask for it before obtaining a useful delivery estimate. Tool calling does not remove the need for clarification; it makes missing information visible.

At this point, the model has produced a request to check stock. No inventory check has happened yet.

So what turns that request into an actual operation?

Who executes the request—and what gets checked first?

The application’s runtime—the software coordinating the exchange—receives the tool call and looks up its implementation in the registry.

Before running it, the runtime checks the request. Does this tool exist? Is it available in the current workflow? Can this user perform this operation? Do the arguments satisfy the tool’s contract?

For our inventory call, that includes checking that the product identifier and size are present and correctly formed. A carefully defined schema can reject unexpected fields instead of silently accepting a misspelling. Further checks enforce rules that types alone cannot express, such as which store or account the request may access.

Even when a model produces schema-constrained output, the application still needs its own checks. Correctly formatted arguments do not prove that an operation is authorized.

Once those checks pass, the runtime invokes the registered function. That function contacts the inventory service, using credentials managed by the application. The inventory service applies its own access controls and returns its answer.

This is the moment the external work occurs. The model generated the request; the application ran the code.

The distinction is easy to miss because an interface may present the entire sequence as “the agent is checking stock.” Underneath that phrase are separate responsibilities: choosing an action, checking it, and executing it.

Now the store has answered. How does that answer get back into the conversation?

How does the model learn what happened?

Suppose the inventory service reports that three medium jackets are available. The application validates the response and prepares a tool result for the model.

{
  "call_id": "call_17",
  "ok": true,
  "data": {
    "product_id": "jacket_104",
    "size": "M",
    "available_quantity": 3
  }
}

The matching call_id connects this observation to the earlier inventory request. That becomes especially useful when several calls are in progress: an answer about one jacket must not be mistaken for an answer about another.

The application then makes the result available in the model’s continuing context, preserving the preceding call as the platform requires. In a common API implementation, this means making another model request containing the conversation, the tool call, and its result. A managed platform may handle that exchange internally, but the logical sequence remains the same.

The model can now reason with fresh evidence: this particular jacket is currently available in medium.

It should also recognize the limits of that evidence. Three units available does not mean one has been reserved. Stock can change before checkout.

Nor does the model need every field the inventory service returned. Internal warehouse notes and unrelated records may have no place in the conversation. Small, relevant results can be passed through directly; larger results can be reduced to selected fields or represented by a reference that supports further retrieval. Any omission that affects interpretation should be clear.

External text also remains data. A product description containing instructions to reveal customer information does not gain authority because it arrived through a tool.

The model has learned something new. Is it ready to answer the shopper?

Why does one request often require several rounds?

Availability answers only part of the question. The shopper needs the jacket before Friday.

After obtaining the destination, the model can request a delivery estimate using the product and the relevant location information. The application checks that call, executes it, and returns another correlated result.

Suppose the shipping service estimates Thursday delivery for $12. The agent now has evidence for a useful response: the jacket costs $149, medium is currently available, and the quoted delivery option is expected to arrive Thursday. Any taxes or other charges still need to be established before confirming the final total.

This is the tool-calling loop:

The model requests an operation → the application checks and executes it → the result returns to the model → the model answers or requests another operation.

A single shopper message may lead to several trips around that loop. Some calls depend on earlier results: the agent needs a product identifier before checking that product’s stock. Independent calls may run in parallel when the workflow allows it.

The application also needs stopping rules. Limits on time, cost, or the number of calls prevent an unsuccessful search from continuing indefinitely. When necessary information cannot be obtained, the agent should explain the gap or ask the shopper for help.

So far, the agent has been gathering facts. What changes when the shopper says, “That works. Order it”?

What changes when a tool can place an order?

The structure of the exchange stays familiar. The model proposes a call, the application checks and executes it, and a result comes back.

The consequences change.

An inventory lookup reads a record. Placing an order can reserve stock, charge money, and start a fulfillment process. Before execution, the application needs the specific product, quantity, delivery option, address, payment authorization, and final total. It must enforce any approval required for that concrete purchase.

A visible ordering tool is not blanket permission to buy. The runtime checks the actual operation against the user’s authorization and the current business rules. The order service must also verify current price and stock; the earlier search results cannot guarantee either indefinitely.

This is where agentic commerce becomes more than a recommendation experience. The conversation can lead to a transaction, but each consequential change has to be supported by a valid, authorized request.

What if that request does not produce the expected confirmation?

When a call fails, what should happen next?

Suppose the order cannot be completed. The application needs to tell the model what kind of problem occurred, because “failed” is too vague to guide the next step.

A missing delivery option is an input problem. The request needs repair. A purchase above the user’s authorized spending limit is a policy problem. The agent cannot solve it by resubmitting the same call. A sold-out jacket is a business rejection: the order service worked and returned an unwelcome but useful answer.

A network timeout is different. The application did not receive a timely response, and may not know whether the order was created.

Useful result contracts distinguish these cases: validation, policy, execution, and business failures. They give the model a stable error code and a short explanation, while keeping sensitive diagnostics in appropriate logs.

That lets the agent respond to the actual problem. It can supply a missing detail, explain a permission limit, or offer another jacket. Retrying unchanged is appropriate only when the failure and the operation make it safe.

The timeout deserves particular attention. What if the store placed the order, but its confirmation never arrived?

How do you retry without buying two jackets?

If the application sends a fresh purchase request after an ambiguous timeout, it risks creating a second order.

To prevent that, the workflow and order service need an idempotency mechanism: repeated attempts at one intended operation must not produce additional purchases.

The workflow assigns a stable idempotency key to the intended purchase and reuses it on retries. The order service recognizes that key, checks that the request is compatible with the original, and returns the recorded outcome rather than creating another order, within its documented scope and retention period.

This key serves a different purpose from the tool call identifier. The call identifier matches a request with its response in the conversation. The idempotency key connects execution attempts to one intended business action. A retry may have a new call identifier while retaining the purchase’s idempotency key.

Both the workflow and the service must cooperate. Generating a new key for every attempt loses the connection. Sending a key to a service that does not enforce it provides no protection.

Until the outcome is resolved, the application should record it as unknown and seek an authoritative status. The agent should not tell the shopper that the purchase failed—or succeeded—without evidence.

Does a marketing agent work the same way?

The retailer’s marketing team might later ask an agent to investigate why shoppers view this jacket but abandon checkout.

The business question changes; the mechanism carries over. The model requests campaign and checkout data through available tools. The application checks access, runs the queries, and returns results. The model uses those observations to decide whether it has enough evidence or needs another query.

Large reports require particular care. Selected metrics should preserve relevant context, such as reporting dates, advertising spend, and missing data. Thousands of customer records need not enter the conversation to answer a question about conversion rates.

If the marketer then asks for a follow-up campaign, drafting the message, selecting an eligible audience, and sending it are distinct operations. Sending requires the appropriate authorization and business checks. An ambiguous response from a sending service raises the same question as the uncertain jacket order: did the action happen already?

Tool calling is the shared mechanism beneath these different uses. Each business supplies its own capabilities and rules; the request–execution–result loop connects them to the conversation.

When can the agent say “your order is placed”?

Back in the shopper’s chat, the order service finally returns a confirmed order with an order number, final total, and delivery estimate.

The application matches the result to the request and passes the relevant facts to the model. The model can now tell the shopper that the order has been placed, state the confirmed total, and describe Thursday as the estimated delivery date.

That answer is the last step in the exchange. Its wording should reflect exactly what the system established. A cart is not an order. Available stock is not a reservation. An estimated arrival is not a delivery guarantee.

What appeared to be one conversation was a chain of structured requests and recorded outcomes. The model interpreted the shopper’s goal and chose useful next steps. The application enforced the rules and performed the operations. Each result supplied the evidence for the next decision.

The shopper can close the chat because there is now an order in the store’s system—and the agent has received the confirmation to prove it.

This is Week 6 of a 26-week series on agent systems from first principles: capability maps, skills vs. tools, memory and context, loops, harnesses, and the patterns that separate a demo from production.

Happy learning, happy building.
Tao