An agent service can return successfully while producing nothing useful. A support assistant might receive an empty answer, a truncated diagnosis or a response that represents an intended action separately from its display text. The application needs a completion rule tied to the requested work. Otherwise an empty artifact can enter storage, acquire a success badge and travel downstream as a finished report.
Define a usable result before calling the model
Start with the artifact the user needs. In a diagnosis workflow, that might be a category, a short explanation and evidence identifiers from the current support case. Specify required fields, explicit uncertainty and the failures that should stop publication. Keep parsing separate from acceptance: converting a missing string into a safe internal value helps the parser, while the acceptance gate decides whether the result can become a report.
JSON Schema supports required object properties and constraints on additional properties. These checks establish shape. The application still has to resolve evidence and apply task-specific rules. A well-shaped diagnosis can be wrong, and a fluent paragraph can be unsupported.
Make completion an application decision
Consider an original example: a support assistant has to produce a diagnosis and attach evidence identifiers. The service receives a successful transport response, but the text is blank. There are at least three states to distinguish: the request reached the provider, a response was obtained, and the business task produced an acceptable artifact. Collapsing all three into success loses the information an operator needs.
A useful result record can carry a status such as needs_retry, rejected_output or completed, together with the attempted operation, finish reason and validation failures. Keep the raw response in a restricted diagnostic store if policy permits; the user-facing report should contain only material that passed the report contract.
Separate text absence from tool execution
Empty display text alone cannot establish that nothing happened. A workflow may represent a requested tool action separately from its prose. Before retrying, the application must examine the response structure its provider and SDK actually return, then consult its own effect journal. A generic retry on empty text can repeat a payment, ticket creation or other external action if execution already happened.
The safest recovery target is the missing stage. If an effect completed and only the explanation is missing, regenerate the explanation from the recorded result instead of repeating the effect. If no action was authorized or dispatched, retry within a bounded budget. If the outcome is ambiguous, surface that ambiguity rather than manufacturing a successful report. These paths deserve separate counters so a reliability review does not mistake recovery traffic for completed work.
Validate the report beyond its headings
An expected-section check is useful as a cheap tripwire. It cannot prove that a diagnosis is correct, that its citations exist or that the proposed fix is safe. An output can include a heading while providing fabricated details underneath it. Conversely, useful text can be rejected because its format differs.
For the support example, use a structured artifact contract with a diagnosis category, evidence references and an explicit unknown state. Validate structure first. Resolve each evidence reference against the current case, then apply task-specific checks. Keep semantic uncertainty visible. If an output fails, store a failure record with a bounded reason rather than a report whose existence implies acceptance.
How to review this failure in your own service
Exercise missing choices, null text, whitespace, truncation and a syntactically valid but unsupported diagnosis. Add a case where a tool effect has already completed before text disappears. Check both the API result and durable storage: a rejected report must not show up in search, exports or a completed-task count. Test the retry budget as well as the first response.
Use a synthetic acceptance matrix before deployment. Record the expected storage outcome, task status and recovery action for each case. An empty answer should leave an explicit incomplete result; an ambiguous external effect should go to reconciliation; a validated diagnosis may become a report. This guide describes an application design and proposed checks rather than a measured provider benchmark.
Sources and evidence
Treat transport success, response availability and acceptable task output as separate states. Recover the missing stage without blindly repeating completed effects, and save a report only after its application contract passes.