Reliability starts with observable success criteria, not a general request for better answers. Define what a Claude system must accomplish, how it must behave under uncertainty, and which failures require a fallback or human decision. Anthropic’s evaluation guidance starts with specific, measurable criteria and supports approaches from deterministic checks to LLM-based grading.
Troubleshooting Methodology: Establish the Failed Contract
Start an investigation by identifying the exact failed contract: task outcome, output shape, source grounding, tool behavior, latency, cost, authorization, or user experience. Capture the input version, prompt and configuration version, model identifier, available tools, tool calls and results, output, and validation decision. Redact secrets and personal data according to the application’s policy.
This record supports root-cause isolation. Without it, a team may change a prompt when the real cause was stale retrieval, an unavailable tool, a permissions denial, or a downstream semantic rule. Provenance logging is a recommended governance control; it is not an official guarantee of the Claude platform.
Define Multidimensional Success Criteria
One aggregate "accuracy" score hides different production risks. Define separate criteria for task correctness, groundedness, output-contract compliance, safety policy, tool-call correctness, latency, and cost. Anthropic recommends that criteria be specific and measurable, with quantitative measures or consistently applied qualitative scales as appropriate.
Choose thresholds and error severity with the accountable product, safety, and operations owners. A low-risk drafting assistant might allow a warning and revision path; a system that sends, changes, approves, or discloses something may require stronger deterministic checks and a human control point. These placement choices are architectural recommendations, not platform defaults.
Build Test Cases, Graders, and Regression Suites
Build a representative suite before tuning. Include ordinary inputs, edge cases, incomplete evidence, conflicting instructions, tool errors, policy-sensitive cases, and requests that should escalate. Keep each case versioned with an expected property or review rubric, not necessarily a single expected string.
Use deterministic graders where a rule can be stated precisely: JSON Schema conformance, required source identifiers, permitted categories, or prohibited side effects. Use rubric-based human or model-assisted graders for nuanced criteria, and periodically calibrate them against human judgment. Anthropic documents evaluations ranging from exact-match checks to LLM-based grading; a model grader is still a measurement component that needs validation.
Run the suite for changes to prompts, tools, models, retrieval, policy, or orchestration. A regression suite should block or flag a change according to a declared release policy. It cannot prove performance for every future input, so retain production monitoring and incident review.
Common Failure Classes and Isolation
For a malformed output, first inspect the output contract and parser; then distinguish a feature-availability mismatch from a prompting problem. For a wrong tool call, inspect the tool definition, tool-choice instructions, available context, returned error, and authorization boundary. Anthropic publishes symptom-to-fix guidance for common tool-use errors, but application-specific access and business rules still need local diagnosis.
For an ungrounded answer, compare the cited or retrieved evidence with the response before changing the model instruction. For a long-running workflow that loses the thread, inspect context budget, compaction artifacts, and the state handoff. Change one causal layer at a time, rerun the affected cases, and preserve the before-and-after evidence.
Fallback, Escalation, and Human Review
Define fallback before an incident. A fallback might return a safe partial result, queue a request for review, retry a transient read, or stop a side-effecting workflow. It should never invent an answer simply to keep a workflow moving.
Escalate when evidence is missing, policy is ambiguous, validation fails repeatedly, the requested action is privileged, or the cost of an error exceeds the automation’s approved risk. Put human review before irreversible or high-impact effects, and give the reviewer the source evidence, proposed output, validation findings, and a clear approve/reject path. These are recommended governance patterns; they do not make a model response automatically safe.
Operational Review and Continuous Improvement
Review failure rates by class, not only overall pass rate. Track whether a fallback was used, whether a reviewer overrode the result, and which input, configuration, or tool version was involved. Feed confirmed incidents into new regression cases and retire tests only with a documented reason.
Do not conflate a context mechanism with a reliability control. Compaction and caching manage what is available in a request; an evaluation establishes whether an outcome meets its contract. Keep that boundary visible in metrics, runbooks, and ownership.
Conclusion
Reliable Claude systems are tested and diagnosed as systems: model behavior, inputs, tools, policy, output handling, and human controls all matter. Define measurable criteria, use appropriate graders and regression suites, preserve provenance, and route uncertainty to a safe fallback or reviewer. That discipline provides the evidence needed for an end-to-end architecture decision.