Where Should This Order Ship From? Carriyo as the Order Management Layer, in Three Modes
We have just published two pieces on the order management space: a scorecard of what the last decade's ideas actually delivered, and a look at where merchants are putting their money now to get order operations ready for AI. The short version of the second one was that the investment is going into the data and orchestration layer underneath the storefront, not into the storefront itself. This post is about what that layer looks like on Carriyo, and we want to do it through one small change we shipped in October, because small changes are usually where you can see how a system really works.
The change is how we rank fulfillment locations by distance when we allocate an order. It took up six lines in our changelog, and it touches almost everything an order management layer has to get right.
The change itself
Our allocation engine has a set of prioritisation rules that break ties between locations that could all fulfil an order. One of them is called Maximize customer proximity, and since October it ranks locations by their real distance to the customer's address. Locations in the customer's country come first. Among those, we measure the distance to every location that has coordinates and keep the nearest, treating anything within a kilometre of it as equally near and leaving the next priority to decide. A location with coordinates always outranks one without, and only when none has coordinates do we fall back to matching on city and state, which is what we did before.
We will say openly that this fixed a bug, because our changelog does: before the change, the proximity rule could prefer a location far from the customer over a nearer one. It also illustrates something we think about a lot in this layer, which is that rules are only as good as the data they run on. A store without coordinates cannot be ranked by distance, and we would rather fall back to city and state than guess. The one-kilometre band is there because two stores a few hundred metres apart are, for most purposes, the same distance away, and which of them should take the order is better answered by the next rule, which might be the one with more stock or the one that avoids a split.
Where that sits in the allocation engine
To see why one tie-break rule matters, it helps to know what happens to an order before it gets there. Our order allocation module runs in three modes. Some orders arrive with their fulfillment locations already decided upstream, and we respect that. Some arrive with no location and automatic allocation switched on, and the engine picks one for every item. And some wait, flagged as missing a location, until someone in operations allocates them in the dashboard.
When the engine runs, it narrows the field in stages. It starts with the locations that have stock, keeps the ones whose coverage includes the destination, and then works through the allocation rules we introduced in May, which let a business say where an order may go, for example by sales channel, order value, product category or dangerous goods, with the first matching rule winning. Only then do the prioritisation rules run, each one trying to maximise fulfilment with the fewest splits, availability, or customer proximity. If locations are still tied at the end, we pick one at random, which is the honest answer when there is nothing left to choose on.
Two things around the edges are worth knowing. Allocation also works for merchants who do not run inventory in Carriyo at all; with inventory management off, the engine picks from the locations that can fulfil the order and cover the address, using the same rules and priorities. And when some items cannot be allocated, what happens next is a setting rather than a surprise: either the allocated items proceed and the rest is cancelled, or the fulfillment order stays open, flagged as failed with a reason per line. Either way, the order itself is not cancelled.
The inventory underneath
Allocation reads from our inventory module, and we are careful about what that module is. Carriyo keeps an operational mirror of your stock, not a master record; the WMS, ERP or commerce platform stays the source of truth. We track stock per inventory key at each location, usually a GTIN, and keep it current through snapshot and adjustment events, such as sales, receipts, transfers and returns. When an order allocates to a location we reserve the quantity, so later orders see on-hand minus reserved and nothing gets allocated twice. Reservations clear when the order is fulfilled or the parcel ships, or when the order is cancelled before booking.
That is also the data an AI agent stands on if you ask it a question about an order, and it is why we think the layer underneath matters more than the agent. The agent can only be as right as the stock positions, the location coordinates and the reservation state it reads.
The control surface: holds, rules and permissions
A decision engine needs a place where a person can stop it. On Carriyo that is the order hold, which we wrote about in detail in October. A held order carries an assignee, a priority, a review SLA and a note, and while it is on hold, updates and fulfillment operations are rejected until someone releases it or cancels the order. Hold rules put new orders on hold automatically on conditions such as order value, mismatched billing and shipping addresses, payment method or destination country.
The second control is who may do what. In a recent release we tightened two things. The pages and actions a user sees in the dashboard now match what their role can actually do. And user management stays within your own access: you can only give another user access you hold yourself, across roles, merchants, countries, locations and MCP access, and you cannot change or remove a user who holds access you do not.
Taken together, the allocation rules say where an order may go and the prioritisation rules say which of the allowed locations we prefer. Holds say which orders must wait for a person, and permissions say who is allowed to change any of it.
Three ways to run the same decisions
Every capability on Carriyo runs in three modes, and allocation is a good example of what that means in practice.
From the dashboard, an operations person allocates an open fulfillment order by hand or moves it later, seeing the stock position of every candidate location as they do it, and can put an order on hold, release it or reject it. The same checks are available over our API, including a dry run that returns what allocation would do without saving it.
By rules, with automatic allocation on, the allocation and prioritisation rules decide every order without anyone looking at it, hold rules divert the ones the business has said need a review, and once we have allocated every item our Shopify connector follows the decision by moving or splitting the Shopify fulfillment orders to match.
By AI agents, through our native MCP layer. Our MCP server exposes more than 90 tools, and we think of it as a different interface to the same product rather than a separate product. An agent can read an order and its fulfillment orders, move a fulfillment order to a different location, split or merge fulfillment orders, change the delivery method, and hold or release an order. It cannot edit hold rules or automation rules, which stay in the dashboard. And whatever it does, it does as the dashboard user who authorised it, with that user's permissions and merchant scope, and it can ask up front what it will be allowed to do before it tries.
In practice we expect most customers to use all three on the same orders. The rules make the routine decision, an agent reads the exceptions and prepares them for a person, and the person decides the ones the rules did not foresee.
Why we build it this way
The second piece this week argued that the money is going into the data and orchestration layer because that is what AI needs underneath it. What it did not go into, and what we have tried to show here, is that the layer is mostly edge cases: locations without coordinates, stock that is reserved but not yet shipped, an order that was changed upstream while it was on hold. Our version of that layer has been shaped by the orders and shipments of 100+ brands, over $5B in GMV and deliveries in 200 countries, with the same shipment status model across 140+ carriers underneath it, and the point of the three modes is that the layer does not change depending on who or what is operating it.
It is also designed to be adopted a piece at a time. You can push orders to Carriyo for visibility only and keep allocation in an existing OMS, then switch the allocation engine on later, with or without inventory, when you are ready. That is a lower-risk path than a re-platform, and it leaves the choice of agent and model open.
If you would like to go through how your own locations, rules and holds would run on Carriyo, and which of those decisions you would hand to rules or to an agent first, get in touch with our team at carriyo.com/contact. The allocation documentation is at carriyo.com/docs/platform/orders/allocation and the MCP documentation at carriyo.com/docs/mcp.
Carriyo is The Intelligent Commerce Platform, from checkout to doorstep.
---
Sources
1. Carriyo. Changelog, release 2026.10-R9 (22 October 2026): "Order allocation ranks locations by distance". https://carriyo.com/docs/changelog/2026.10-R9 2. Carriyo. Changelog, release 2026.10-R3 (12 October 2026): dashboard access matches each role; user management stays within your own access; MCP `get_access` tool. https://carriyo.com/docs/changelog/2026.10-R3 3. Carriyo. Changelog, release 2026.10-R1 (1 October 2026): MCP order hold tools. https://carriyo.com/docs/changelog/2026.10-R1 4. Carriyo. Changelog, release 2026.08-R5 (13 August 2026): order holds and order hold rules. https://carriyo.com/docs/changelog/2026.08-R5 5. Carriyo. Changelog, release 2026.08-R3 (10 August 2026): order allocation without inventory management. https://carriyo.com/docs/changelog/2026.08-R3 6. Carriyo. Changelog, release 2026.06-R1 (11 June 2026): stock-aware location changes and allocation; available-locations and allocate endpoints; Shopify orders follow Carriyo allocation. https://carriyo.com/docs/changelog/2026.06-R1 7. Carriyo. Changelog, release 2026.05-R1 (18 May 2026): Order Allocation Rules. https://carriyo.com/docs/changelog/2026.05-R1 8. Carriyo. Documentation, "Allocation" (modes, engine stages, coverage, partial allocation, re-allocation). https://carriyo.com/docs/platform/orders/allocation/ 9. Carriyo. Documentation, "Inventory" (operational mirror, inventory keys, events, reservations). https://carriyo.com/docs/platform/inventory/ 10. Carriyo. Documentation, "Orders" (allocation decided manually, via rules, or by a connector; orders pushed for visibility with allocation in an external OMS). https://carriyo.com/docs/platform/orders/ 11. Carriyo. MCP documentation: overview, tool catalogue, Orders tools and Fulfillment orders tools. https://carriyo.com/docs/mcp/ , https://carriyo.com/docs/mcp/tools/ , https://carriyo.com/docs/mcp/tools/orders/ , https://carriyo.com/docs/mcp/tools/fulfillment-orders/ 12. Carriyo. "Before an Agent Touches a Live Order: Holds, Rules and Permissions on Carriyo" (October 2026). https://carriyo.com/blog/agent-touches-live-order-holds-rules-2026-10-06/ 13. Carriyo. "Decide and Deliver: Carriyo Expands Into Distributed Order Management and Fulfillment" (August 2026). https://carriyo.com/blog/decide-deliver-carriyo-expands-distributed-2026-08-04/ 14. Carriyo. Part 1 and Part 2 of this week's order management series (October 2026). https://carriyo.com/blog/ten-years-order-management-ideas-became-2026-10-26/ , https://carriyo.com/blog/money-goes-merchants-buying-order-operations-2026-10-28/