How do you make business rules hold firm when an agent plans its own steps?

The first part of this series weighed two ways to run AI agents. Predefined workflows are predictable, at the cost of design effort up front and brittleness when inputs vary. Agents that plan their own steps are flexible, at the cost of predictability. We argued that putting agents into production takes both.

To keep that predictability while letting an agent plan, we first need to know what makes a predefined workflow predictable. The answer lies in how it’s built. The team that owns the workflow writes its steps in advance, and every run takes them in the same order. It matches each payment to its invoices, runs the team’s check on those matches, and only then applies the payment. So the check can’t be skipped.

However, an agent that plans its own steps has no such predefined order. It might skip the team’s check, or run it and then change which invoices a payment is matched to. Only its own word says the payment it applied was checked.

The order itself was never the business rule, though. The business rule is that no payment is applied until the team’s check passes on the latest invoice matches. The order was only a way to enforce it. What if we could confirm the rule held, and let the agent plan everything else?

Confirming every step would bring back the predefined workflow, one check at a time. Most of an agent’s work doesn’t need it: an invoice match can be revised, a draft rewritten. The confirmation is needed only where an action can’t easily be undone, or would be costly to get wrong. Applying a payment, sending a customer an email and writing off a balance are such actions. We call them “points of no return.”

What is a PNR?

The term comes from aviation. A flight’s point of no return, or PNR, is the place or moment after which it no longer has the fuel to turn back. A workflow’s PNR isn’t a place or a moment, though. It is an action whose effect can’t easily be undone, wherever it falls in the agent’s plan.

Your team decides which actions are PNRs. A good test is whether getting one wrong would harm customers or the company’s reputation in a way that can’t simply be reversed. And the answer often depends on the workflow: dropping a database table in one, sending out an email in another.

We think making business rules hold firm starts at these actions. Your team gives each PNR one or more checks that must hold before the agent can take the action. A check can be anything: a script that exits with status 0, an LLM judge’s approval, a person’s sign-off.

An agent at work, held at its points of no return

The agent applying customer payments meets three PNRs, each with a different kind of check. Applying a payment in the ERP is the first, and its check is a script that verifies which invoices the agent matched each payment to. Emailing a customer about a short payment is the second, checked by an LLM judge that compares the email with the remittance. Writing off a balance is the third, and it waits for a person’s sign-off.

Figure 1 · The pattern

The agent plans its own path. At each point of no return, OnRails holds it until the checks pass.

OnRails holds the agent at each PNR until its checks pass. It refuses the action and tells the agent why, so the agent can fix its work and try again. An agent that goes to apply a payment too early reads:

[OnRails] Operation blocked by rule `apply-after-check`.
- Target operation: run /opt/ar/bin/erp-post
- Reason: Apply payments only if the latest invoice matches passed the team’s check.

Why not just scope the agent’s permissions?

Scoped tokens are a good start, and teams should keep them. A token can let the agent apply payments in the ERP and nothing else. But it says who may act, not whether this action should happen now. The agent holds the same token whether its invoice matches passed the team’s check or not.

A team could build the check into the path, with a service that holds the ERP token and applies payments only after the check passes. But that is a predefined workflow again, with its design effort up front and its brittleness when inputs vary. With points of no return, each new business rule is one more check, and OnRails enforces it on whichever path the agent takes.

“Whichever path” is the hard part. An agent that plans its own steps can reach one PNR by many paths. It might use a tool it was given, a script it wrote, or a call straight to the ERP. A hold that sees only some of those paths leaves the PNR open.

So how do you make a check hold on every path an agent takes? That’s where the next part of this series picks up.