A customer asks for a refund
A customer writes in: "I want my money back for order #1234."
It feels like one task. Something you could hand to an AI with a single instruction: handle this refund.
But think about what a good human support agent actually does:
- Reads the message and understands what the customer wants.
- Looks up the order. Does it exist? What was paid?
- Checks the refund policy. Is it within the window? Was it already refunded?
- Issues the refund.
- Writes back to the customer and tells them what happened.
Five actions. Only two of them — reading and writing — are "thinking." The other three require access to your systems: your order database, your policy rules, your payment provider.
That split is the entire point of this post.
The brilliant hire with no keys to the building
AI is like a brilliant new support hire who just walked in on day one.
They read fast. They write beautifully. Their judgment is surprisingly good.
But they have no keys to the building. They cannot look up an order. They cannot check your policy database. And you would never, on day one, hand them the company card.
Your backend holds the keys. It knows the orders, enforces the policies, and moves the money.
So a useful AI support agent has to keep asking your backend for help. Not once — repeatedly, at every step where facts or actions are needed.
That is why AI needs to call your backend more than once.
Why "asking once" is not enough
You might wonder: can the AI not just gather everything in one go?
If the AI only talks to your systems once, you have two options, and both are bad:
- Trust it blindly. The AI says "approve $42" and your backend issues the refund without checking anything. One hallucinated order number later, you are refunding orders that do not exist.
- Do the work yourself. Your team looks up the order, checks the policy, and prepares everything before calling the AI. Now the AI is just a fancy email writer — and you are still doing the hard parts by hand.
Real automation lives in between: the AI and your backend take turns. The AI judges. Your backend verifies and acts. Then the AI picks up the confirmed facts and continues.
What a real refund flow looks like
Here is the refund story again, this time with the AI and your backend taking turns:
Notice the ordering. The customer reply is written after the refund is confirmed — not before.
That is not a small detail. It means the AI writes "your refund of $42.00 is on its way" instead of "we will process your refund." One is a fact. The other is a promise your systems have not kept yet. Customers forgive a lot; they do not forgive broken promises about money.
This is the deeper reason for multiple backend calls: each call lets the AI build on verified reality instead of its own guesses.
The two kinds of steps
Look at the flow again. There are really two kinds of steps:
- Backend steps — your systems do something (look up an order, issue a refund, send a message) and report back. That report-back has a name: a callback — your backend phoning home to say the job is done.
- AI steps — a model does the thinking work (reading the request, drafting the reply), using everything the backend has confirmed so far.
The information accumulates as the flow runs. Once the refund is confirmed, that confirmation — the exact amount, the reference ID — travels with everything that follows. That is how the reply-writing AI can state the precise amount with confidence.
And the identifiers you started with — the order ID, the customer ID — ride along untouched through every step, so nothing loses track of who this is about.
How ModelRiver makes this easy
Wiring this up yourself means queues, retries, timeouts, and a lot of glue code. This is exactly what ModelRiver's backend pipeline does for you.
In ModelRiver, you save your AI setup as a workflow — the model, the instructions, the expected shape of the answer. Then you attach a pipeline: an ordered to-do list of steps that runs after the AI responds. Some steps call your backend and wait for the callback. Some steps call another AI.
The refund flow above is two workflows and four steps:
refund_triage— the AI that reads the request and recommends approve, deny, or escalate, with a reason.refund_response_writer— the second AI that writes the customer reply once the facts are settled.- Steps 1, 2, and 4 — your backend: verify the order, issue the refund, deliver the reply.
The guardrails are built in, and they are worth saying out loud:
- Your backend always gets the first and last word. Every pipeline starts and ends with a backend step. The AI drafts; your systems verify, execute, and deliver. Nothing reaches the customer unless your backend sends it.
- Money moves only inside your backend, on facts your backend verified.
- Duplicate or out-of-order reports are safely ignored. If your backend retries a callback, or a response arrives for the wrong step, the pipeline refuses it — so a retry can never double-refund a customer.
For the engineers, this is what the AI-drafted reply looks like when it reaches your backend for delivery:
Everything else — the envelopes, the retries, the status updates — is handled by the platform and documented in the links below.
The one-line takeaway
Useful AI is not one smart call. It is a conversation between AI judgment and your backend's facts.
Judge, verify, act, write, deliver. That rhythm — AI and backend taking turns — is what separates a demo that impresses investors from automation you would trust with a customer's money.
Next steps
- Backend pipeline — how async AI, webhooks, callbacks, and real-time delivery fit together
- Multi-step pipelines — build a flow like the refund example, step by step
- Backend pipeline architecture — the engineering deep-dive behind all of this
If you want the engineering deep-dive on the architecture underneath this — webhooks, callbacks, retries, and real-time delivery — start with the backend pipeline architecture post. If you want to build the refund flow from this post, the multi-step pipelines guide walks through it step by step.