Blog

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

Three identical matte trays one behind another, the front one with a green edge

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

  1. The production key is set only in your production deployment.
  2. Every enabled endpoint is one the live agent actually uses.
  3. Write operations you have not tested in staging are switched off.
  4. The OAuth scopes requested match what your product needs, and no more.
  5. Your team knows which statement to watch for live usage.

Read more about permissions and environments on the Security page.

Stacks of envelopes being organised into an index card cabinet with green tabs
Product

iGPT: your agent’s email context in one request

iGPT is a premium connector on Agent200. It indexes your users' email, threads and attachments, and answers your agent with cited, structured context in…

1 min read

Five frosted glass lenses of different shapes in a row, one with a green edge
Guides

Choosing a web search API for your agent

Tavily, Exa, Brave Search, Perplexity and Firecrawl each lean toward a different part of search. How to pick for your agent, and why you…

2 min read

200 OK

Build the agent.
Access everything it needs.

Bring the agent you already have. Agent200 provides and executes its external capabilities.

Book a demo.
See it in action.

Tell us who you are, then pick a time for a 1:1 session with an expert from our team.

We use your details only to email you about Agent200. See the Privacy Policy.

Pick a time. We'll take it from there.

A 1:1 session with an expert from our team, about what you are building.

Open in Calendly (opens in a new tab)