Agent instance
An agent instance is one user's isolated agent runtime: their own process, their own memory, their own tool catalog, their own credentials. Multi-tenant agent platforms run many instances; per-user isolation prevents data or state from leaking between them.
Why it matters
A single shared agent serving thousands of users would be a privacy and reliability disaster. One user's prompt could pollute another user's context; one user's tool call could affect another's data; one user's bug could take down everyone.
The per-user agent instance pattern solves this. Each user gets their own runtime: their conversation history, their memory layers, their connected tools, their credentials. The runtime is isolated from other users at the process and storage level.
Architecturally:
- Process isolation. Each user's agent runs in its own container or VM. No shared in-memory state.
- Storage isolation. Each user's data lives in its own namespace. Database queries are scoped to the user; no shared rows.
- Credential isolation. Each user's OAuth tokens and API keys are encrypted with per-user keys (or at minimum, per-user namespacing).
- Compute isolation. A user with a runaway tool call cannot starve other users of compute.
The trade-off vs shared infrastructure: cost per user is higher (running separate containers), and the operational story is more complex. The benefit is that the per-user blast radius is bounded.
How Ajeris handles this
Ajeris runs one shared agent service rather than a separate runtime per user, and isolates each user at the data layer instead. Every request runs in its user's database context, so row-level security keeps that user's conversation history, memory, tool catalog, and credentials apart from every other user's, and the service keeps no state of its own between requests. A bug in one user's request cannot read another user's rows. Audit trails are per-user and access-controlled.
The pattern combines with encryption at rest and tenant isolation to keep the blast radius bounded.