First principle
Do not ask an LLM to be deterministic where software can be deterministic. Let the model classify, interpret, summarize, or choose within constrained options. Let code validate types, required fields, permissions, totals, identifiers, and business rules.
There are several different kinds of "inconsistent"
Before tuning prompts, identify the failure class. Different symptoms need different controls.
| Symptom | Likely problem | Better control |
|---|---|---|
| Valid prose, wrong JSON shape | Output contract is too loose | Structured outputs / schema validation |
| Correct format, wrong fact | Context, retrieval, or reasoning problem | Source grounding, retrieval tests, human review |
| Agent calls the wrong tool | Tool choice is ambiguous or over-broad | Narrow tools, explicit permissions, required approval |
| Same input produces different acceptable answers | Normal model variability | Decide whether variation actually matters |
| Works on examples, fails on real traffic | Test set is too narrow | Eval suite with edge cases and production samples |
| Occasional malformed or incomplete output | Generation edge case / truncation / integration handling | Validation, retry policy, stop conditions |
Use a schema when the next system expects a schema
If the model output will be parsed by software, inserted into a database, used to call an API, or mapped into n8n fields, prose instructions like "return JSON" are weaker than an explicit output contract.
OpenAI distinguishes JSON mode from Structured Outputs. JSON mode is intended to produce valid JSON, but valid JSON does not guarantee your specific schema. Structured Outputs can enforce a supported JSON Schema for function-call arguments when strict mode is used. Even then, your application still needs to handle request failures, tool failures, refusal states, missing upstream data, and business-rule validation.
Important distinction
A schema can make shape reliable. It does not make the underlying business judgment true. "customer_id" can be a perfectly valid string and still be the wrong customer.
Reduce the amount of judgment in each step
Large agent prompts often combine classification, retrieval, decision-making, policy interpretation, drafting, tool selection, and execution. That may look elegant on a canvas, but it creates a large failure surface.
- Separate interpretation from action.
Have one step identify what it believes is happening. Validate that result before any consequential tool executes. - Use constrained categories.
If there are seven valid ticket types, give the model seven valid ticket types rather than asking it to invent a label. - Keep calculations out of free-form generation.
Use code or a calculator for arithmetic, pricing, dates, thresholds, and deterministic transformations. - Pass only the context needed for the task.
More context is not automatically better. Excess context can introduce irrelevant instructions, stale facts, and conflicting data. - Require evidence for high-risk decisions.
Capture source IDs, document references, retrieved passages, or structured fields that support the model's conclusion.
Tool access is part of output reliability
An agent that drafts a questionable response is annoying. An agent that sends the response, changes a CRM record, refunds money, deletes data, or emails a customer without review can turn a model error into a business incident.
- Give the agent the smallest useful toolset.
- Separate read tools from write tools.
- Require human approval for irreversible, financial, external-communication, or security-sensitive actions.
- Validate tool arguments independently of the model.
- Record what the model requested and what the tool actually executed.
Retries can improve reliability or multiply damage
A retry is appropriate when a failure is transient or when you can safely regenerate an output. It is dangerous when the prior attempt may already have created side effects.
Before retrying an email send, invoice creation, CRM update, payment action, or provisioning request, use an idempotency key, external transaction ID, state check, or another mechanism to determine whether the action already happened.
Build a real evaluation set
Do not judge an AI workflow by five hand-picked examples. Save representative cases and expected outcomes. Include the awkward inputs that real users create: missing fields, contradictory instructions, long messages, ambiguous language, unusual attachments, duplicate records, angry customers, and malformed upstream data.
Your evaluation does not have to be academically sophisticated. For an SMB workflow, a practical test suite might ask:
- Did the classifier choose one of the approved categories?
- Did the output include every required field?
- Did it cite the correct record or document?
- Did it avoid taking action when confidence or required data was missing?
- Did it route edge cases to a human?
The goal is controlled uncertainty
Reliable AI systems do not pretend uncertainty disappeared. They put uncertainty where it can be tolerated and controls where it cannot. A marketing draft can tolerate variation. A routing classification might tolerate a small error rate if a person can correct it. A bank transfer, security change, termination notice, or regulatory filing needs a different control model.
Related White Paper
It Worked in the Demo. Now What?
See how model behavior, validation, monitoring, approvals, retries, and ownership fit into a production automation system.
