An engineering pattern for letting models interpret uncertainty without letting interpretation become authority.
At 16:42, a project lead sends a chat request: “A visiting analyst needs read access to the cell-level study export through Friday so she can compare the validation runs.”
A capable model can identify the likely action, find the relevant project context, and notice what is still unclear: Which analyst? Which export? Which Friday and time zone? Is this data class available to visitors? That interpretive work is useful. It is also not permission to grant access.
The design problem is not to make this request deterministic from end to end. Natural language, incomplete records, and changing context make that unrealistic. The problem is to put uncertainty where it helps and make critical decisions explicit where the system needs a stable answer.
A request arrives as language
Enterprise work rarely begins as a perfectly formed API call. A person may refer to a colleague by role, name a resource informally, omit a time zone, or describe a goal without knowing the correct operation. Models can help bridge that gap. They can interpret varied language, retrieve supporting context, propose a canonical action, and explain why the request may need clarification.
The model’s output should be treated as a proposal. A downstream system can accept, reject, clarify, or route that proposal for review. That boundary matters because a model’s confidence is not an authorization signal. A well-formed response can still identify the wrong person, choose the wrong resource, miss a policy exception, or describe an action that is invalid in the current state.
The distinction is between interpreting what someone may mean and deciding what the system is allowed to do. The first can be probabilistic. The second should be governed by authoritative identity, policy, state, and explicit approval rules.
The handoff is the system boundary
The model should not send free-form prose directly to a write operation. It should return a bounded proposal with fields the application can validate: the proposed action, canonical resource references, requested scope, duration, supporting evidence, and unresolved questions. If a resource cannot be resolved exactly, the system should ask for clarification rather than silently converting a fuzzy match into an access grant.
One possible proposal shape is:
{
"intent": "request_temporary_access",
"principal_reference": "candidate identity reference",
"resource_reference": "candidate resource reference",
"scope": ["read"],
"requested_expiry": "requested time boundary",
"evidence": ["context references used to interpret the request"],
"unresolved": ["identity or resource details that need confirmation"]
}This structure does not make the model’s interpretation true. It makes that interpretation inspectable. Application code can validate the schema, resolve references against authoritative records, reject unsupported fields, and keep uncertainty visible. A generated field should never be allowed to smuggle extra authority through a flexible payload.
State changes need their own authority
Once the proposal is understood, deterministic services can apply rules that should not be left to a language model: whether the authenticated requester may initiate this operation; whether the selected resource is eligible; whether the requested scope is permitted; whether separation-of-duties rules require another approver; and whether the requested expiry is within the allowed range.
The workflow owns the state transition. It can move a request from proposed to awaiting_approval, denied, or ready_to_execute; after approval, it can recheck the current policy and resource state before committing. The model cannot jump a request from proposal to provisioned access by returning a persuasive sentence or a different status value.
In practice, a critical action might follow logic like this:
proposal = interpret(request, authorized_context)
candidate = validate_schema_and_resolve_exact_references(proposal)
if candidate.has_unresolved_identity_or_resource:
return ask_for_clarification()
decision = policy.evaluate(
authenticated_principal,
candidate.action,
candidate.resource,
current_policy_and_resource_attributes
)
if decision == DENY:
return deny()
if decision == HUMAN_REVIEW_REQUIRED:
approval = request_human_approval(bound_to=candidate.exact_action)
if not approval.matches(candidate.exact_action):
return stop()
if not reauthorize_against_current_state(candidate):
return stop_or_replan()
if not transition_is_valid(current_state, candidate.action):
return report_conflict()
return commit_once(candidate, idempotency_key)This is illustrative pseudocode, not a complete authorization implementation. The important detail is the separation of duties: the model interprets; policy code authorizes; workflow code controls state; and, when required, a human approves the exact action that will occur. Approval should be bound to the principal, resource, scope, expiry, and relevant policy version. If any of those change before execution, the system should ask again or re-evaluate.
Authorization systems have long used this kind of boundary. Open Policy Agent, for example, describes a policy decision point that makes decisions for policy enforcement points, which then enforce them in the application. That separation is useful for agentic systems too: a model may formulate a candidate request, but the trusted enforcement point must check it against current policy before changing a protected resource. [4]
A stop is a valid outcome
Hybrid systems are often judged by how smoothly they complete an action. They should also be judged by how safely they refuse to complete one. Missing identity, stale context, conflicting policy, an unavailable authorization service, or a changed resource state should not be papered over with a plausible generated answer.
For high-impact operations, the system should fail closed when it cannot establish the conditions for a permitted action. For low-impact or read-only work, a safe fallback may be to return a draft, provide an explanation, or route the request to a person. The right fallback depends on the consequences of acting and the consequences of stopping.
Deterministic does not mean correct. A deterministic policy can encode the wrong rule; a state machine can have a bug; a cached attribute can be stale. The control path still needs versioning, review, testing, monitoring, and incident handling. Reproducibility means that, given the same authoritative inputs, policy version, and state, the system applies the same checks and transition rules. It does not guarantee that those inputs or rules are sound.
The boundary also needs operational care. Rechecking permissions after a human approval helps prevent a stale approval from authorizing a changed request. Idempotency keys help prevent retries from creating duplicate changes. Recording the proposal, evidence references, policy version, approval, execution result, and resulting state makes later investigation possible. Keep fast policy checks close to the enforcement point where practical, while ensuring that latency optimizations do not rely on stale permissions.
Why the hybrid pattern is appearing in agent tooling
The distinction between model-directed agents and code-defined workflows is not new. Anthropic’s 2024 engineering guidance described workflows as LLM-and-tool systems following predefined code paths, and agents as systems where the model dynamically directs its process and tool use. The page also cautions that much of its tooling landscape has changed since publication, so it is best read here as an architectural distinction rather than a current tooling survey. [1]
Current OpenAI Agents SDK documentation makes the same boundary concrete in implementation choices: code orchestration is described as a way to make task flow more deterministic and predictable, and tool guardrails can check or block calls around execution. These are examples of primitives in current engineering tooling, not evidence that every enterprise has converged on one architecture. [2][3]
The NIST AI Risk Management Framework places governance across the system lifecycle and calls for human-oversight processes to be defined, assessed, and documented in line with organizational policy. It does not prescribe this specific hybrid architecture. It does reinforce the idea that oversight belongs in the design of the deployed system, rather than being delegated to the model’s own judgment. [5]
CARM’INK’s engineering position
For CARM’INK, this is a semantic-intelligence design choice. A system should represent what an action means, what evidence supports it, who is asking, which policy governs it, and what state transition would follow. The model can help interpret intent and context. It should not become the source of truth for identity, authority, or operational state.
The strongest agent is not the one that can act at every point. It is the one whose useful discretion ends at a deliberate boundary—and whose next step is clear when the boundary is reached.
Let the model interpret the request. Let governed software determine whether the action is permitted. Let people own the exceptions and the risk.
References
- Anthropic. “Building effective agents.” 19 December 2024. The page notes that much of the tooling landscape has changed since publication. Article
- OpenAI Agents SDK. “Agent orchestration.” Current documentation, accessed 29 October 2026. Documentation
- OpenAI Agents SDK. “Guardrails.” Current documentation, accessed 29 October 2026. Documentation
- Open Policy Agent. “How to Deploy OPA.” Current documentation, accessed 29 October 2026. Documentation
- National Institute of Standards and Technology. “AI RMF Core,” excerpt from the AI Risk Management Framework 1.0 (2023). NIST notes that a revised version is in progress; accessed 29 October 2026. NIST resource