No deploy window: Slack / Teams / Chatwork agent builder shares update design

The piece draws its contrast from ordinary web apps, where a rolling update works because each request is answered and then finished, so machines can be swapped one at a time. A resident agent is different: a single turn can take seconds to tens of seconds across LLM inference (the step where the AI produces an answer) and external API calls, and killing the process in that stretch looks to the user like being ignored. The same gap shows up in stored conversation state, such as a pending confirmation, where a new version that cannot read the old format leaves the conversation hanging.

The suggested remedies are deliberately staged. State carries a schema version, and a read-compatible release ships before writes move to the new format, so both versions stay readable for a defined period. Giving in-progress state an expiry date is what lets that period end, since migration can be bounded by the longest-running conversation and the old reading code can eventually be deleted; without an expiry, compatibility branches accumulate on every later change.

The write-up also separates releasing from enabling. Because a code swap that never drops a request can still change every answer at once, prompt and decision-logic changes are gated per tenant and widened from internal tenants outward, so a problem can be reverted within a small slice. It adds a limit to that safety: only code and configuration can be rolled back, and notifications or writes already sent cannot, so hard-to-undo operations need human confirmation alongside the rollback plan.