AI Agent Deployment: Require Five Receipts Before Production

An AI agent deployment is ready only when five independent proofs agree about the same release: the runtime is reachable, its identity has exactly the permissions the task requires, scheduled work has explicit timing and duplicate semantics, a previous release can be restored, and a canary produced the promised deliverable. A healthy endpoint proves only the first of those facts. Use a blocked by default gate. Bind every receipt to an immutable release digest, record when it was checked, and stop promotion when evidence is missing, stale, contradictory, or belongs to another build. Do not average the five checks into a readiness score. A missing write scope and a missing customer artifact are different failures with different owners. This guide turns that rule into a compact manifest and an executable eight case fixture. It is intentionally runtime neutral: adapt the field names to Kubernetes, a serverless platform, a native agent scheduler, or a host process, but keep the five questions separate. Make deployment a version bound evidence decision Production deployment is not just the moment an image or function reaches a hosting platform. Google's production agent guidance identifies session state, persistent memory, tool authentication and permissions, logging, and staged sandbox to canary to production rollout as agent specific concerns. Those are useful ingredients, but a release decision still needs evidence from the exact build being promoted. Start with a stable identifier such as an image digest, Git commit, package hash, or signed release ID. Put that identifier in each receipt. A route can answer from release v27 while a permission probe or canary result was collected from v26 ; joining those records without a release key creates a false green. Infrastructure health has a narrower meaning. The Kubernetes probe documentation distinguishes liveness, which can trigger a restart, from readiness, which controls whether a container receives traffic. A ready process can accept a request while its tool credential is expired, its scheduler points at an old command, or its output verifier has no artifact to inspect. The release manifest can remain small: The example stores hashes and identifiers rather than prompts, transcript content, secrets, or raw tool payloads. Evidence should be sufficient to decide, not an excuse to copy sensitive material into a release system. Collect five receipts that answer different questions The five receipts are deliberately not interchangeable. Receipt Required proof What it does not prove Reachability The exact release accepts work through the intended route The agent can finish a task Permissions The runtime identity has all and only the declared scopes, with usable expiry A tool effect happened Schedule Timezone, next occurrence, misfire deadline, concurrency, and duplicate protection are explicit The occurrence delivered its result Rollback A known target was restored and its relevant outcome reverified The new release is correct Outcome A canary created the expected destination state Future runs will remain healthy For permissions, compare sets instead of asking whether authentication succeeded. The NIST definition of least privilege restricts a process to the minimum authorizations and resources needed for its function. Missing authority blocks the task; surplus authority expands the effect of a bad instruction or retry. Both should block promotion until the declared contract and deployed identity match. For scheduled agents, record the scheduler's real semantics. Kubernetes documents .spec.timeZone , startingDeadlineSeconds , and concurrencyPolicy , then warns that a CronJob can create two Jobs or no Job in some circumstances. Its CronJob documentation therefore recommends idempotent jobs. Another scheduler may use different names, but the release gate still needs an answer for late starts, overlap, duplicates, suspension, and the next expected occurrence. A rollback receipt is stronger than a command exit code. The Kubernetes Deployment documentation exposes rollout status, stuck rollouts, and rollback to an earlier revision. That confirms platform state. For an agent, add one more check: after restoring the previous digest, rerun a safe canary or inspect a known task specific result. Otherwise the rollback may restore a process without restoring useful work. The outcome receipt should use the strongest practical oracle: an object at its destination, a database row with the expected idempotency key, a passing test tied to the release, or a human decision record followed by observable progress. An agent message saying “done” is activity evidence, not a deliverable. Run the gate against inconvenient failures The accompanying deployment readiness fixture.json contains eight releases. Every endpoint reports ready. Only one case has five fresh receipts bound to sha256:agent v27 ; the other seven isolate a different failure: a stale reachability check; a permission receipt from the previous release; a missing required scope; a surplus administrator scope; a schedule without duplicate effect protection; a rollback that did not restore the expected outcome; a canary that reported success without an artifact. Run the classifier and its assertions: The observed result is eight reachable endpoints, one READY release, and seven blocked releases. The gate returns the first actionable state rather than a percentage: This precedence matters. If a receipt belongs to an older digest, inspecting its detailed result can waste time because the evidence is not admissible for the current release. Once identity and freshness pass, the operator can act on the specific boundary: adjust a scope, repair a schedule, rerun the rollback drill, or implement a destination verifier. Do not turn unknown into pass. If an external system is unavailable during the canary, the result is BLOCKED OUTCOME UNVERIFIED , not a guessed success. If the task cannot be verified deterministically, use a bounded human review and retain the decision receipt, reviewer authority, release digest, and time. Promote in stages without weakening the evidence contract The Google Cloud production agent guide recommends progression from sandbox to canary to production. Keep the same five receipts at every stage; change the allowed exposure, not the meaning of ready. In a sandbox, the permission receipt can use synthetic accounts and the outcome can target a disposable destination. In canary, route a small bounded cohort, prohibit irreversible actions unless separately approved, and collect the same destination level receipt. Before full promotion, refresh current state checks and confirm the rollback target remains available. Choose freshness windows from operational risk. A reachability or permission receipt may expire in minutes; a rollback drill might remain valid for days if neither the deployment mechanism nor destination contract changed. Re run the drill when the runtime, tool authority, state schema, or rollback path changes. Record the rule beside the timestamp so “fresh” is inspectable rather than subjective. After promotion, these receipts become monitoring inputs, but the deployment decision and continuous health are not the same system. A release that passed at 21:00 can lose a credential at 22:00 or miss a scheduled run at 23:00. Preserve the release manifest, then evaluate new occurrences and outcomes on their own deadlines. Keep the boundary honest This fixture tests decision logic, not a live cloud platform. Permission names, scheduler fields, freshness windows, canary safety, rollback duration, and outcome oracles must be adapted to the real environment. The five receipt structure is useful because those adaptations remain explicit. Sidewisp is currently in private preview. Its production monitoring adapters and recovery systems are not generally shipped. The readiness gate described here is a local operating practice that teams can implement today, not a claim that Sidewisp currently deploys agents, watches live releases, or performs rollbacks. The relevant private preview question is whether future health evidence can keep reachability, authority, schedules, recovery, and verified outcomes separate—without turning one green process check into a production verdict.