Enterprise agents do not fail because they are “too probabilistic.” They fail because teams leave the wrong decisions probabilistic.

That distinction matters. A service agent should be flexible when it interprets a customer’s phrasing, summarizes a case, or explains a policy in plain language. The same agent should not improvise whether identity verification is required, whether a refund exceeds an approval threshold, or whether a regulated disclosure must be presented before an action.

Salesforce’s six levels of agentic control provide a useful vocabulary for this design problem. The mistake is treating the levels as a maturity ladder where every agent should climb to level six. They are better understood as an allocation framework: each decision belongs at the least restrictive level that still satisfies the cost of being wrong.

The real unit of design is the decision

An agent is not deterministic or non-deterministic as a whole. It contains dozens of decision points, each with a different risk profile:

• What does the customer mean?

• Which business domain owns the request?

• What data is relevant?

• Which action is allowed?

• What prerequisites must be satisfied?

• What sequence must execute?

• How should the result be explained?

Trying to force all seven questions through natural-language instructions produces an agent that looks intelligent in a demo and behaves inconsistently under edge cases. Forcing all seven through rigid branching recreates a chatbot with a larger bill. The architecture should preserve probabilistic reasoning where ambiguity is useful and replace it where ambiguity is dangerous.

A practical reading of the six levels

Level 1: descriptions and autonomous selection

At the first level, the reasoning engine uses the names and descriptions of subagents and actions to infer what to do. This is appropriate for low-risk discovery and FAQ behavior, especially when the actions are read-only and semantically distinct.

The engineering work is ontology design. “Look up order” and “find customer order” are probably too similar. “Order status” and “product troubleshooting” create a cleaner semantic boundary. Reliability at this level comes from reducing overlap, not from writing longer prose.

A useful test is adversarial paraphrasing. Generate twenty ways a user could express the same intent, then twenty near-neighbor intents that must route elsewhere. If the descriptions cannot separate those sets, instructions later in the subagent will not fix classification because subagent selection only sees the subagent name and classification description.

Level 2: natural-language instructions

Instructions constrain how the selected subagent behaves. They are good for policies with interpretive room: tone, preferred order of investigation, when to ask a clarifying question, and how to explain uncertainty.

Instructions are not enforcement. “Always verify the user before discussing an order” is still text interpreted by a model. It may perform extremely well in testing and still be the wrong control for a legal or security boundary. If violation is unacceptable, the rule belongs in a deterministic gate, not a stronger adjective.

Level 3: grounding

Grounding reduces epistemic freedom. The agent can reason flexibly, but its claims are constrained by retrieved CRM records, Knowledge, Data Cloud, or action outputs.

This level is frequently misdiagnosed. Teams see an unsupported answer and add another instruction against hallucination. The better question is whether the correct evidence was retrievable, current, permission-aware, and narrow enough to outrank distractors. Grounding quality is an information architecture problem before it is a prompt problem.

For high-value retrieval, log the candidate set—not only the final answer. You need to distinguish “the right source was not retrieved” from “the right source was retrieved but ignored.” Those are different failures with different owners.

Level 4: variables and explicit state

Variables turn conversation history into inspectable state. Instead of hoping the model remembers that identity was verified three turns ago, store verified = True. Instead of inferring whether an order was loaded, store its identifier and eligibility result.

State should represent facts that change control flow. Do not mirror the entire transcript into variables. Every variable becomes another dependency to initialize, update, test, and clear. Strong candidates include verification status, case identifier, approval tier, workflow step, and action outcomes used by later conditions.

Level 5: deterministic actions

Apex, Flow, and APIs make the work itself predictable. The agent can choose an action probabilistically while the action enforces validation, sharing, field-level security, transaction boundaries, idempotency, and error semantics.

This is where many production systems should place their strongest controls. An agent action should be a narrow contract, not a conversational suggestion:

{
  "status": "APPROVAL_REQUIRED",
  "refundAmount": 740.00,
  "approvalThreshold": 500.00,
  "requestId": "RR-10482",
  "safeToRetry": true
}

{
  "status": "APPROVAL_REQUIRED",
  "refundAmount": 740.00,
  "approvalThreshold": 500.00,
  "requestId": "RR-10482",
  "safeToRetry": true
}

{
  "status": "APPROVAL_REQUIRED",
  "refundAmount": 740.00,
  "approvalThreshold": 500.00,
  "requestId": "RR-10482",
  "safeToRetry": true
}

Typed statuses are more valuable than paragraphs. They give Agent Script, tests, monitoring, and human operators the same observable state. A vague string such as “This may need approval” pushes business logic back into interpretation.

Level 6: Agent Script control

Agent Script governs the reasoning path itself. It can run prerequisite actions, branch on variables, hide unavailable tools, and force transitions between subagents before the LLM reasons. This is the right level for authentication gates, mandatory disclosures, approval boundaries, and sequences where reordering creates risk.

The architectural pattern is not “replace the LLM with code.” It is a control sandwich:

• Deterministic preconditions establish identity, data, and permissions.

• Bounded reasoning interprets the user’s goal and communicates naturally.

• Deterministic postconditions validate, record, or route the outcome.

Design from the cost of error

Use a decision matrix instead of choosing one control level for the entire agent.

• Low impact, reversible, observable: descriptions and instructions may be enough.

• Incorrect answer harms trust but not records: add grounding, citations, and retrieval evaluation.

• Decision depends on session facts: add explicit variables with defaults.

• Action changes systems of record: enforce rules inside typed Apex, Flow, or API actions.

• Prerequisite or sequence must never be skipped: use Agent Script conditions and transitions.

Three properties increase the required control: irreversibility, blast radius, and delayed detectability. A wrong summary is visible immediately and easy to correct. A wrong entitlement update may affect thousands of downstream decisions before anyone sees it. Those two operations do not belong at the same level.

Worked example: a refund agent

Consider a customer asking for a refund after a late delivery. The agent must understand the request, retrieve the order, verify identity, evaluate policy, determine whether approval is required, create a request, and explain the outcome.

A balanced design assigns each decision deliberately:

• Intent recognition: level 1, because customers phrase refund requests unpredictably.

• Conversation guidance: level 2, to ask concise clarifying questions.

• Policy explanation: level 3, grounded in the effective policy version.

• Verification and order context: level 4, stored as explicit session state.

• Eligibility and request creation: level 5, implemented as transactional actions.

• Verification gate and approval routing: level 6, enforced before reasoning can proceed.

The critical point is that the LLM never decides whether verification is optional. It can decide how to ask for verification and how to explain the result.

variables:
  verified: mutable boolean = False
  order_id: mutable string = ""
  refund_amount: mutable number = 0
  approval_required: mutable boolean = False

start_agent agent_router:
  reasoning:
    instructions:
      -> if @variables.verified == False:
        transition to @subagent.identity_verification
      | Classify the customer’s request and route to the most relevant subagent

variables:
  verified: mutable boolean = False
  order_id: mutable string = ""
  refund_amount: mutable number = 0
  approval_required: mutable boolean = False

start_agent agent_router:
  reasoning:
    instructions:
      -> if @variables.verified == False:
        transition to @subagent.identity_verification
      | Classify the customer’s request and route to the most relevant subagent

variables:
  verified: mutable boolean = False
  order_id: mutable string = ""
  refund_amount: mutable number = 0
  approval_required: mutable boolean = False

start_agent agent_router:
  reasoning:
    instructions:
      -> if @variables.verified == False:
        transition to @subagent.identity_verification
      | Classify the customer’s request and route to the most relevant subagent

This is a boundary, not a suggestion. When the condition is true, the transition happens before the model receives a prompt for ordinary routing.

Why longer instructions eventually stop helping

Instructions improve behavior until they begin encoding a state machine in prose. Warning signs include repeated “always,” nested exceptions, references to facts from earlier turns, and rules that depend on action outputs. At that point, the prompt is doing the job of variables and conditions without their observability.

A useful refactoring rule is:

• If a rule describes how to communicate, keep it in prompt instructions.

• If a rule depends on a fact, represent the fact as a variable.

• If a rule controls permission, sequencing, or mutation, express it as deterministic logic.

Testing the control allocation

Do not only test whether the agent reaches a good answer. Test which layer prevented a bad one.

• Routing tests: paraphrases, ambiguous requests, and near-neighbor intents.

• Grounding tests: stale records, conflicting sources, missing permissions, and empty retrieval.

• State tests: fresh session, resumed session, cleared variable, malformed action output.

• Action tests: bulk inputs, retries, duplicate requests, partial failure, and authorization.

• Script tests: every branch, mandatory transition, unavailable tool, and terminal state.

The evaluation should assert invariants. “No refund action is available before verification.” “Every request above the threshold has an approval record.” “A failed write never produces success language.” These are stronger than grading a response for general helpfulness.

The architecture principle

Determinism is not a feature to maximize. It is a scarce constraint to place precisely.

Use the LLM for the work that benefits from interpretation: language, ambiguity, explanation, and recovery from unusual phrasing. Use code and typed actions for the work that benefits from guarantees: identity, permissions, thresholds, ordering, writes, and audit evidence.

The best enterprise agent is not the one with the fewest surprises. It is the one whose surprises are confined to places where surprise is useful.

Sources and further reading

• Salesforce: A framework for six levels of agentic control

• Salesforce Developer Guide: Agent Script

• Salesforce pattern: required subagent workflows