Designing agents for many users from day one

A demo agent has one user: you. A product has thousands, each with their own accounts, their own data and their own permissions. Most agent architectures that break in production break here. Designing for many users from the first line of code is easier than retrofitting it later.

The two identities in every request

• Your application, identified by your Agent200 API key. It decides which capabilities exist.
• The end user the request is for. Their connections decide whose data the tools can reach.

Agent200 associates every user-specific operation with an end-user identity and that user’s authorized connections.

Conceptual example.

agent200.user("user_123").run({ ... })

What goes wrong without it

• One shared service account reads everyone’s data, so every user can, in principle, see everything.
• Tokens for many users sit in one table, keyed by something that is easy to mix up.
• A bug in one lookup sends user A’s email to user B’s assistant.

How the model looks with per-user connections

Your project
├── user_123
│   ├── Chat workspace A
│   └── Email account A
└── user_456
    ├── Chat workspace B
    └── Email account B

A request for user_123 uses user_123‘s connections. It never uses credentials belonging to user_456. You pass the identity; Agent200 keeps the mapping.

Four rules for your side

1. Use a stable internal ID. Pass your own user ID, not an email address that can change.
2. Set the identity once, at the edge. Resolve the user where the request enters your app, and pass that identity down. Never accept it from the client as free text.
3. Treat background jobs as users too. A nightly brief runs for a specific user; give the job that user’s ID.
4. Plan for missing connections. A new user has connected nothing. Handle the authorization-required response gracefully, with a clear prompt to connect.

Teams and shared accounts

If your product serves teams, decide early whose connection a shared task uses. A team summary might run as the team admin who connected the workspace; a personal brief always runs as the person it is for. Write the rule down, and encode it where you resolve the identity.

The payoff

With per-user connections handled by the platform, adding your thousandth user is the same as adding your first: they connect their accounts once, and every capability works for them, on their data only.

Read more about managed OAuth and the identity model.