How to Write a Decision Rule an Agent Can Follow

Every rule an agent can execute reliably has the same skeleton:

Two design notes matter more than the table suggests.

First, the condition must reference fields the agent can actually see: order date, order total, product flags, account tier, margin. If the condition depends on a value that is not in the input, the model will guess, and guesses are not consistent. Decision-rules documentation for LLM-based agents describes this as the model reasoning over input and returning a typed, structured response every time the rule runs, and it warns that logic expressible as explicit conditions is better served by a deterministic table or tree than by a model at all (DecisionRules AI agent documentation).

Second, the exception should point somewhere. "Unless the product is final sale" is weaker than "unless the product is flagged final sale, in which case deny and cite the policy name." An exception without a destination is a pause, and a pause in an agent usually becomes improvisation. Guidance on agent exceptions puts the same principle plainly: the agent may reason about a case, but business rules should come from authorized sources, not from the model itself (this practitioner answer on keeping agents from inventing rules).

Worked example: the refund rule in full

When a customer requests a refund (trigger), if the order was placed within the last 30 days and the order total is under $100 (condition), approve the refund (action). If the product is flagged final sale, deny the refund and cite the final-sale policy. If the order total is $100 or more, or the customer has already received a refund on this order, do not decide: return escalate with the reason.

Notice what the rule refuses to do. It does not approve large refunds, and it does not deny them either. It routes them to a person, which is a decision the agent can make correctly 100 percent of the time.

The prompt should state the rule word for word and constrain the output. Three elements do the heavy lifting: a verbatim rule, an input schema, and a strict output format.

You are a refund decision function. Apply the rule exactly as written.
Do not use judgment outside the rule. If a case is not covered, output escalate.

RULE:
When a customer requests a refund, if the order was placed within the last
30 days and the order total is under $100, approve.
If the product is flagged final sale, deny and cite the final-sale policy.
If the order total is $100 or more, or the customer has already received a
refund on this order, escalate.

INPUT FIELDS:
order_date (YYYY-MM-DD), today (YYYY-MM-DD), order_total (USD number),
final_sale_flag (true/false), prior_refund_on_order (true/false), request_text

OUTPUT (JSON only, no other text):
{"decision": "approve" | "deny" | "escalate", "reason": "<one line>"}

This shape follows the design guidance in OpenAI's practical guide to building agents, which treats an agent as a model, a set of tools, and explicit instructions and guardrails, and which recommends prototyping with the most capable model to establish a performance baseline, then trying smaller models to see whether they hold up. The instructions field is where the rule lives; the schema is what makes the output machine-checkable.

Two phrasing habits pay off immediately.

Put the rule before the data and the output format after it. Models follow instructions more reliably when the rule is not buried between input fields.

Say what to do with missing data. If order_date is null, the rule above says nothing, and the model will fill the gap. Add one line: "If any input field is null, output escalate with reason missing_field." Then add a test case for it.

A note on tools: agents get more consistent when they fetch context with tools instead of carrying it in the prompt. The Linear Agent team described the biggest mistake in agent building as over-prompting, and advised giving the agent tools to load context rather than pasting all the context in (this conversation with the Linear Agent builders). For a refund rule, that means a tool that fetches order history rather than a prompt stuffed with customer records.

A decision that can be written as explicit conditions should stay deterministic. Reserve the model for the part that resists a table: reading a free-text complaint to extract the requested remedy, or judging whether a customer narrative describes a genuine service failure.

The comparison is worth putting in front of your team:

The DecisionRules comparison makes the tradeoff explicit: decision tables and trees are fully deterministic with full row-level or branch traces, while LLM-driven agents are probabilistic and best for reasoning, scoring, and extraction (DecisionRules documentation). That is not an argument against agents. It is an argument for keeping the arithmetic in code and the language understanding in the model.

A worked split for refunds: the agent reads request_text and outputs a structured requested_remedy field (refund, partial refund, store credit, unspecified). A short function then applies the 30-day and $100 thresholds to that field plus the order record. The model never evaluates a date difference, which is exactly the kind of operation where it will occasionally slip.

This also shrinks the eval surface. You only need to test the model on extraction and edge-case classification, and you test the threshold logic with ordinary unit tests.

An eval set is a fixed list of cases with expected outputs, run repeatedly. For a single rule, twenty to forty cases is often enough to expose the gaps, provided the cases are chosen to attack the rule rather than flatter it.

Build the set in four layers:

• Happy paths. Three to five ordinary approvals and denials, one per action. These catch regressions in the basics.
• Boundary cases. The day 29, day 30, and day 31 orders; totals of $99.99, $100.00, and $100.01. Boundaries are where off-by-one reasoning shows up.
• Exception cases. Final-sale products, repeat refunds on the same order, orders that trigger two exceptions at once. The double-exception case is the one most rules fail to specify, so write the precedence explicitly: safety exceptions beat commercial ones, and any conflict escalates.
• Garbage cases. Missing fields, dates in the future, negative totals, a request text that contradicts the structured data. Every one should produce escalate, never a guess.

Then score consistency, not just correctness. A single run that passes tells you little. Splunk's guide to agent evaluation frameworks distinguishes pass@k (at least one of k runs succeeds) from pass^k (every one of k runs succeeds) and reports that one computer-use agent reached roughly 78 percent pass@10 but only about 36 percent pass^10. Your customers experience the second number. For a rules agent, run each eval case five times and require the same decision in all five.

Track two failure counts separately:

1. Wrong decision: the agent returned a valid action that the rule says is wrong. This is a rule or input problem.
2. Inconsistent decision: the agent returned different actions across runs of the same case. This is usually a wording problem, often a vague word or an unstated precedence between two exceptions.

The second count is the more informative one for prompt work. If a case flips between approve and escalate, you have found ambiguity in your own rule, not a model defect.

Close the loop by converting every production surprise into a permanent case. Splunk's framework calls this turning production incidents into regression tests so the same failure cannot reach users again (Splunk). A rule that grows from twenty cases to sixty over a few months is a rule that has met reality.

The escalate branch deserves its own design, because it is the part of the rule that keeps a wrong decision from leaving the building.

Three things must be true of every escalation:

• A named owner. "Escalate" without a destination is a notification that goes nowhere. Escalation studies note that a rule is unfinished if you cannot name who acts when the first owner is silent, and recommend writing the fallback route before the primary route (Neota Logic on governed escalation workflows).
• A time expectation. A decision owner and a response clock should accompany every trigger, so a stalled escalation is visible rather than quiet (Neota Logic).
• Thresholds set from evidence. Thresholds that are too low flood senior people with routine cases and train them to ignore the queue, which the same escalation analysis lists as a recurring failure mode (Neota Logic).

For the refund rule, that means: escalate returns go to the support lead queue with a four-hour clock during business hours, and to an on-call backup after that. The agent outputs the reason code, and the queue sorts on it.

Escalation thresholds should be reviewed with actual volume. If escalate is firing on 40 percent of cases, either the condition is too narrow or the threshold is set below the team's risk appetite. Both are fixable with numbers, which is the point of writing them down.

Run through this list for every rule you draft. It takes ten minutes and catches most of the failure modes above.

If you are running several rules across different models, a single API for text, vision, and structured tasks keeps the plumbing out of the way; Quanta Inference exposes many model families behind one OpenAI-compatible key, which makes swapping the model under a rule a configuration change rather than a rewrite.