How should agent workers drain before a deployment?

Deployment termination has a shorter clock than the task

An investigation may remain active for hours, while its worker is expected to exit within a short deployment window. The process should own bounded execution, not the entire lifetime of the task. Human waits and delayed callbacks need a durable owner that survives worker retirement.

The deployment drain therefore ends when current work is finished or transferred under the execution contract. It should not wait for every business task to become terminal. That distinction makes routine releases possible without abandoning accepted work.

Stop every source of new assignments

Changing readiness can remove a worker from ordinary service traffic, but an application may also poll a broker or receive assignments through a dispatcher. Disable each acquisition path. Make the drain flag idempotent so a deployment hook and a termination signal cannot produce conflicting shutdown behavior.

Continue only the operations required to settle current ownership: state commits, supported lease maintenance, evidence persistence, and handoff. A shutdown handler that disables its database client before recording the final task disposition defeats its own protocol.

A ninety-second shutdown with a forty-second step

In a constructed deployment exercise, a worker receives a 90-second termination budget while a model step has up to 40 seconds remaining. The service stops polling within five seconds, allows the bounded step to complete, and reserves time for state persistence and exit. A separate task waiting for approval is already represented durably and does not keep the process alive.

If the step cannot finish within the usable budget, the runtime follows its established interruption and handoff contract. It must not mark the task completed because the process is stopping, or acknowledge queue work before the required durable transition exists.

Use a drain timeline with observable milestones

The values below are teaching budgets. Measure actual shutdown behavior before selecting production limits.

Milestone	Illustrative deadline	Observable condition	If the condition fails
Stop acquisition	5 seconds	Pollers stopped; dispatcher excludes worker	Halt rollout expansion
Settle bounded step	50 seconds	Step result or supported interruption recorded	Start the defined handoff path
Transfer durable ownership	65 seconds	Replacement route exists; old ownership closed safely	Retain explicit unresolved disposition
Persist required evidence	75 seconds	Required records committed; export gap stated	Apply evidence-failure policy
Exit with margin	80 seconds	Process exits before 90-second budget	Investigate forced-termination exposure

Do not interpret the handoff row as permission to release a lease while the old executor can still commit. The runtime must fence stale ownership or otherwise establish an equally explicit protection.

Budget the hook and the process together

Kubernetes Pod lifecycle documentation describes a finite grace period, including lifecycle-hook handling, before forced shutdown. A long sleep in a hook consumes useful drain time; it does not create extra capacity for application cleanup.

Account for the actual signal path, process-one behavior, container ordering, and evidence sidecar lifetime. Confirm how the deployment mechanism reports progress when a drain stalls. Avoid treating replacement Pod readiness as proof that the departing process transferred its work.

Verify replacement using task records

Run a deployment exercise with a running step, a durable wait, and a delayed callback. Confirm that no new work reaches the draining worker, accepted tasks remain discoverable, and compatible replacements can advance eligible work. Include a forced termination to expose the residual reliance on graceful exit.

SQS’s redelivery behavior is one reminder that shutdown cannot rely on one-time delivery. The complete mechanism for ambiguous external operations belongs in preventing duplicate agent side effects.

A clean exit is one piece of release evidence

Draining verifies process retirement. It does not prove task quality, cancellation of remote effects, or cross-version state compatibility. Review active-task release compatibility before shrinking an old cohort, and use safe task resume for reconstruction after interruption. AI Agent Platform Engineering connects these boundaries into the operating contract.