How to Stop Your Support Agent From Behaving Inconsistently

Why does my support agent resolve disputes it should escalate?

Because a defensive instruction like 'avoid escalating unless absolutely necessary' signals urgency and overrides your explicit escalation rule. The strong prohibitive word tells the model this is the top priority, so it fills in wrong behavior — resolving billing disputes itself instead of handing them to a human.

The fix is Decision Criteria over prohibitions. Delete the avoidance instruction and replace it with a calm, two-sided rule: Escalate when the issue is a billing dispute. Continue resolving when the issue is a general product question. Now the agent evaluates neutrally, without a strong-word signal distorting its decision. This is the single highest-leverage change most support-agent prompts need.

How do I make account answers short and consistent?

Declare the exact output. Support agents drift into verbose, inconsistent answers because there's no declared shape — sometimes a paragraph, sometimes a bullet list, sometimes wrong. Add a `` tag that specifies format and length: Respond in one to two sentences with a direct, factual answer. Models follow declared output shapes faithfully, so this alone stabilizes most response variability.

While you're in there, reformat the whole prompt with HTML-style tags — ``, ``, `` — and strip anything the model already knows by default. Shorter and cleaner consistently outperforms longer and more detailed. A lean support prompt handles edge cases better than a bloated one.

How do I handle account IDs and live plan data?

Never hard-code them. Account IDs, plan names, billing status, and pricing change from user to user and run to run, so they must be injected at runtime by the harness as variables. Your static prompt should contain only stable instructions and reference variables like `{{account_plan}}` — never a literal plan name baked into the text. This is No Hard-Coded Dynamic Data, and it stops the agent from confidently citing stale account details.

Similarly, if the agent computes anything deterministic — a proration amount, a renewal date, a remaining balance — offload it. Compute it in the harness or expose a tool, then pass the result back. LLMs are unreliable at math and lookups, so this eliminates a whole class of wrong-number errors.

How do I audit a support prompt with months of patches?

Run a patch audit. Support prompts accumulate patches fast — every angry ticket becomes a new 'always' or 'never' rule. For each patch, ask: is it still relevant, does it conflict with another instruction, and can you name the specific failure it prevents? If you can't name the failure, cut it first. Resolve conflicting pairs by keeping one. Remove stale instructions whose root cause — say, a fixed billing pipeline bug — no longer exists.

Do all of this behind eval tests. Set up a suite that makes real API calls against representative tickets — a billing dispute, a plan question, an authentication edge case — and record what passes before you touch anything. After each change, re-run the suite multiple times, since model calls vary, and confirm the agent escalates correctly, answers concisely, and stays consistent across runs.

What about balancing when to escalate versus resolve?

Frame both costs. If your prompt only says escalation is expensive (ties up a human), the agent will under-escalate. If it only says wrong resolutions are dangerous, it'll over-escalate. State both: Escalating a resolvable question wastes agent time; resolving a dispute you shouldn't creates a compliance risk. Balanced trade-off framing keeps the agent from reflexively drifting in one direction.

Next step: Pull your current support prompt, set up an eval suite with five representative tickets, and run the patch audit and prohibition rewrite before touching anything else. Verify improvement against your baseline, not your gut.