Determinism Is a Feature: Agents Need Rails, Not Vibes

There is a demo everyone in this industry has seen by now. An agent receives a vague instruction, "figures it out", chains a dozen tool calls, and lands the result while the room applauds. It is genuinely impressive. It is also, unedited, the exact behaviour that produces incident reports when you wire it to systems that matter.

Here is the position we run our company on: determinism is a feature. Production agents need rails, not vibes. The teams shipping agentic systems that survive contact with real operations have all converged on the same unfashionable architecture — a deterministic skeleton, with the model invoked only at the points where judgment genuinely lives. Everything else is engineering discipline that would have been recognisable to a good software team twenty years ago.

The industry sells the opposite, for reasons we will get to. But first, the argument.

Stop asking the model to be reliable

Large language models are probabilistic. That is not a flaw to be patched out of them — it is the property that makes them valuable. They handle ambiguity, interpret intent, draft, judge, classify the unclassifiable. Certainty was never on the label.

The engineering sin, then, is not "the model was wrong". Models will be wrong at some rate forever. The sin is deploying probability where the process needed certainty — letting a model decide how money moves, what gets sent, which record gets written, when a plain state machine could have decided it perfectly, every time, for free.

So invert the question. Do not ask "how do we make the model reliable?" Ask "how do we make the system reliable, given a component that is usefully unreliable?" That is a question engineers know how to answer. We have been building dependable systems out of undependable parts — networks, disks, humans — for the entire history of computing.

The architecture: skeleton and judgment nodes

Every agentic system we ship at Gravitnomad decomposes the same way:

• The skeleton is code. Data movement, validation, formatting, retries, idempotency, state transitions, scheduling, permissions, logging. Typed, versioned, unit-tested, code-reviewed. If a step can be specified, it must be specified — a model call where an if statement belongs is not intelligence, it is negligence with better marketing.
• Judgment nodes are model calls, deliberately placed. "Which category is this request?" "Draft the reply to this unusual email." "Does this clause deviate from our standard terms, and how?" Each node has a bounded job, receives curated context, and returns output into a schema.
• Nothing a judgment node says is trusted raw. Outputs are validated against schemas and business rules before the skeleton acts on them. A malformed or out-of-policy answer does not crash the flow or, worse, flow through it — it triggers a retry, a fallback, or a human.
• Consequences get gates. Anything that leaves the building — an email, a payment, a published page — passes a human approval gate until the eval history has earned it more autonomy. Autonomy is granted like a promotion: gradually, on evidence.

Use the model where judgment lives. Everywhere else, write code. Boring code is the most advanced agent technology we have.

Around the skeleton sit the guardrails that make the word mean something: allowlisted actions (the agent can do these twelve things and structurally nothing else), budget caps on spend and iterations, kill switches a human can pull, and traces — every step, every input, every decision logged, so "what happened at 03:14 on Sunday" is a query, not a séance.

Evals: regression tests for judgment

The skeleton is covered by ordinary tests. The judgment nodes need their own instrument, and this is where most agent projects are flying blind: evaluation suites.

For every judgment node, we keep a golden set — real historical cases with known-good answers, plus the adversarial ones: the ambiguous email, the contract with the weird clause, the input designed to confuse. Every change to the system — a prompt tweak, a model swap, a new context source — runs against the suite before it ships. "Does it still work?" becomes a number, not a feeling.

This is also what makes model churn boring, in the best way. When a better or cheaper model appears — every quarter, reliably — you swap it behind the judgment nodes, run the evals, and promote it if it passes. The system's guarantees live in the rails and the tests, not in any vendor's release notes. That is the architecture answer to the mess we described in The Demo-to-Production Chasm: demos showcase the model's ceiling; production is about raising the system's floor.

Why the industry sells vibes

If rails are so obviously right, why does the market keep buying freestyle?

Because autonomy demos raise rounds and rails do not. "Fully autonomous agent replaces your ops team" is a fundable sentence. "Deterministic workflow engine with bounded model calls, validators and an approval queue" is merely true. Vendors demo the ceiling — the dazzling best case. You, the buyer, will operate the floor — the worst case at volume on a Friday evening. The gap between those two is where agent projects die, and no benchmark measures it.

There is a second, softer reason: rails require understanding the process you are automating. Freestyle lets everyone skip the uncomfortable work of specifying what "correct" means. The vibes are load-bearing precisely because the spec is missing.

What this looks like in practice

House rule: no invented clients, no fictional uptime figures. Our own systems, which we operate daily, and one archetype.

The engine behind this website is the purest example. Our multi-tenant engine renders entire sites — pages, sections, media, articles — from structured brand data. Generation and judgment (what to say, how the brand sounds) happen upstream, with models involved; the rendering layer itself is deliberately deterministic. Same data in, same site out, every time, testable. When something looks wrong, we know which half to interrogate.

The publishing hub that produced the article you are reading runs one brief through drafting agents into a deterministic pipeline — formatting, cross-linking, scheduling — with a human approval gate before anything goes public. The creative layer is probabilistic; nothing probabilistic touches "publish".

The assistant on this site answers from retrieval over our actual pages with persistent memory, and its most important behaviour is deterministic: when grounding is weak, it says so and offers a human instead of improvising. (Memory, incidentally, is the other half of what makes agents dependable — the argument of Agents Need Memory, Not Bigger Models.)

The archetype: an invoice-intake agent at a mid-sized firm. The skeleton ingests, parses, matches against purchase orders and routes; a judgment node handles only the genuinely ambiguous matches; anything below a confidence threshold, above a value threshold, or outside policy lands in a human queue with full context. The agent never approves its own edge cases. This is what agentic automation looks like when it expects to pass an audit — and it is the coordination pattern we generalise in One Orchestrator, Many Hands.

How much determinism is too much?

Intellectual honesty requires the inverse warning: rails can over-tighten. If you enumerate every case in code and leave the model nothing but multiple-choice questions, you have rebuilt no-code brittleness in a better language — and you will feel it as a new kind of failure: the system that is never wrong and never useful.

The working heuristic we apply: consequences deterministic, interpretation probabilistic. Anything that moves money, sends messages or writes records runs on rails with gates. But the reading of a messy situation — what does this email actually ask, what kind of document is this, how should this unusual request be framed — deserves a wide lane, because a narrow one just relocates the ambiguity onto a human queue.

Context changes the dial too. Exploration workloads — research, drafting, options analysis — can freestyle safely, because their output is text a human will judge, not an action the world will absorb. Execution workloads cannot.

And watch for the over-tightening symptoms, because they are measurable: judgment nodes answering "other" at high rates, humans routinely overriding validators, exception queues filling with false positives. Each one means the walls moved in too far. The craft is not maximum rails. It is rails exactly where consequences live, and trusted judgment everywhere else.

Trust is predictability under stress

Teams do not adopt agents because the demo was magical. They adopt agents whose failure modes are known, bounded and visible — systems that fail the way a good colleague fails: loudly, early, and into a process that catches it. That property is not emergent. It is designed, and the design is called rails.

If you are evaluating an agentic system — ours or anyone's — ask one question first: "show me what happens when it is wrong." If the answer is a schema, a threshold, a queue and a trace, you are talking to engineers. If the answer is a demo, you are talking to a pitch. We are happy to be asked the hard version of that question: talk to us and bring your most consequence-laden workflow. We will show you the boring parts first — on our systems page, the boring parts are the pitch.