By NHI Mgmt Group Editorial TeamBased on TruFoundry: “Deterministic vs Agentic Workflows: Lessons from Building a Shopping Assistant” (June 30, 2026)

TL;DR: Building a shopping assistant shows that forcing every interaction through agentic reasoning adds latency, cost, and control risk when clear intents can be handled deterministically, while open-ended, multi-step tasks still need a ReAct-style loop, TruFoundry’s analysis finds. TrueFoundry’s analysis also shows that state must be organised around workflows and explicit context, not just conversation history, to keep multi-product assistants reliable.


At a glance

What this is: This is a practitioner analysis of shopping-assistant architecture showing that deterministic workflows work better than agentic reasoning for known intents, while agentic loops remain useful for open-ended tasks.

Why it matters: It matters because AI teams need to decide where reasoning is actually worth the latency, cost, and control overhead, and where explicit workflows and state boundaries are the safer design choice.


Context

AI assistants become harder to govern as they move from simple question answering into multi-step task execution. The core design problem is no longer whether a model can respond, but how much of the interaction should be decided by reasoning versus routed through explicit workflow logic.

In this article, the governance issue is architectural: clear intents, tool selection, and state scoping create a different risk profile from open-ended agent loops. That boundary matters for teams building assistants that must remain reliable as context, tools, and user journeys expand.


Key questions

Q: When should teams use deterministic workflows instead of agentic reasoning in AI assistants?

A: Use deterministic workflows when the intent is clear, the tool is known, and the expected output is predictable. That keeps latency lower, reduces token overhead, and makes behaviour easier to test. Reserve agentic reasoning for tasks where the assistant must choose between paths, incorporate intermediate results, or recover from ambiguity.

Q: Why does building SSO in-house often create more risk and cost than using a dedicated provider?

A: In-house SSO usually looks cheaper at first, but the hidden cost is ongoing engineering effort. Teams must build integrations for multiple identity providers, maintain auth protocols, keep security controls current, and support failures over time. That overhead increases delivery risk, delays enterprise onboarding, and can create downtime at the exact point where login reliability matters most for revenue and customer trust.

Q: What breaks when AI assistants rely on flat conversation history?

A: A flat history accumulates irrelevant context, increases token load, and makes it hard to know which object the user means. That leads to slower responses, poorer tool selection, and unreliable follow-up actions. In production, memory must be scoped to the workflow, not treated as one long thread.

Q: How should teams structure workflow state for multi-step AI assistants?

A: Separate state by workflow and entity, such as user preferences, active product context, and agent-thread memory. Make key context variables explicit, so the system can refresh downstream data when the user changes focus. That approach keeps orchestration predictable and reduces accidental context bleed across tasks.


Technical breakdown

Deterministic execution for known intents

Deterministic execution means the system maps a recognised user intent directly to a known tool or workflow, without asking the model to plan the path first. In this article’s shopping-assistant design, that fits requests such as product specs, coupon retrieval, and review summaries because the input, tool, and output shape are predictable. The architectural benefit is not just speed. It reduces prompt complexity, lowers token use, and removes one decision layer that can fail under load or drift across repeated tasks.

Practical implication: Use deterministic routing when the intent is known, the tool is fixed, and the answer shape should be stable.

Why ReAct loops are still needed for agentic reasoning

A ReAct loop combines reasoning and action across multiple cycles: the model plans, calls a tool, reads the result, and then synthesises the next step. That structure is appropriate when the path depends on intermediate results, such as location resolution, inventory validation, or fulfillment selection. The trade-off is that each loop adds latency, cost, and more room for compounding prompt complexity. In production, that means agentic reasoning should be treated as a targeted control path, not the default execution model for every request.

Practical implication: Reserve agentic loops for tasks where the next action genuinely depends on what the previous tool call returns.

State management must follow workflows, not just conversation history

As assistants grow beyond a single-product interaction, flat conversation history becomes a weak foundation because it mixes user intent, product context, and workflow state into one noisy memory stream. The article’s approach is to separate user-level state from product-level state, track current_product_id explicitly, and scope memory to agent threads such as search, inventory, and purchase. That design reduces ambiguity and prevents unrelated context from polluting later steps. It also makes orchestration easier because state changes become visible and intentional rather than inferred from prior dialogue.

Practical implication: Structure state around workflow phases and explicit context fields instead of relying on a single global chat history.


NHI Mgmt Group analysis

Deterministic routing is the governance control hidden inside performance engineering. When a request has a known intent, the safest design is often the least autonomous one because it constrains tool choice, output shape, and state drift. That makes the system easier to test, easier to audit, and less likely to improvise where no judgment is needed. For practitioner teams, the control question is not whether the model can reason, but where reasoning should be disallowed.

Agentic reasoning should be treated as an exception path, not an operating model. The article shows that ReAct-style loops are appropriate when the system must resolve uncertainty across multiple steps, but they add prompt load and execution variance. That is the same governance pattern seen in broader AI operations: autonomy should expand only when the task requires it, and only within a bounded workflow. Practitioners should define those boundaries explicitly rather than letting capability creep make the decision for them.

Explicit state is the difference between a manageable assistant and an ungovernable one. Separating user state, product state, and thread memory turns context from an implicit side effect into an observable control surface. That matters because multi-step assistants fail when memory becomes a dumping ground for unrelated signals, not because the model lacks language skill. The named concept here is workflow-scoped state, and it is becoming a core design principle for production AI systems. Teams should govern state as deliberately as they govern tools.

AI gateway governance only works when orchestration logic matches the actual interaction pattern. Central control is useful, but it cannot compensate for a design that routes every request through the wrong execution mode. If deterministic tasks are wrapped in unnecessary reasoning loops, the gateway becomes an expensive transport layer for avoidable complexity. Practitioners should align gateway policy, workflow design, and context handling so control does not become a bottleneck for simple requests.

From our research library:

What this signals

Workflow-scoped state: production assistants need context boundaries that map to task progression, not just to conversation length. When a system can switch products, workflows, and fulfillment paths, the state model has to make those shifts explicit or the assistant will confuse one task for another. Teams building governed AI assistants should treat state design as an orchestration control, not a convenience layer.

The practical signal for programmes is that autonomy should be introduced selectively, with direct execution handling the repetitive path and reasoning reserved for ambiguous or branching tasks. That split reduces the chance that simple requests inherit the latency and failure modes of complex ones. It also gives teams a cleaner basis for observability, because the workflow path itself becomes part of the control surface.


For practitioners

  • Route known intents deterministically Classify requests such as specs, coupons, and review summaries into direct tool execution paths, and reserve reasoning loops for requests that genuinely need multi-step decisioning.
  • Limit ReAct to uncertain workflows Use agentic loops only for cases like inventory checks, store discovery, or fulfillment selection where intermediate results change the next action.
  • Split state by workflow and entity Keep user-level state separate from product-level state, and make current_product_id an explicit variable so context shifts do not corrupt downstream actions.
  • Scope memory to each agent thread Isolate search, inventory, purchase, and product memory so one task does not carry irrelevant context into the next interaction.

Key takeaways

  • Deterministic workflows are the better control pattern for known intents because they reduce latency, cost, and decision noise.
  • Agentic reasoning remains appropriate for tasks with branching paths or uncertain tool selection, but it should be bounded and intentional.
  • Explicit workflow state, including scoped memory and named context fields, is what keeps multi-step assistants reliable as capability expands.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, CSA MAESTRO and MITRE ATLAS address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article is about when agentic reasoning should be constrained in production assistants.
Recommendation — Bound agentic execution so reasoning only expands access when the workflow requires it.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe piece is fundamentally about governance boundaries for AI assistant behaviour.
Recommendation — Define when deterministic routing replaces agentic execution in your AI governance policy.
CSA MAESTROAgentic AI threat modelingWorkflow control, tool selection, and state scoping are core agentic-system design concerns.
Recommendation — Model workflow transitions, tool use, and memory boundaries as governed agentic risk surfaces.
MITRE ATLASTA0002;TA0006 — Execution; Credential AccessAgent execution and tool use are central to adversarial and defensive analysis of AI assistants.
Recommendation — Map assistant tool execution paths to adversary tactics and constrain unnecessary autonomy.

Key terms

  • Deterministic Workflow: A deterministic workflow is a fixed sequence of investigation steps that produces the same output when given the same inputs. In SOC automation, it reduces variability, improves auditability, and creates a stable evidence trail before any AI reasoning is applied.
  • ReAct Loop: A ReAct loop is an agent pattern that alternates between reasoning and action, with the model planning, invoking a tool, and then using the result to decide the next step. It is useful for ambiguous or multi-step tasks, but it adds cost and execution variance.
  • Workflow-Scoped State: Workflow-scoped state means context is stored according to the task phase or agent thread rather than as one flat conversation history. This prevents unrelated context from leaking between search, inventory, and purchase operations, and it makes multi-step orchestration easier to control.
  • Explicit Context Tracking: Explicit context tracking is the practice of naming critical state variables, such as the active product or current workflow, instead of inferring them from dialogue. It makes assistant behaviour more stable because downstream tools can refresh or reset based on a visible state change.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in production environments. It gives practitioners a common control language for governing AI systems, service identities, and the workflows they depend on.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org