Development, staging, production: environments for your agent
Give the agent you build, the one you test and the one your customers use their own keys, services and statements. A setup that works, and a checklist before going live.
2 min read

An agent that can send messages and edit records deserves the same release discipline as any other production code. Agent200 supports multiple projects and environments, so the agent you are building, the one you are testing and the one your customers use can each have their own setup.
What an environment holds
Each environment carries its own settings, integrations and credentials. In practice that means:
- Its own API key. A key gives access to the capabilities permitted in its project or environment, and nothing else.
- Its own services and endpoints. Enable an operation in development without exposing it in production.
- Its own statement. Paid model requests and paid services are consolidated per environment, so testing never blurs into production usage.
A setup that works
Development
Your laptop and your preview deployments. Enable broadly, use your own test accounts, and try new workflows here first. Keep this key in your local environment file and out of your repository.
Staging
A copy of production’s configuration with test users. This is where you confirm that a new write operation behaves, that the OAuth consent screen asks for the scopes you expect, and that a workflow returns the shape your code reads.
Production
Only what the live agent needs. If the agent should read email but never send it, that is the configuration here, whatever you are experimenting with elsewhere.
Promote a capability the way you promote code: try it, test it, then enable it where your users are.
Keys stay in their lane
Because each environment has its own key, a development key cannot reach production’s configuration. Store each key with the deployment that uses it, and only there.
A short checklist before going live
- The production key is set only in your production deployment.
- Every enabled endpoint is one the live agent actually uses.
- Write operations you have not tested in staging are switched off.
- The OAuth scopes requested match what your product needs, and no more.
- Your team knows which statement to watch for live usage.
Read more about permissions and environments on the Security page.


