How to tell whether an agent can run your back office system

A scheduling product sold on its AI can have an API that lets an agent create a task and still not let the agent ask where the task was scheduled. That is what The Headless Index recorded for Motion: “an agent can create a task but cannot query how Motion placed it.” A back office system can be run by an agent when four things hold: the agent can call the system’s decision engine, it learns of every state change without polling, it can read a machine contract, and it acts through named transitions under its own scoped identity. Motion passes on the records and fails on the engine, and the engine is the check to run first.

That is the test, and it applies the same way to a quoting tool (CPQ), an order management system (OMS), a warehouse management system (WMS) and a scheduler. The pages that rank for headless back office today describe something else. They treat headless as a storefront split from an ecommerce back end, and none of the five we checked on 2026-10-12 asks whether software, rather than a person, can operate that back end. The four checks below come from the rubric we use to score vendors: in May 2026 we scored 447 software vendors on how well a machine can operate them, the Index has since grown to 550 vendors, and the questions here are that rubric applied to the back office.

The records are not the system: test whether the engine is callable

The first check is whether the agent can reach the part of the system that makes decisions, because that part is what you bought. A quoting tool is a set of configuration and pricing rules; the quote record is its output. An order system’s value is allocation and routing: which warehouse ships which line, and what happens when stock is short. A warehouse system decides slotting and pick release. A scheduler decides placement.

An API that exposes only the records gives an agent a database with business rules it cannot see. The agent can write a quote line, but it cannot ask the pricing engine what the line should cost. It can create an order, but it cannot ask why the system allocated it to the slower site.

Motion is the measured case. Its API covers tasks, projects, recurring tasks, schedules, statuses, comments, custom fields, users and workspaces, and the Index records that create, read, update and delete work, plus a move endpoint. The product’s value, the auto-scheduling engine that arranges work against calendars, is not exposed, and Motion scores 8 of 20 on headless operation and 30 of 100 overall. The criterion behind that score asks one question, in our methodology’s words: “Can this vendor be operated end-to-end with no UI involvement?” (methodology). For a back office system, end to end includes the engine.

The practical test needs only the vendor’s API reference. List the three decisions the system makes for you, then look for an endpoint that returns each decision and the inputs it used. A vendor that documents “calculate”, “price”, “allocate”, “reserve” or “schedule” operations with their reasons in the response passes. A vendor whose reference stops at resource CRUD fails, however complete the CRUD is.

Test whether state changes arrive as signed events

The second check is whether the system tells the agent what changed, because a back office runs on state transitions: a quote approved, an order allocated, a pick confirmed, a slot moved. Our rubric asks it directly: “Can an agent subscribe to state changes rather than polling?” Its lowest band reads “No webhooks. Agents must poll.”

Motion scores 4 of 20 here: the Index found no webhooks at all. Its documentation lists no events section, no signing scheme and no delivery semantics, so an agent that wants to know when a task was rescheduled has to call GET /v1/tasks on a timer and diff the results itself. For a scheduler, the reschedule is the event that matters most.

Order platforms show what passing looks like, and where passing still leaves gaps. Commerce Layer signs callbacks with HMAC-SHA256, and its webhook topics follow resource.action names such as orders.place, declared in the same OpenAPI document as the API. Shopify, per its Index scorecard, delivers more than 100 event types across orders, inventory and fulfillments, signed and versioned with the API. Sitecore OrderCloud has integration events for OrderCheckout and OrderReturn, but the Index records thin retry and replay, with no documented redelivery window.

The rubric’s evidence list for this criterion names four things to check in the event reference, the last being “Webhook payload completeness (carries enough state to act, or ‘go fetch’)“:

The delivery row is the one buyers skip. An agent that misses one allocation event acts on a stale order until something else corrects it.

Test whether the contract is machine-readable

The third check is whether an agent can read the system’s interface without a person transcribing it. The rubric’s question: “Can an agent introspect the schema at runtime and act on it?”

Motion fails it outright. The Index found that https://docs.usemotion.com/openapi.json returns the documentation site’s HTML and api.usemotion.com/v1/openapi.json returns a 404, so any client has to be written by hand from the rendered reference. Motion scores 6 of 20 on this criterion.

The pass condition is concrete. Ask the vendor for the URL of its OpenAPI or GraphQL schema, fetch it with a script, and check that it validates and is current; our rubric’s second band reads “Schema introspectable; OpenAPI present and current within 90 days.” Then check that the events are in the contract too. Commerce Layer’s topics sit in its OpenAPI document, so a machine can discover the event catalogue from the same file it uses to call the API. An event list that exists only as a documentation page is one more thing a person has to keep in sync.

For back office systems the schema carries a second load: custom fields. Every quoting and warehouse deployment adds its own attributes, and an agent that cannot read them at runtime will write records that pass the API and break the process.

Test whether transitions are named operations under a scoped identity

The fourth check is how the agent changes state, and who it is when it does. A system where every change is a generic update on a record lets an agent set any field to any value its token allows. A system where each transition is its own operation, approve a quote, release an order, confirm a pick, lets you grant the transitions one by one.

Bitvea, the company that publishes this site, builds a CRM with an MCP server, and its setup document shows both halves of this check. The deal tools are listed as “list, get, create, update, delete, move_stage, list_stages”, so a stage move is a named tool beside the generic update. And each API key “is scoped to an organization and member, with permissions inherited from their role”, so an agent acts as a member whose role you set, not as an administrator.

OrderCloud shows a third control worth asking for. Its webhooks are bound to routes, and the Index records that BeforeProcessRequest lets a listener veto the call. A pre-commit hook like that is a place to put a rule an agent cannot skip: reject an order release above a value, or a quote discount past a threshold, before the system writes it.

The test questions for a vendor:

1. Are state transitions separate operations, or field writes on one update call?
2. Can a credential be limited to some transitions and not others?
3. Can a credential be issued to a non-human member with its own role, and revoked on its own?
4. Is there a hook that can reject a write before it commits?

A system that answers no to the first two can still be run by an agent, but every guardrail then lives in the agent, which is the one component you trust least.

What the order platforms in the Index show

The Index has no OMS category, but its commerce category covers order workflows, and it shows the pattern this test is built to catch. The category holds 28 platforms, all scored on 2026-08-20 under methodology THI-v1.0, and 20 of them have all five criteria scored.

Of those 20, eight score 15 or more of 20 on headless operation: BigCommerce 16, Commerce Layer 17, commercetools 18, Medusa 16, OrderCloud 16, Saleor 16, Shopify 18 and VTEX 15. None of the eight scores 15 or more on MCP posture; the highest is Saleor at 12. Across the 20, headless operation averages 13.9 of 20 and MCP posture 8.0.

The order surface is there. commercetools, per the Index, exposes every commerce primitive through its API, including business units and approval flows. What lags is the layer that hands that surface to an agent. Commerce Layer has one MCP server, and it wraps the Metrics API only: “Core resources, orders, SKUs, prices and markets are not exposed through it.”

So for order systems, checks one to four will often pass on the API and the agent integration will still be work you do. That is a smaller problem than a missing engine. Of OrderCloud, which has no MCP server, the Index says its OpenAPI document “makes an agent bridge easy to write”. An engine the vendor never exposed is not something a customer can add.

What this test cannot tell you

The Index holds no quoting, order management or warehouse category, so this post names no CPQ, OMS or WMS vendor and scores none. The commerce figures above describe ecommerce platforms that carry order workflows, not dedicated order management systems, and a dedicated OMS may score differently. Motion stands in for schedulers because it is the scheduler the Index has scored, not because it is typical of field-service or production scheduling software.

The scores are a snapshot from 2026-08-20, and the Index’s own review of Motion calls MCP and agent integration the fastest-moving criterion in the index. The Index also grades only what an automated collector could find, fetch and resolve in public; a capability a vendor ships but does not publish scores as absent, which is also what an agent would meet.

None of this measures whether an agent makes good decisions inside a system that passes. The test tells you whether the system lets an agent operate it safely, which is the precondition for finding out.

What changes in a back office buying decision

The question to put to a quoting, order, warehouse or scheduling vendor is no longer whether it has an API. In the Index’s commerce category, none of the 20 fully scored platforms scores below 10 of 20 on API-first design. The question is whether the API reaches the engine, reports every transition, publishes its contract, and lets you scope an agent to the transitions it should make.

The first of those is the one to check before anything else, because it is the one you cannot fix later. Events can be bridged, a schema can be transcribed, and a permission layer can sit in front of a system. An engine that only runs behind a screen stays there.

The ERP market reached the same point first: as we argued about NetSuite and SAP, the agent race there is decided by the API layer underneath, and headless ERP has become the route out of a closed core. The smaller systems around the ERP are next. A back office system whose decisions an agent cannot read is a system an agent will work around, and the workaround is usually a different vendor.