We believe an agent is only as dependable as the system it runs in. We are working toward a loop that finds the actions an agent can’t undo and proposes their checks, for your team to approve.

Previously in this series, we saw that putting AI agents into production takes both predictability and flexibility. Predictability comes from checks that can’t be skipped, at the points of no return, or PNRs: actions that can’t easily be undone. An agent can reach a PNR by many paths, but every one of them passes through the operating system. That is where OnRails holds the agent.

Today your team finds its PNRs and writes their checks, mostly by hand. That works for one workflow. But as models improve, agents will take on more of a company’s work, and the business rules will have to keep up with them.

We believe an agent is only as dependable as the system it runs in. So we are building a system that does this work with your team. It finds the PNRs in what your agents do, proposes a check for each and holds the agents there. Every run then feeds the next round, which closes the loop. And the loop compounds: each round starts from the PNRs and checks your team approved in the last. Once it runs, your team says what must hold and approves what the system proposes, instead of writing every check by hand.

How would the loop work?

Figure 1 · The loop

Every run feeds the next round, and your team approves what OnRails proposes.

1. Your agents run, and OnRails records each run. Every program an agent starts, every file it writes and every connection it opens goes into the run’s record.
2. OnRails finds the points of no return. From the record, and from the instructions your team already writes, such as AGENTS.md, it proposes the actions that can’t easily be undone. A payment applied, an email sent and a balance written off are such actions.
3. OnRails proposes a check for each. It starts from the checks your team already runs, such as a script that verifies the invoice matches.
4. Your team approves. A person reviews each PNR and its check before it holds, so the business rules stay your team’s.
5. OnRails holds the agents, and the next round begins. Every refusal goes into the record with its reason. From there, OnRails proposes sharper checks, and new PNRs as better models take on new work.

Agents bring the intelligence. OnRails brings the guarantees.

If you’re still making your agents follow a workflow, we’d love to work with you. Email us at hello@onrails.run.

An agent can reach a PNR by many paths, but every one of them passes through the operating system. That is where OnRails holds the agent, so no path goes around the PNR.

Previously in this series, we saw that putting AI agents into production takes both predictability and flexibility. Predictability never needed a predefined path, only checks that can’t be skipped. Those checks sit at the points of no return, or PNRs: actions that can’t easily be undone, such as applying a payment in the ERP. OnRails holds the agent at each PNR until its checks pass.

That left the harder 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 where should the hold live?

To answer that, we first need to know what those paths have in common. Each of them comes down to programs running on a machine. And no program can read a file, start another program or open a connection on its own. It has to ask the operating system’s kernel, through a system call.

An agent can use any number of tools and write any number of scripts, but an operating system has only so many system calls. Every path the agent takes passes through them. Engineers call a layer like this a “narrow waist.”

What is a narrow waist?

The term comes from networking. The internet carries every kind of application over every kind of network, and all of them meet at one protocol in between, IP. Drawn as layers, that design looks like an hourglass, with IP at its narrow waist.

An agent’s machine has a narrow waist too. Above it sit the tools, scripts and harnesses the agent might use, and below it the files, programs and connections they reach. The system calls sit in between, and that’s where OnRails holds the agent. A rule enforced there applies alike to everything above it, since the kernel sees processes, not tools or frameworks.

Is seeing every path enough?

A sandbox, such as a container, already works at the narrow waist, and it sees every path. But it decides each action on its own: whether the agent may read this file or reach that host. A PNR, though, depends on what happened before the action, such as whether the check passed on the latest invoice matches. The kernel shows each action as it happens, and keeps no record of what came before.

OnRails keeps that context itself, through information-flow control. Data carries a taint from its source, and the taint follows the data as it moves. A program that reads a file takes on the file’s taint, and a file it writes takes on the program’s. OnRails also keeps track of which program ran and which files changed after each check. So if a script the agent wrote changes the invoice matches after the check passed, OnRails knows the pass no longer counts. It holds the agent at the PNR until the check passes again.

Why not the prompt, a tool hook or a proxy?

Those are where teams put business rules today, and they are a good start. But each one misses something. The model weighs a prompt against everything else it reads, and even a strong one is sometimes confidently wrong. A tool hook sees the command that runs a script, not what the script goes on to do. A proxy on the network sees each request leave, not which program sent it or what that program read first. A hold at the narrow waist sees every path, and OnRails remembers what happened on each one.

That puts the business rules in the system around the agent, not in the model. Holding the agent at its PNRs is only the start of what that system can do.

So what are we working toward? That’s where the last part of this series picks up.

Predictability never needed a predefined path, only checks that can’t be skipped.

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.

Intelligence is no longer scarce, but guarantees are. Teams still choose between the flexibility of agents that plan and the predictability of predefined workflows, yet we think putting agents into production takes both.

Frontier models are making breakthroughs in science and mathematics, and intelligence has never been more abundant. Yet teams still argue over how much freedom to give their AI agents. One side writes every step in advance, as a predefined workflow. The other lets the agent plan its own steps. Both sides get something right.

Predefined workflows are predictable

A predefined workflow runs like an assembly line. Engineers lay out the steps in advance, and the model carries out each one as written. Every run takes the same path, so every output can be checked, and that is where the guarantees come from.

An accounts-receivable workflow matches each day’s customer payments to the invoices they settle, then applies them in the accounting system. Every run matches before it applies, so no payment is applied unmatched. And no step sends customers’ bank details anywhere but the accounting system.

The cost, of course, is the design effort up front, and brittleness when inputs vary in ways you didn’t anticipate. A customer pays three invoices with one wire, short by a disputed fee, and sends the remittance as a PDF no step expects. The payment drops into an exceptions queue for someone to work by hand.

Agents adapt, at the cost of predictability

An agent that plans its own steps takes cases like that in stride. Given the same wire, it reads the remittance, matches the invoices and logs the disputed fee, without anyone writing a step first. Each new model handles more of these cases.

But when the agent plans its own steps, the guarantees don’t come along. What the workflow enforced often becomes one more instruction in the agent’s AGENTS.md, weighed against everything else it reads. And the agent can be confidently wrong. It might decide a payment is close enough and skip the matching check. A script it wrote might upload a remittance, with the customer’s bank details, to an online PDF reader.

Both sides get something right

It can seem that teams have to pick one: the flexibility of an agent that plans, or the predictability of a predefined workflow. But it’s when their powers are combined that we get to build something outstanding. We think each side is right about a different thing. The workflow is right that the business rules must hold on every run. The agent is right that the steps don’t need to be written in advance.

So how do you make business rules hold firm when an agent plans its own steps? That’s where the next part of this series picks up.