Production checklist

If you start with generated OpenAPI config, review the exposed operations, authentication, confirmation previews, response validation, and environment URL before release. Regenerate into a separate candidate file when the API changes; compare and merge reviewed settings instead of replacing your deployed config.

Treat release readiness as evidence, not a checked box

After connecting your first endpoint, test your application's flows against its staging API. Record requests, responses, continuation states, and authorization failures. The booking exercise is optional practice for selection and confirmation policies. Configuration validation alone does not prove production behavior.

A small single-process deployment can use memory stores if losing pending sessions on restart is acceptable. Horizontal workers need shared session state, serialized transactions, and an explicit credential-sharing strategy. Those are host integrations, not YAML switches.

Use a staging booking as the release gate

Demonstrate zero writes before approval, one write after approval, no duplicate on double-click, fresh choices after a stale slot, and a documented reconciliation procedure after an ambiguous timeout. Have an operator identify the request from logs without exposing credentials.

Keep a reviewed config and package version together. Config changes invalidate old pending sessions; plan the user experience for users whose choices were open during deployment. Monitor stale confirmations, uncertain execution, API rejections, and routing quality after rollout.

Each checklist item below should have a test result, an implementation, or an operational procedure behind it. Marking it complete without that evidence does not change runtime behavior.

Use this page as a release gate.

Configuration

• Config is immutable for the lifetime of a runtime instance.
• Every tool has a narrow description and explicit input schema.
• Request mappings are explicit; no hidden inference is required.
• Output schemas exist for critical API contracts.
• private_fields covers execution secrets returned by APIs.
• Large tool catalogs use a selective retriever or safe recall limits.

Authentication

• Host owns and binds sessionId to the authenticated caller.
• User tokens are passed only through auth.token.
• Downstream API performs authorization for every protected resource.
• API/service credentials live in environment/secret management.
• Credential-bearing production endpoints use HTTPS.
• Account switching clears or rotates AGENTO sessions.

Side effects

• Every write is declared side-effect or destructive.
• Every write requires confirmation.
• Confirmation preview contains understandable user-facing facts.
• Backend supports idempotency for important writes.
• There is a reconciliation path for ambiguous execution.
• Destructive operations have stronger UX and audit logging.

Horizontal deployment

• SessionStore.transact() serializes one session across workers using distributed locking/fencing or equivalent.
• Session store is shared.
• Opaque token store is shared if continuations may land on another worker.
• Workers share the credential encryption key when using a shared token store.
• Rate limiter is shared when global limits matter.
• Per-instance circuit breakers are understood as per-instance, not global.

Network

• Host/network egress rules prevent untrusted config from turning AGENTO into an unrestricted network client.
• Timeouts are appropriate per endpoint.
• Response byte limits are realistic.
• Retry attempts are conservative.
• Only idempotent/safe operations are retried.

Models

• Exact provider/model IDs have been tested.
• Routing evaluation fixtures cover real user language and ambiguity.
• Arabic/multilingual utterances are tested if supported product behavior.
• Model failures have a user/host fallback.
• AI presentation is not the only source of authoritative UI fields.

Observability

• requestId and sessionId are present in trusted logs.
• Runtime metrics are exported.
• Hooks are collected without adding secrets.
• Error-code dashboards exist for auth, upstream errors, stale selections and uncertain execution.
• Circuit state can be inspected.

Testing

• Read-only happy paths.
• Missing input.
• Empty selections.
• Multiple selections.
• Selection expiry.
• Confirmation expiry.
• 401 / 403.
• 409 / 410 recovery where enabled.
• 429 / 5xx / timeout behavior.
• output-schema violation.
• aborted request.
• config change invalidates old session.
• worker crash/uncertain execution procedure.

Release validation

The documented public package is agento-runtime@1.0.0. Before declaring a production guarantee, freeze a reviewed commit/tag, run the repository tests, add integration tests against your APIs, and define operational ownership for uncertain side effects and distributed session locking.