What the Agent Says When No Human Answers

Three values are enough for the vast majority of enterprise tool surfaces. The test for which one applies is not "did the user ask for something bad" but "what is true about the requested action right now."

The distinction between denied and parked is the one teams get wrong most often. Denied is a statement about the policy: the action is outside what this agent, for this user, on this resource, may ever do. Parked is a statement about completeness: the action is inside policy but the request lacks something the policy requires, such as an approval ticket reference, a verified identity, or a fresh retrieval.

Escalated is not a synonym for parked with a human attached. It changes control. The agent loop should not keep retrying, and the model should be told explicitly that further attempts are not its job. Approval and escalation design in workflow systems already follows this pattern: auto-escalation activates when a service level or time threshold is exceeded and reroutes to a secondary or managerial role rather than waiting indefinitely (auto-escalation for stalled approvals).

A template is only as good as its fields. Keep them identical across all three outcomes so the model sees one shape and your logs stay queryable. Six fields do the work.

outcome: one of denied, parked, escalated. Never free text.

reason_code: a stable, enumerable string from a fixed list. This is what you alert on, what you count per week, and what you attach runbooks to. If your reason codes drift into prose, you lose the ability to say "the top fallback reason last month was missing_evidence on refund tools."

attempted_action: the tool name plus the full argument object as submitted. The model needs to see its own request echoed back, including the exact field values, because most near-miss retries come from a single wrong argument. Echoing arguments also means the trace shows what was blocked, not just that something was.

deciding_policy: the identifier of the rule, policy version, or upstream system that produced the decision. Something like refund_policy_v7#amount_ceiling or identity_check#unverified_caller. Note the parallel with input validation guidance: validate the representation that will actually be used, and do not re-decode downstream, because inconsistent decoding invalidates earlier checks (OWASP Input Validation Cheat Sheet). The same applies to the deciding policy: the identifier the enforcement point emits is the one the model and the auditor should both see.

next_allowed_steps: a specific, finite list. Not "try something else." Write things like ["issue_refund with amount <= 50.00", "create_callback_request", "hand_off_to_human"]. A model given a menu picks from the menu; a model given a prohibition improvises.

owner: null for denied, a queue or ticket reference for parked, a named individual or team plus a ticket for escalated. Zendesk's guidance on agent escalation is a useful sanity check here: gather order number, name, and email, tag and update fields, and identify suitable agents before handing off, so the human does not start from zero (configuring escalation strategies and flows for AI agents).

Here is the shape in JSON. denied carries no owner and a mandatory alternative list.

{
  "outcome": "denied",
  "reason_code": "amount_over_limit",
  "attempted_action": {
    "tool": "issue_refund",
    "arguments": { "order_id": "A-10442", "amount": 780.00, "currency": "USD" }
  },
  "deciding_policy": "refund_policy_v7#amount_ceiling",
  "next_allowed_steps": [
    "issue_refund with amount <= 50.00",
    "create_callback_request",
    "escalate to billing_queue"
  ],
  "owner": null
}

And parked, which keeps the model in the loop:

{
  "outcome": "parked",
  "reason_code": "awaiting_approval",
  "attempted_action": {
    "tool": "update_contract_terms",
    "arguments": { "contract_id": "C-8871", "clause": "term", "months": 24 }
  },
  "deciding_policy": "contract_change_policy#manager_approval",
  "next_allowed_steps": [
    "read contract C-8871 and summarize the current term",
    "create_approval_request and reference ticket AP-3312",
    "escalate to legal_queue"
  ],
  "owner": "approvals_queue"
}

The model does not read your intent. It reads your tokens. Two wordings of the same decision produce opposite behavior.

Weak: "You are not allowed to issue this refund." The model hears a prohibition on the category and either apologizes or rephrases the same refund with a different argument.

Strong: "Refund of 780.00 USD on order A-10442 was denied by refund_policy_v7 amount_ceiling. You may issue a refund up to 50.00 USD, create a callback request, or escalate to billing_queue."

Four wording rules carry most of the value.

1. Put the outcome in the first sentence as a plain noun, not as a verdict on the user. "Denied by policy" and "parked pending approval" are facts. "Rejected," "invalid," and "not permitted" are judgments the model will translate into apology.
2. Follow immediately with the alternative list, in the same breath. Alternatives placed after a paragraph of explanation get truncated or ignored; alternatives placed directly after the outcome are the next thing the model conditions on.
3. Never use "no" without a "but." Parked outcomes should lead with what is already true: the request passed identity and scope checks and needs one specific piece of evidence. That framing is a direct application of why validation exists at all, to reduce the risk of invalid operations rather than to punish the caller (OWASP Input Validation Cheat Sheet).
4. For escalated, say who owns it and tell the model to stop. Something like: "This request is now owned by billing_queue under ticket AP-3312. Do not retry this action. You may tell the user the reference and stop." An agent that keeps proposing the escalated action after a human took it converts a clean handoff into a duplicate-work generator, which is exactly the failure mode escalation timers exist to prevent (approval timeout handling).

A decision rule for choosing between parked and escalated, if you want one line: if the only thing missing is something the model can obtain in this turn (a document read, a user confirmation, an ID verification step), park it. If the missing thing requires a person's judgment, a signature, or a queue, escalate it.

The loop has one insertion point and one rule. The insertion point is immediately after tool dispatch and before the result returns to the model. The rule is that the model never sees a raw exception.

def dispatch(tool_name, args, ctx):
    decision = policy.evaluate(
        actor=ctx.user, agent=ctx.agent_id, tool=tool_name,
        args=args, resource=ctx.resource, state=ctx.workflow_state,
    )
    if decision.allow:
        return {"outcome": "allowed", "result": run_tool(tool_name, args)}
    return {
        "outcome": decision.outcome,          # denied | parked | escalated
        "reason_code": decision.reason,       # stable enum
        "attempted_action": {"tool": tool_name, "arguments": args},
        "deciding_policy": decision.policy_id,
        "next_allowed_steps": decision.alternatives,
        "owner": decision.owner,
    }

Three engineering details make this work in production.

Fail closed, and fail into parked, not into allowed. A useful policy system must fail closed, produce explainable decisions for reviewers, and emit evidence that survives incident response (policy-as-code for enterprise AI agents). If the policy engine times out, the safe default is a parked outcome with reason policy_unavailable, not a pass-through.

Cap the retries per reason code. Give the model two attempts to reach an allowed state after a parked outcome. If the third dispatch comes back with the same reason code, the orchestrator promotes the record to escalated with owner set to a queue. This keeps the model from looping on a missing evidence item it cannot produce.

Count outcomes separately from errors. Fallback usage must be a distinct counter with alerting on the rate, not lumped into generic error logs, and zero-token responses are a cheap correctness signal (silent LLM fallbacks). Do the same for outcome records: dashboard denied by reason code, parked by age, and escalated by owner queue. A spike in one reason code is a policy or a prompt that needs a change; a spike in parked age is a queue that needs staff.

Tool output schema design matters here too. Structured tool outputs that follow an explicit schema are far easier for a model to consume than free text, and error handling belongs in that schema as a first-class variant rather than an afterthought (error handling for LLM agent tools).

You cannot validate this by reading prompts. You test it by asserting on the record.

Start with an allowlist and denylist matrix per tool, because a block list can only name components someone has already reviewed, while the agent layer arrives through self-service config changes that get forked and repointed in seconds (allowlist and denylist policies for AI agents). Encode each cell as a test case with an expected outcome and reason code.

Then add the regression you actually care about: after a denied record, does the model pick from next_allowed_steps or rephrase the blocked action? Run it ten times per case. Reliability, not capability, is what breaks in production, and consistency across repeated trials on identical inputs is the number benchmarks rarely report (fallback design as an architecture problem).

The same discipline applies to the model layer underneath. A single-provider architecture has no path when the API degrades, which is why provider fallback and human escalation appear together in reliability designs (why AI agents need fallback models). If you are running several model providers behind one interface, Quanta Inference exposes text, image, video, audio and embedding models through one OpenAI-compatible key, which keeps the outcome record identical no matter which model produced the proposal.