afv-library/plugins/builder/salesforce-development/skills/agentforce-generate/references/posture-and-determinism.md

Authoring Posture: Agentic vs Deterministic

This guide defines how to choose the right posture for each subagent.

Posture is the dial between model latitude (agentic) and authored control (deterministic). Choose posture first, then choose subagent organization (router-first architecture, verification gate, and so on).

Core Principle

Default to the most agentic posture that still meets the requirement.

Pin determinism only with cause:

• Regulated, audited, or legally constrained steps
• Identity, trust, or authorization gates
• Confirmed irreversible or consequential actions
• External ordering backed by successful action outcomes
• A failure mode observed in preview or production traces

Avoid defaulting to scripted instructions because they feel safer. Over-scripted flows are brittle and expensive to maintain.

Primary Controls

Three primitives control posture:

1. available when
   Primary invariant tool. Hide actions when preconditions are false.
2. with param = ... vs with param = value
   Default to .... Pin values only when sourced from controlled state (for example, verified customer_id), needed after action-output scope ends, or when a reproduced extraction failure requires it.
3. if / else in instructions: ->
   Use conditional instructions only when a named controlled value changes the prompt the model must receive. More branching means more authored control.

Surviving conversation history is the default source for names, preferences, answers, corrections, and current intent. Add mutable state only for a named runtime consumer or a value explicitly required beyond the history window.

Failure Mode to Avoid

Do not start with step-by-step prose directives like:

• Step 1: invoke X
• Step 2: invoke Y
• CRITICAL: always invoke Z

These ask the LLM to follow a fixed procedure via natural language — brittle and easily ignored.

Deterministic if/else conditionals are resolved before the LLM sees the prompt, but that does not make every branch desirable. Each branch must cite a regulation, authorization boundary, confirmed consequence, external ordering constraint, or reproduced trace failure. Its variable must have a trusted writer and a named consumer.

Use if/else when:

• The branch consumes verified authorization or eligibility
• The branch consumes exact action output or confirmed consequence data
• The branch enforces required external ordering
• A reproduced trace failure requires deterministic resolution

Use prose instructions when:

• The LLM needs judgment/flexibility (tone, phrasing, edge-case handling)
• The decision depends on unstructured user input the LLM must interpret
• Surviving conversation history already contains the relevant fact

Posture Matrix

Decision	Scripted	Mixed	Agentic
Action ordering	gates on required external outcomes	gates on real invariants	gates on real invariants
Action parameters	mostly pinned	mixed pinned + ...	mostly ...
Instructions	step-by-step with many branches	guidance with targeted branching	high-level intent, minimal branching

When requirements do not name a deterministic cause, start agentic. Add each mixed or scripted control only when a specific decision needs one of the causes listed above.

Scripted Posture

Use when requirements are regulated, audited, or require strict traceability.

Signals in requirements:

• "regulated"
• "compliance"
• "auditable"
• "must trace every step"

Structural expectations:

• available when gates on auditable invariants
• Parameters mostly pinned to authored variables
• Detailed branching only where the regulated procedure requires it

Mixed Posture

Use when some decisions have machine-checkable invariants while the remaining decisions depend on unstructured current intent or judgment.

Typical shape:

• Gate real invariants only (identity, entitlement, eligibility)
• Pin controlled values (for example customer_id), keep other values as ...
• Use concise guidance, not full scripts

Agentic Posture

Use for open-ended assistance where the model can safely carry more reasoning.

Typical shape:

• Minimal gating outside trust/security invariants
• Most parameters use ...
• High-level intent instructions with minimal branching

Review Checklist

For each subagent:

1. Which posture is selected?
2. Why that posture (regulation, trust gate, or observed failure)?
3. Which invariants are enforced with available when?
4. Which parameters are pinned, and what controlled source justifies each pin?
5. For every variable, what named runtime expression or later action consumes it?
6. Does that consumer need the exact stored value, or would a trusted boolean outcome preserve the same invariant with less state?
7. What are each variable's reset, expiry, correction, and cancellation semantics?
8. Which instructions can be simplified without losing required control?

If an answer cannot cite a cause and consumer, remove the control or variable.