AI alone closes nothing

Fluency is the part that is already finished

What improved over the last few years is drafting: the sentence, the register, the summary of a policy document, the reply in the customer's language. Those are language problems, and they are largely settled.

What did not improve is the rest of a refund decision. Whether this order shipped. Whether it is inside the return window. Whether this customer already received two courtesy replacements. Whether the brand allows a partial refund on a sale item. Whether the system may move the money at all.

Four of those are reads against systems the model does not own. The fifth is a permission. None of the five improves when the model improves. A model that invents a return window is not writing badly — it is answering a question it had no source for. Fluency guarantees the sentence, never the fact behind it.

The industry shorthand hides this. "The AI handles tier 1" names a volume band instead of naming what the cases in it require. A where-is-my-order question and a $340 refund on a damaged order sit in the same band and have nothing in common. One is a lookup. The other is a decision, a limit, and the right to execute.

Permitted is not the same as executable

Give the system a complete rule set and the problem persists, because two separate layers are in play. The policy layer says what the brand allows for this case and this customer. The execution layer is a connector into a specific system — the store, the helpdesk, the carrier. The two come apart routinely.

A brand's rule may authorize a replacement shipment for a damaged item. Sending a replacement is a warehouse operation. Where no connector reaches the warehouse, the action is permitted and not executable, and those are two different states that no confidence value distinguishes.

The weak design collapses them. The system reads the rule, sees the action allowed, and tells the customer the replacement is on the way. The promise has no mechanism behind it, and the operation finds out days later, from the customer.

Keeping them apart has a corollary about record-keeping. Razviel's architecture treats a completed action as something the external system confirms, not something the model states: a resolution recorded without that confirmation is a claim, not an outcome. The same rule governs the fields around it — where the source has no value, the record is designed to leave the field blank and flag it. A declared blank can be audited. An invented number cannot.

Context is the other half, and it does not come from the model

Authority settles whether the system may act. Context settles whether the action applies. They are independent, and closing a case needs both.

The facts that decide a refund live in the store, in the conversation history, in the carrier's tracking record, and sometimes in a photo the customer attached. None of them are in the model's weights. They are reads performed at the moment of decision, against systems the brand owns.

Order of operations decides whether that helps. Razviel's architecture captures context before any route is chosen — before resolving and before escalating, unconditionally. A decision made without it is a guess with better grammar, and an escalation made without it hands the next party the work of finding out.

Where the facts stay inconclusive, the honest behavior is to stop rather than resolve. NIST's framework treats that as ordinary practice rather than an admission of defeat: "AI risk management efforts should prioritize the minimization of potential negative impacts, and may need to include human intervention in cases where the AI system cannot detect or correct errors."

Which describes the human tier's real job, and not the one the market usually advertises. A human operator is not there because the model wrote badly. They are there to apply judgment to a case that arrived assembled — the order, the history, the policy cell consulted, what was attempted, and the reason it is in front of them. Validation, not restart.

The takeaway

A model closes the language of a support case, not the case. Closing it takes two layers outside the model: one that holds the right to act, and one that reads the facts the decision depends on at the moment of the decision. Neither arrives with a larger model, and both have to exist before the model is allowed near the money. For a Shopify Plus brand, the question about any AI deployment is not how well it writes. It is where those two layers live.

What to check, in your own stack or in any vendor’s:

1. Where the right to act lives. A refund limit written into a prompt is advice to the model, not a control on the action. The check belongs in code on the path to the write, and a vendor can name the component that runs it.
2. What the decision reads, and when. Shipment status, the return window, the customer’s history and the brand’s policy live in the store, the helpdesk and the terms — never in the model’s weights. They are read at the moment of decision, before resolving and before escalating.
3. Permitted versus executable. For each action the policy allows, a connector either reaches the system that carries it out or does not. An action that is permitted and not executable is a state the system knows about, never a promise it makes to the customer.
4. What counts as done. A resolution is complete when the external system confirms it, not when the model says so. A field with no source is left blank and flagged rather than filled in.
5. What happens when the facts run out. Where the facts stay inconclusive, the system stops and hands a person the case assembled — the order, the history, the policy cell consulted, what was attempted. Resolving anyway is a guess with better grammar.

Without those layers a support agent does not fail loudly — it answers everything, promises what it cannot deliver, and leaves no record of which rule it believed it was following.