3 m read
March 30, 2026 Agentic Workflows

Support bot approved the refund. How did it get past finance?

You already have a finance workflow that can issue customer credits. You add a second one in support chat because the first route keeps missing support edge cases, and reps need to move faster with customers.

Now both routes can reach the same money outcome. Both can look at the same account. But each workflow carries its own policy in its own instructions, and nothing non-skippable sits in front of the credit action.

You expect both to respect the same floor:

  • who asked for the credit
  • why it is being requested
  • who approved it
  • what the account looks like right now

Then finance reads the chat reply

The support side looks fine at first. A rep sees a clean answer, the customer is happy, and the case moves on.

I approved a customer credit for the delay. Reason: repeat inconvenience. The account is updated.

The record behind that reply can still look neat enough to pass a quick review:

{
  "action": "issue_credit",
  "actor": "support_ai",
  "reason": "repeat inconvenience",
  "approval": null
}

What the agent didn’t do:

  1. It did not tie the credit to a named requester.
  2. The reason is just text, not tied to an approved reason.
  3. It did not carry a current approval record; the field is null.
  4. It did not include the live account state at the time of the decision.
  5. It did not force the support and finance paths to answer the same credit case in the same way.

Later, finance looks at the same case and says the regular process would have blocked that credit.

That last part is the one teams miss.

The mistake is not just that the support workflow forgot a check. The bigger problem is that support and finance can both produce the same credit action, while each reads the rule through different instructions.

Adding one more route is what breaks the policy

With one route to credits, you are mostly judging one place that says yes or no.

Add a new workflow that does the same thing, and now the same customer case can receive two different answers without any model changes in the old path.

State Workflows that can issue credits What finance is now exposed to
Before 1 One place decides yes or no
After adding support chat 2 Two places can disagree on the same case

If the new route is even a little looser than the old one, and people or routers can still reach it, traffic starts to collect there.

Tightening five prompts elsewhere does not matter much if one reachable path can still issue the credit with fewer checks.

So at company scale, the real risk tracks something very plain: how many separately maintained places can approve the same money action, how reachable they are, and how much each can touch. It does not track the review score of any one prompt very well.

Why the fast path becomes the real rule

Your policy is not the text inside each workflow; it is the loosest reachable path to the same state change.

That is why pasting policies into prompts, relying on shared context alone, or trusting the model to check itself stops holding once too many overlapping routes can touch the same credit or refund action.

Raw workflow counts and after-the-fact failures miss it too, because the real issue is which routes overlap on the same action and which one is loosest.

In safety systems, this is called a mandatory floor constraint: every path to a dangerous action must pass the same hard minimum check.

In Policy-Adherent Enterprise Agentic Workflows, every route to money, access, or customer data means the same non-skippable gate sees who asked, why, who approved it, and the current state first.

Once you see that, the question stops being whether one assistant followed its prompt and becomes whether any other route can still reach the same outcome on looser terms.

If your team needs engineers who put one non-skippable gate in front of shared money or data actions, that’s what we do at InTheValley.

InTheValley
Latest posts by InTheValley (see all)

Leave a Reply