Building Deterministic Infrastructure for Non-Deterministic AI Agents [Testμ 2026]

From Text Output to Real Actions

Two or three years ago, models mostly returned text. A human read the output, copied what was useful, and made the decision, so failures were visible before anything changed state.

In the agentic setup, the model is a decision-making component wired to real tools. It selects the tool, the runtime executes the action, and a wrong decision can mutate infrastructure, change data, move money, or affect critical customer state.

Nishant was clear that the goal is not a deterministic model. Temperature controls and structured outputs help, but the model remains a probabilistic planner, so the engineering job is to place it inside a deterministic execution envelope.

His test for whether that envelope exists is a set of questions an engineer should be able to answer after any agent run:

• What did the agent believe when it was executing, and what action did it request?
• What schema did that action satisfy, and what policy allowed the decision?
• Which tools did it have access to, and which did it actually execute?
• What state changed, and how would you replay or roll back the workflow?

He condensed that into a production rule: every agent action should be reconstructible as a typed request, together with a policy decision, a tool result, and a durable state transition.

How Agents Break in Production

Nishant argued that every production architecture should be driven by the incidents it has to survive, so he started with failure modes rather than capabilities.

• Wrong action - the agent picks a tool that is valid but inappropriate for the situation it is actually in.
• Retry storms - a failed call is reattempted without a bound, multiplying load on an already degraded system.
• Cost spiral - the loop keeps expanding context and fanning out, and spend climbs with no ceiling.
• Silent success - the run reports completion while the underlying outcome was never achieved.

None of those ingredients are new. Software systems have had retries, state machines, and permissions for decades, and what agents add on top is ambiguous planning and self-directed tool selection.

The rollout example makes the composition concrete. With unbounded retries and broad permissions, an ambiguous failure stops being a contained error and becomes a cascading incident for the organisation.

Sources of Non-Determinism

Non-determinism is not only a question of random seeds. Nishant mapped the points where it enters an agentic system: prompt context, external tool calls, concurrent execution, state compaction when the context window is close to full, and human feedback.

Those points sit inside an orchestrator loop. Model output leads to tool execution, tool output is fed back into the model, and the loop continues, with every step offering another place for uncertainty to amplify.

The exercise he recommended is to ask, at each layer, where the deterministic contract lives:

Asking those questions layer by layer, he said, reduces non-determinism to a very small residue rather than eliminating it outright.

The Deterministic Shell

The core architectural idea of the talk is a shell placed around the agent. The model transforms natural language intent into a candidate plan, and the runtime owns the semantics of validation, execution, retries, and recording.

Nishant drew the analogy to ordinary distributed systems practice. A client is not trusted to mutate databases directly, so the design puts APIs, an authorization layer, idempotency, transactions, and audit logs in the way.

An agent deserves the same discipline, with additional controls layered on because this particular caller is probabilistic. That splits responsibilities cleanly between the two halves of the system.

• The model - proposes a plan, explains its reasoning, and adapts when circumstances change.
• The infrastructure - constrains the output, executes it, verifies the result, persists the record, and escalates to a human when required.

Eight Patterns for Agent Infrastructure

The middle of the session worked through eight patterns that turn the shell from a diagram into something a team can build.

Note: Agent evals only work if something scores the behaviour. TestMu AI Agent Testing runs autonomous testing agents against chat, voice, and phone agents and scores them on hallucination, bias, completeness, and context awareness. Try it free!

Reference Architecture for an Agent Runtime

Nishant then assembled the patterns into a reference runtime, reading left to right:

• User intent enters as a normalised task envelope.
• The planner proposes bounded steps rather than an open-ended plan.
• The validator checks schema, tool availability, and semantic constraints.
• The policy engine decides whether to allow, deny, request more context, or require approval.
• The tool broker mints credentials scoped to that agent and that action, executing in a sandbox wherever possible.
• Every step is written to an append-only trace and state store.

He drew out three properties that fall out of the design. The security property is that the model never directly holds broad production credentials.

The reliability property is that orchestration state, retries, and verification are owned by deterministic services. The operational property is that every agent run is replayable enough to debug and audit.

Comparing the two paths for a deployment remediation agent makes the point sharply. The unsafe path hands the agent broad credentials and treats each model response as a command, while the deterministic path treats each response as a proposal that a validator, policy engine, approval gate, idempotent executor, and verifier each narrow.

The model can be identical in both paths. The production outcome differs because the execution fabric differs, which is the argument for infrastructure-first agent safety.

Progressive Autonomy

The rollout model Nishant has been using follows a graded path: suggestions first, then drafts where the agent prepares artifacts or commands, then dry runs, then approval-gated production, and finally tightly bounded atomic execution.

Jumping straight from chatbot to autonomous production operator skips every stage where you would have learned something. Each promotion should clear objective criteria rather than a product decision.

• Eval results - the agent passes its evaluation suite at the current stage before moving up.
• Observed incident rate - real incidents attributable to the agent stay within an acceptable band.
• Approval rate - human reviewers are agreeing with the agent’s proposals often enough to justify loosening the gate.
• Rollback success - reversals work when they are needed, not just in theory.
• Budget stability - token, step, and spend budgets hold steady rather than drifting upward.
• Audit completeness - traces are complete enough to reconstruct what happened.

Framed that way, autonomy is an operational maturity level rather than a launch switch.

Q & A Session

The session ran to time without a live Q&A, and host Kavita Joshi, Senior Marketing Specialist at TestMu AI, closed by directing audience questions to the TestMu AI community channels. These are the questions the talk itself sets up, and how Nishant answered them.

• Should teams wait for models to become deterministic?

  Nishant: No. Design the surrounding infrastructure as if the model will be probabilistic, occasionally wrong, and sometimes overconfident. Even with temperature control and structured outputs, the model is still a probabilistic planner, so the engineering goal is to place it inside a deterministic execution envelope rather than to fix the model.

• What makes agent failures different from ordinary software failures?

  Nishant: The ingredients are familiar, since software systems already have retries, state machines, and permissions. Agents add ambiguous planning and self-directed tool selection on top. A failed rollout that would make a human stop and ask why can instead trigger an agent to retry, roll back, and run extra diagnostics until an ambiguous failure becomes a cascading incident.

• Where should a team start if agents are already in production?

  Nishant: Start with two checklist questions. Are retries centralised, bounded, and idempotent, and can you replay a trace from intent through the policy decision and tool result to the final outcome? A safe agent platform is not a better prompt; it is a runtime, a policy layer, a workflow engine, and an operating model.

His closing takeaway was that the future of agents is systems engineering rather than model work alone, and that autonomy should evolve gradually behind valves, canaries, approvals, and rollbacks. Agents can be creative in planning, but never creative in production control.

Kavita closed the session on the same note, observing that determinism has to live in the infrastructure rather than the model.

This session was part of day one of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.