A small agent fix can reveal a larger application design problem. Two recent merges in the Apache-2.0 awesome-llm-apps repository address missing or unusable model responses. The governance example gained null-content handling in an October 21 merge; the RAG diagnostics example gained a report gate in an October 18 merge. This review is dated October 26, when the commits and their patches were inspected. Neither change is being described as an October 26 release.
What the two patches actually change
The governance patch converts a missing message body to an empty string before subsequent processing. Its added mocked test expects an empty result for that case. The diagnostics patch checks for absent choices, empty text, token-limit termination and a missing expected section before allowing its report-saving path to continue. These are narrow repairs to examples, not evidence of a repository-wide security or reliability certification.
The distinction matters: one contract prevents an application error; the other decides whether an artifact deserves to exist. A program can satisfy the first and still fail its user. Returning an empty string may be safe for a caller that understands absence. It is misleading if a dashboard turns every returned string into a green completion badge.
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. That design is a recommendation here, not a claim about features implemented by the repository.
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.
A heading check is a tripwire, not an evaluator
The diagnostics example's 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.
No provider calls or upstream test suites were executed for this review. The evidence is the pinned patches and their added tests; the support workflow is original design analysis. The practical lesson is to make artifact acceptance explicit. Catching a null value is necessary plumbing, while declaring a task complete requires a contract tied to what the user actually requested.
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.