Varendo

Agent recovery

Keep the application understandable when language is ambiguous, the provider fails, the session expires, or an action outcome is uncertain.

Agent sessions fail in ordinary ways: vague requests, dead providers, expired pairings, uncertain writes. Show each state honestly and keep the user's last good screen.

Ask when the request is ambiguous

Return needs-input with bounded choices such as the intended period, resource, or action. Show the proposed filters and target view so you can inspect the interpretation.

For example, a trend request that leaves two eligible measures unresolved comes back as a receipt like:

needs-input receipt

JSON example
{
  "status": "needs-input",
  "requestId": "req-42",
  "regionId": "people-main",
  "diagnostics": [
    {
      "code": "web.recipe.needs-input.measure",
      "message": "Choose one requested measure before rendering a trend: Present employees, Absence days.",
      "retryable": false
    }
  ]
}

The honest response is a visible choice between the eligible measures — not a guessed chart.

Survive provider and transport failure

Keep the last still-authorized UI, say that the connection failed, and leave manual controls available. Stop repeated failures that provide no new information.

Re-pair after expiry or revocation

Reject the call, cancel in-flight work, clear any now-unauthorized Region data, and have the trusted host pair again.

Treat uncertain writes honestly

A remote write may have happened even when its answer is lost. Show an ambiguous receipt plus a host-defined reconciliation action. Never report cancellation as rollback, and never auto-retry a non-idempotent write.

Write truthful copy

  • “UI updated” appears only after the matching runtime/renderer receipt.
  • Displayed numeric summaries are derived from Result evidence.
  • Model prose is not promoted to application fact.
  • The inspector shows intent, compiled Task, Result descriptor, selected view, and diagnostics — not chain-of-thought.