Public works wants clear separation between a sandbox Foundry project and the production resident-facing agent. Which environment design is appropriate?

Public works should maintain separate Foundry projects or environments for sandbox experimentation and production resident-facing agents. Separation prevents experimental prompts, models, or tools from affecting live residents. Environment design is a core plan-and-manage concern for municipal AI: sandbox for learning and iteration; production for controlled, supported service with change control. Using a single Foundry project with isolated deployments for sandbox experimentation and resident agents fails isolation — separate deployments still share the same project control plane, quotas, connections, and data scope, so experiments can contend with resident traffic and misconfigured prompts or tools can affect production. Maintaining separate agent versions in one Foundry project for sandbox experimentation and production use fails environment isolation — versions are labels in a shared project, not separate boundaries for identity, secrets, data, and networking, so an untested version can be called or promoted into resident service without change control. Connecting sandbox and production agents to one Foundry project with role-based experimentation access fails environment isolation — roles limit who can act but the agents still share project resources, deployments, and data, so a permission error or experimental change can reach live residents. Exam caveat: separation means separate projects or environments with their own identity, secrets, networking, and data—not only isolated deployments, separate versions, or role-based access inside one shared Foundry project. Operational check: prove a sandbox change cannot reach production endpoints without a defined promotion path, and verify production has backup/restore and documented config rather than 'rebuild from memory' procedures.