Deterministic by Default: When Not to Build the Agent

Every roadmap review for an AI system eventually reaches the same slide: "Phase 2 — the agent." It's usually framed as inevitable, the natural next step once retrieval and generation are working. Sometimes it is the right next step. Often, on the systems that matter most, it isn't — and saying so, in writing, with reasoning attached, is a stronger engineering decision than shipping the agent would have been.

The Asymmetry That Matters

An agent earns its keep when a task genuinely benefits from adaptive, multi-step reasoning: unpredictable inputs, a large space of possible actions, a workflow that can't be fully enumerated in advance. That's real value, and plenty of systems fit that description.

But high-stakes systems — the ones making determinations that get appealed, audited, or cited as the basis for a decision affecting someone's benefits, employment, or legal standing — have a different risk profile. The cost of an agent taking a slightly wrong action isn't a bad user experience. It's a decision that has to be unwound, explained, and potentially defended. That asymmetry changes the math on whether adaptive control flow is worth what it costs in auditability.

Note: This is not an argument that agents are unsafe categorically. It's an argument that the bar for giving an LLM control over what happens next, versus control over what to say, should scale with the cost of being wrong.

Auditability and Reproducibility as First-Class Requirements

A deterministic pipeline — retrieval, then generation, then a rules-based decision layer — has a property that's easy to undervalue until you need it: given the same inputs, it produces the same trace, every time. When a decision gets questioned six months later, you can reconstruct exactly what happened and why, because the "why" was never delegated to a model deciding its own next step at runtime.

An agent's reasoning trace is not the same kind of artifact. It can genuinely explain what happened, but it explains a process that was itself non-deterministic — the same inputs might not produce the same sequence of tool calls twice. For a system where "explain exactly what happened and why, reproducibly" is a hard requirement rather than a nice-to-have, that's a real cost, not a stylistic preference.

Keeping the Injection Surface Small

There's a security argument here too, and it's more specific than "LLMs can be tricked." In a strict-grounding, deterministic pipeline, untrusted input — a scanned document, an inbound email, OCR'd text — can corrupt an answer. That's a real risk, and it's exactly what a grounding gate exists to catch before the answer reaches anyone.

Give an LLM control over tool calls, and the same untrusted input can potentially corrupt what the system does, not just what it says. Prompt injection embedded in a document a model retrieves and reasons over becomes an attempt to steer actions, not just steer a paragraph of output. Keeping tool-calling out of the critical path for untrusted-input systems keeps that entire attack class off the table — not mitigated, off the table, because there's no control-flow surface for it to target.

That last comment is the design posture in one line: uncertain, it escalates. It never mutates state or takes a further autonomous action on its own judgment. A single bounded conditional re-retrieval — a rule, not a model deciding to try again — can close most of the gap an agent would otherwise be reached for, without opening the control-flow surface up at all.

Writing the Decision Down

The organizations that get this right don't leave "we didn't build the agent" as an absence. They write it as a decision record: what was evaluated, what the agent would have bought, what it would have cost in auditability and attack surface, and why the deterministic path won for this specific system, at this specific risk level, right now.

Tip: Frame the deferral as evaluated-and-deferred, not not-yet-built. "We prototyped an agent harness offline, benchmarked it against the deterministic path, and it didn't clear the bar for the live system" is a fundamentally different — and stronger — statement than silence on the roadmap slide.

This matters beyond the immediate system. A documented ADR that concludes "we deliberately kept this deterministic, and here's the evidence" is a better answer under technical scrutiny than an implied claim that agentic capability was simply out of scope. It shows the team evaluated the harder path and made a defensible call, which is exactly the judgment a regulated environment needs to see.

Where the Agent Still Belongs

None of this is an argument against building agentic capability at all. The right home for it, on a high-stakes system, is often a shadow or offline prototype: run the agent harness against historical cases, score it against the same evaluation set the deterministic pipeline is held to, and let the evidence — not the roadmap's momentum — decide whether it ever touches the live path. Azure AI Foundry's evaluation tooling makes this comparison concrete rather than qualitative: same eval set, two pipelines, a scored answer to "did the agent actually do better," instead of an assumption that adaptive reasoning is automatically an upgrade.

Conclusion

Not every system should get an agent, and the systems that most need to be right — the ones with real consequences for the people on the other end of the decision — are frequently the ones where restraint is the harder, better call. Deterministic by default isn't a failure to keep up with agentic AI. Done well, with the evidence to back it, it's the more disciplined engineering decision, and it reads that way to anyone who actually checks the work.