Before an Agent Touches a Live Order: Holds, Rules and Permissions on Carriyo
In our previous article we looked at where AI agents really stand in post-purchase operations going into this peak, and ended with four things we think have to be true before you would let one near a live order: the data has to be normalised, the rules have to exist and be readable by the agent, the agent's reach has to be limited by something other than its own judgement, and there has to be a place where a person approves. This post goes through how those four work on Carriyo today.
We will keep to what is in the product and publicly documented, in the changelog and the MCP documentation. The links are at the end.
The MCP layer, briefly
Carriyo runs a Model Context Protocol server, which is how an AI agent or assistant connects to the platform. The documentation describes it in a sentence we rather like: "MCP is not a different product surface; it's a different interface to the same product." It exposes 80+ tools across the families you would expect, which are lookups, delivery options, products, inventory, orders, fulfillment orders, returns, shipments, reports, automation rules and system logs, and it works with MCP-aware clients such as Claude Desktop, Claude Code and Cursor, or with an agent a merchant has built for itself. The documentation is also clear about where it is meant to be used, saying that "MCP is best-suited to internal copilots and agentic ops workflows", which is the operations side we wrote about in that article.
The order and inventory side of it has been filled in over the last few releases. Release 2026.09-R1 moved the inventory tools onto inventory keys, 2026.09-R3 added tools to fulfil or unfulfil a whole order in one call and let agents address orders by the merchant's own references, and 2026.10-R1, released on 1 October, added order holds. The last of those is what most of this article is about, because a hold is the simplest version we know of a place where a person approves.
The hold as the place where a person approves
Order holds have been in Carriyo since release 2026.08-R5 in August. A held order has the status On Hold, and the release note for the API is direct about what that means: "While an order is on hold, updates and fulfillment order operations are rejected." A hold sits over an order that is open, partially allocated or allocated, which is to say before fulfilment has started, and it carries the things a review queue needs. There is an assignee, a priority from low to urgent, a review SLA in hours and a note for the reviewer.
In the dashboard a person can put an open or allocated order on hold by hand, and an order that was held by a rule shows which rule held it. The reviewer then either releases it, with an optional review note, or rejects it, which cancels the order. The Orders menu has an On Hold view with a live count. Two details matter more than they might appear to. In the Fulfillment App, picks and packs cannot be created for a fulfillment order that is on hold, so the hold is enforced on the warehouse floor as well as on the screen. And order webhooks fire when an order or a fulfillment order is held or released, so the merchant's other systems know about it. Since release 2026.09-R3 holds also cover orders that come in through the Shopify connector, and if a held order is changed in Shopify in the meantime Carriyo marks it as out of sync instead of quietly rebuilding it.
The rules that decide what gets held
The second of the four preconditions was that the rules exist before the agent arrives, and for holds they do. Order hold rules put new orders on hold automatically as they are created. Each rule combines conditions with Match ALL or Match ANY, and the conditions are the ones an operations or fraud team would recognise: order value, set per currency; whether the customer is verified; whether the billing and shipping addresses differ; payment method, destination country, sales channel and merchant; item quantity, item category and discount percentage; and the merchant's own custom order attributes. The rule's hold action sets who reviews the order, the priority, the review SLA and the note. Rules run in sequence, and the first one that matches holds the order.
The settings page for hold rules shows how many rules are active, how many orders were held in the last seven days, how many are awaiting review and the average review time, and a change history tab records every modification to the rules. So the business has already written down which orders a person must look at, and has a record of every change to that definition, before any agent is involved.
What an agent can do with a hold
Release 2026.10-R1 brought holds to the MCP server. An agent can now put a whole order on hold or release it, with `hold_order` and `release_order_hold`, and do the same for an individual fulfillment order. A hold placed by an agent carries the same assignee, priority, notes and review deadline as one placed by a person or a rule. The agent can read the hold rules, with `list_order_hold_rules` and `get_order_hold_rule`, and it cannot change them; in the words of the documentation, "Order hold rules are read-only over MCP — editing them stays in the Dashboard." And `list_orders` gained the filters a review queue needs, including whether an order is on hold, who it is assigned to, whether it is awaiting review, which rule held it, and the date range of the hold.
The constraint that we think matters most is this one, again from the documentation: "While an order is on hold, every update is rejected except `cancel_order` and `release_order_hold`." That applies to the agent as much as to anyone else. An active hold cannot be edited either. To change its assignee or priority the hold has to be released and placed again, and the earlier hold moves into the order's hold history.
There are two fairly different ways a merchant could use this. In the first, the agent is the one raising its hand. An agent that is watching orders and sees something the rules did not anticipate could put the order on hold, assign it to the right person with a priority and a deadline, and write in the note why it stopped. From that point the platform rejects any update to the order, from the agent or from anyone else, until the hold is released or the order is cancelled. In the second, the agent prepares the queue. It could list the orders awaiting review, read each order and the rule that held it, and give the reviewer a short summary of each case so that the person spends their time on the decision.
Whether the agent is also allowed to release is the merchant's choice, and we would be cautious about it at first. The documentation notes that most agent clients let a user switch off individual tools per server, and calls this "the strongest guardrail you have for production agents". A merchant who wants every release to be made by a person can leave the release tools switched off for the agent, and `cancel_order` as well if rejections should also stay with a person.
Late orders, exceptions and reassignment
Holds deal with orders before they ship. The rest of the unglamorous work is about shipments that are already moving, and here an agent mostly needs to read.
What it reads is normalised, which was the first precondition. Carriyo translates each carrier's events into one set of shipment statuses across 140+ carriers, so "out for delivery" or "failed delivery attempt" means the same thing whoever has the parcel. Lateness has one definition as well. Since release 2026.09-R2 the late and at-risk flags in the dashboard, and the promised-date alerts, use the end of the delivery window first, then the promised delivery date, then the scheduled date. And release 2026.10-R1 extended the carriers from which Carriyo records the carrier's own estimated delivery date, including FedEx and Amazon Shipping from status updates, which feeds the carrier delivery delay alert and the estimate shown on the tracking page.
On top of that data, the report tools give an agent the views an operations lead would ask for. There are open shipments by age, shipment errors over time, failed delivery analysis and SLA compliance across processing, collection and delivery. For a single shipment the agent can read the activity timeline, which covers creation, status changes, rule assignments, notifications and customer feedback, and the system logs behind it, which hold the carrier request and response for each interaction. The documentation describes this as a pattern, "Diagnose a stuck shipment", in which the agent pulls the shipment, its timeline and its logs to work out whether to reprocess, reassign or refresh the label. It also includes a caution we agree with: "System logs are diagnostic, not user-facing. Don't return raw log bodies to an end customer — narrate the cause instead."
When the agent does act, the tools are specific. `reassign_shipment` reassigns or retries an unshipped or errored shipment, `reprocess_shipment` reprocesses one that is in error, and `update_customer_promise_date` revises the date the customer sees in tracking, which the documentation is careful to distinguish from the carrier's delivery schedule. The shipping rules that decided the original routing are readable by the agent and not editable, as with hold rules. The catalogue also says which tool is not for routine use. `update_shipment_status` is described in these words: "Administrative override; discouraged for normal flows." On the promise date our own view is the one we gave in that article, which is that an agent should not move a customer's date on the strength of a doubtful scan, and that it is better to wait for something reliable.
The limits on the agent's reach
The third precondition was that the agent's reach is limited by something other than its own judgement. On Carriyo that comes from how the agent is authorised. The MCP server uses OAuth 2.1 with PKCE, and the documentation is explicit about what that means: "There is no `client_credentials` flow and no service-account tokens — every MCP session is bound to a real Dashboard user." The agent inherits that user's role and that user's tenant and merchant scope, or as the getting-started page puts it, "Whatever your Dashboard user can do, the agent can do. If you have a read-only role, the agent is read-only." Its calls count against the same rate limits as that user. On the audit trail the documentation says that "Every MCP call is logged identically to a Dashboard action", and those calls are visible in the Integration Monitor.
The documentation then lists what it recommends before an agent runs in production: use a dedicated user for the agent, tighten that user's role to the smallest set of permissions the agent needs, restrict the tool catalogue in the agent client, re-state the server's guardrails in the system prompt, review the audit trail weekly at first, and for customer-facing agents add a confirmation step in the application before any write tool fires.
It is worth being plain about the division of labour in that list. Permissions, scope, logging and the enforcement of a hold are the platform's. The choice of which tools to enable, and any confirmation step in the merchant's own agent, are the merchant's to set up. We think that is the honest way to describe it, and it is the description we would want from any vendor.
Three ways to run it
Like every capability on Carriyo, holds run in three modes. From the dashboard, a person puts an order on hold and a reviewer releases or rejects it. By rules, the order hold rules catch the cases the business has already defined. And by AI agents, through Carriyo's native MCP layer, an agent holds what the rules did not foresee and prepares the queue for the reviewer. In practice we would expect most merchants to use all three on the same orders, with the rule catching the predictable cases, the agent doing the reading, and the person making the decision.
Why what sits underneath matters more than the agent
The models that drive agents are improving quickly and are available to everyone, so we do not think the agent itself is where the advantage or the risk sits for long. What takes time to build is what the agent stands on. That means one status model across every carrier a merchant uses or might add, one definition of late, rules for routing and for review that the business has already written, and permissions and a log that treat an agent as a user. Carriyo's version of that layer has been shaped by the delivery data across 100+ brands, $5B in GMV and shipments in 200 countries, and it does not change depending on who or what is doing the work.
That is also why we think this is the lower-risk way to start. A merchant does not have to choose its agent now, or commit to one model. It can adopt the order and shipping layers alongside the systems it already runs, put its rules and holds in place, start an agent on read-only work this peak, and widen what the agent is allowed to do once the audit trail shows it has been getting things right.
If you are at DELIVER America in Las Vegas on 7 and 8 October, come and find us, and we would be glad to go through which of your post-purchase jobs an agent could safely take on and where a person should stay in the loop. Otherwise, get in touch with our team at carriyo.com/contact. The MCP documentation is at carriyo.com/docs/mcp.
Carriyo is The Intelligent Commerce Platform, from checkout to doorstep.
---
Sources
1. Carriyo. Changelog, release 2026.10-R1 (MCP order holds; carrier estimated delivery date from more carriers), 1 October 2026. https://carriyo.com/docs/changelog/2026.10-R1 2. Carriyo. Changelog, release 2026.09-R3 (MCP order tools; holds on Shopify orders; activity timelines), 5 September 2026. https://carriyo.com/docs/changelog/2026.09-R3 3. Carriyo. Changelog, release 2026.09-R2 (late shipment flags), 3 September 2026. https://carriyo.com/docs/changelog/2026.09-R2 4. Carriyo. Changelog, release 2026.09-R1 (inventory keys; MCP inventory tools), 2 September 2026. https://carriyo.com/docs/changelog/2026.09-R1 5. Carriyo. Changelog, release 2026.08-R5 (order holds and order hold rules), 13 August 2026. https://carriyo.com/docs/changelog/2026.08-R5 6. Carriyo. MCP server documentation: overview and getting started. https://carriyo.com/docs/mcp/ and https://carriyo.com/docs/mcp/getting-started/ 7. Carriyo. MCP tools catalogue: orders, fulfillment orders, shipments, reports, shipping rules and system logs. https://carriyo.com/docs/mcp/tools/ ; https://carriyo.com/docs/mcp/tools/orders/ ; https://carriyo.com/docs/mcp/tools/fulfillment-orders/ ; https://carriyo.com/docs/mcp/tools/shipments/ ; https://carriyo.com/docs/mcp/tools/analytics/ ; https://carriyo.com/docs/mcp/tools/shipping-rules/ ; https://carriyo.com/docs/mcp/tools/system-logs/ 8. Carriyo. MCP prompts and patterns. https://carriyo.com/docs/mcp/prompts-and-patterns/ 9. Carriyo. MCP limits and security. https://carriyo.com/docs/mcp/limits-and-security/ 10. Carriyo. Order status codes and shipment status codes references. https://carriyo.com/docs/reference/order-status-codes/ and https://carriyo.com/docs/reference/status-codes/ 11. Carriyo. Tracking documentation and carriers. https://carriyo.com/docs/platform/shipping/tracking/ and https://carriyo.com/carriers 12. Carriyo. "After the Order Is Placed: What Operations Teams Are Really Handing to AI Agents This Peak" (Carriyo blog, October 2026). https://carriyo.com/blog/order-placed-operations-teams-handing-ai-2026-10-06/