Where AI can actinside an order
The useful version of “where should AI act?” is not a policy — it is a decision made one order at a time. This is how that decision was bounded on Strata: what the AI is allowed to do, where a person stays in the loop, and why one layer of it was designed and then held back.
The order, and the decision it forces
Strata coordinates execution in contract office furniture, where a few manufacturers sell through many dealers who don’t know each other. A single order crosses those organizations, and no participant sees the whole of it. Somewhere in that crossing, work stalls: a shipment slips, a price and an inventory signal disagree, a quote needs to become a purchase order, an exception needs an owner.
Each of those is a decision waiting for someone. The platform can see them all at once and rank them; a person still has to choose what happens next. “Where can AI act?” is really that question, asked at the level of one order: which of these decisions can be prioritized and proposed automatically, and which have to be reviewed by a person before anything moves.
What structures the decision
The boundary is not drawn in prose. It is drawn by the same three things the platform already models for every order.
Roles
Operators, managers and admins see different surfaces of the same order. Who is looking decides which actions are even offered, and which ones need a second pair of eyes.
States
The order moves through explicit states — quoted, ordered, processed, shipped, delivered, plus the exception states beside them. The UI reflects the real workflow state, so an action is only available when the state allows it.
Permissions
Approval groups, delegation rules, and hierarchical and parallel routing decide who can authorize what. The AI proposes inside those permissions; it never widens them.
The exception, and the moment it needs a person
On the operator’s home surface, the discrepancies for the day are queued and tagged by severity. The AI has already done the ranking — it puts the high-severity mismatch above the low one, and offers a way to resolve each: fix it, fix part of it, or assign it to someone.
That is as far as it goes on its own. Applying a resolution that changes what a customer is charged, what ships, or what a contract commits to is an impact decision, and an impact decision is reviewed by a person before it takes effect. The review is not a fallback for when the AI is unsure; it is where the boundary sits by design, for the whole class of decision, every time.
The design artifact, and the decision it recorded
The flow behind this was mapped end to end before any of it was designed as screens — the journey across dealer, rep, manufacturer, quoting, contract and cash ordering, and the points where it breaks. That map is what made the boundary decidable: you cannot say where AI should stop until you can see every step it might touch.
From it came the authorized decision, stated plainly so engineering and leadership could hold each other to it: the AI prioritizes and proposes; a person reviews that prioritization and the impact decisions during the order. Everything below is a consequence of that one line.
See the research this decision was built on →L2 shipped. L3 was designed and held back.
I evaluate AI automation across three levels. What separates them is how much reasoning a step is allowed to do — which is the same as asking how much of the decision a person is still holding.
Workflow automation
Fixed rules, point A to point B, nothing reasoning about anything. In the B2B2C layer, the two boundary events — taking payment and confirming the legal commitment — were kept deterministic at L1 on purpose.
Agentic integration
An LLM agent interprets the context of one step and makes a bounded decision inside it — here, prioritizing discrepancies and routing them. It shipped where the decision surface was narrow enough to trust and a person still reviews the impact decisions.
Adaptive agent loops
Agents weighing options in real time against historical context, SLA data and permission scopes, closing the loop with minimal human review. It was designed, with the audit trails and permission scopes it would need. It was then held back — and holding it back is the decision, not a stage still pending. It stays out until that governance is mature enough to remove the human review step safely.
The point of the framework is what it refuses to promote. L3 was ready as a design and is not in production, because the thing that would make it safe — audit trails and permission scopes strong enough to trust without a person watching — was not yet there.
The frames behind it
Five interface frames from the work, authorised for this piece. They show how the decision reads on the surface — the queue, the signals, the order record. They are design frames with placeholder data, not production screenshots, and not evidence of any metric or technical implementation.
Why this is the part worth showing
Anyone can say AI should keep humans in the loop. The work is deciding which decisions, at what point in a real order, and then being willing to hold a finished design back until the thing that would make it safe actually exists.
Why holding L3 back was the decision:Read the full article on Medium
I write about these decisions in more depth.AI workflow audit, fixed scope:Check the price on Contra