A train doesn't choose to stay on the rails.
It can't leave them.
That's the model. Not a colleague you persuade. An engine you route down a track you laid before it ever started moving.
You lay three rails in code, up front, every time.
The context rail: what it sees.
The tool surface rail: what it can call.
The action rail: what it's allowed to actually do.
Decide those three and the model can't wander off, because there's nowhere off to go.
The first rail: what it sees
The model knows what you put in front of it.
Nothing else.
So stop dumping.
Here's the trap. You paste a 10,000-word board transcript and tell it: "find the revenue figures, work out the growth, summarise."
I've watched this in government departments. ASX-listed firms. Same story, different logo on the slide deck.
The thing burns thousands of tokens wading through small talk, fumbles the arithmetic one time in five, and you pay for the wrong answer at the wrong price.
The rail fixes it before the model ever wakes up.
Code finds the two figures, runs the division, hands back "14.2%".
The model gets the finished fact, not the haystack.
Curate the context. Don't tip the whole bucket in.
The tool that doesn't exist can't be called
A paragraph of pleading is not a control.
"Only read from prod, never write." "Don't email the customer without sign-off."
Sounds fine in the demo.
Three weeks in, on an edge case, it writes. It emails.
The instruction was a sticky note on the problem.
Real constraint lives a layer down.
If there's no send-email tool in the registry, no function to call, the model cannot send an email. Not because you asked. Because the verb isn't in its world.
So don't hand it the warehouse and a warning label.
Hand it the four moves this task needs. Give the database connection read-only credentials. Let the absent tools do the refusing.
You don't talk the model out of the action. You make it unable to.
The model proposes; the rail disposes
Don't hand the model the whole job.
"Summarise this" is four decisions you've given away: what to cover, what to cut, how long, what to call it.
Instead: "Quarterly growth came in at 14.2%. Write the one-paragraph summary explaining the trend."
One move, scoped.
Now every token goes to the language and the judgment, the only thing it beats my code at. None of it goes to inventing the shape of its own work.
Then catch it on the way out.
The model returns structured output. Deterministic code checks that 14.2% is still 14.2%, that the paragraph is a paragraph, that the rules held. Before anything ships.
The model proposes. The rail disposes.
Because exact work fails unpredictably, and failures stack.
95% per step, four steps deep, gives you 81% system reliability.
Wrong one in five. In enterprise, unusable.
The validation rail is what stops a fumble becoming a shipped error.
State is a rail, too
You laid three clean rails for a single call: context, tools, action.
Then you spin up an agent loop and hand the whole job back to the model to hold in its head.
What step it's on. What's done. What's left.
Every rail you just laid, gone.
Now the track lives in a context window that rots the longer it runs. It forgets. It repeats a step. It drifts off the line.
So lay the fourth rail in plain code.
An external state machine owns the progress. Each turn you hand the model only the slice it needs to act on right now, nothing else.
You're not building a thinker keeping a diary of its own progress.
You're building a worker you hand the next instruction.
Same discipline as the rest. The model decides nothing it doesn't have to.
Lay track
I stopped asking what the model can do years ago.
It can do almost anything. Slowly, expensively, and wrong in ways you won't catch until a customer does.
Wrong question.
The right one is narrower: where does the track go?
Decide the context. Decide the tools. Decide the action, the validation, who holds the state.
Write it down in code. Then hand the model the one stretch nothing else can run.
The rails aren't there to slow it down. They're what let the most expensive, least predictable part of your system move fast without coming off the track.
Build the track, and the engine ships.
Leave it off the rails and you don't have a product. You have a derailment with a demo.