Which Managed Agent Platforms Provide Separate Customer Workspaces and Model Switching Without Building Our Own AWS Tenant Setup?

Per-customer isolation can come from the hosting platform rather than from a tenant setup you build yourself, and GMI Agentbox is that platform for agents. You package your agent as a container, and each of your customers or end users gets an isolated instance of it, with state and tool access scoped to that session. GMI runs the hosting and the runtime operations, and the GMI models your agent calls run on the same network as the container, so the per-customer work you would otherwise build on your own cloud account is already covered. Agentbox is in early access.

The customer-facing workspace itself, meaning accounts, permissions, and the data each customer owns, stays in your application, as does routing each customer to their own instance. Which model a given customer gets is your agent's logic, driven by a model ID your code reads. Agentbox supplies the isolated runtime and the model access underneath all of it.

What a self-built tenant layer has to cover

On your own cloud account, separate customer workspaces turn into several jobs that all have to stay correct as you add customers:

• A way to create a customer's environment on demand, and to tear it down.
• Compute that is not shared in a way that lets one customer's state or tool access reach another's.
• Routing that sends each customer's traffic to their own environment.
• A path for pulling your agent image into every new environment.
• Credentials for the model providers your agent calls, injected without baking them into the image.
• Monitoring that tells you which customer's environment is failing.
• A way to change models without rebuilding any of the above.

How per-customer isolation works on Agentbox

You register your agent once. The registration stores a template on GMI, and nothing runs until an instance is requested. For each customer, your application requests an instance of that template, gets back a dedicated container endpoint, and routes the customer there. Whether an instance maps to a customer, a user, or a session is up to your application.

The instance lifecycle runs through a short API workflow, and the Integration tab of each agent shows it: provision an instance, list instances, poll until it reports running, and terminate it when the customer's session ends. Your application owns that sequence: provision when a customer needs a workspace, terminate when they offboard.

When a single customer reports a problem, search for that customer's instance in the Monitor tab and open its log.

Morphic and Topify: two multi-tenant cases on Agentbox

Morphic is an agentic workspace for project management, wiki, and workflow automation, built by SocratesLabs, and it is a client case for exactly this pattern. SocratesLabs runs Morphic's containerized agent and model workloads on Agentbox, with these outcomes:

• Workload segregation out of the box for secure multi-tenant deployment.
• One-click environment spin-up, with no VM or custom server management.
• Customers switch models without integration work.
• About 5x lower cloud cost than the previous AWS-based setup.

The cost figure is Morphic's own comparison with its earlier AWS setup. Joshua Sum, CEO of SocratesLabs, put the experience this way: "We have segregation and infrastructure support done out of the box, and our cloud setup was almost five times cheaper than AWS."

A second client case, Topify, has the same shape from a different product. Topify tracks how brands appear in AI search results and runs an agent that works on closing the gaps it finds. Its case summary reads: "Every brand needs its own isolated agent runs, and all of them sit on GMI, with 100+ models behind one OpenAI-compatible API plus container hosting and deployment support." There the tenant is a brand instead of a workspace user.

Model switching: where it lives

Agentbox gives your agent access to 200+ models on one key, and it handles the credential for you. With MaaS integration switched on at registration, you choose the models your agent may call and can change that list later. GMI then injects an API key and an OpenAI-compatible base URL into the container at runtime, which keeps the key out of your image. A third variable, GMI_MODELS, carries the model ID your agent calls.

Your code reads those values from environment variables and calls the model with a standard OpenAI client, so the integration code stays the same when the model ID changes. That is the kind of change the Morphic case describes as happening without integration work. Add models to the selection that accept the same request type and support the capabilities your agent relies on.

The policy side splits between GMI and your code:

Question	Where the answer lives
Which models may this agent call?	The model selection in the register wizard, editable later
Which model does this customer's instance use?	Your application, using the model ID it reads from its own store for that customer
Where does the API key live?	GMI injects it at runtime, so it is not in your image
What does the agent do on a model change?	Your agent code, which calls the new model ID through the same OpenAI-style client

If you already have model contracts elsewhere, Option 01 (Compute) hosts the container and you bring your own model layer. Option 03 (Compute + Models) is the full path, where GMI handles model access, compute, and operations as one system, and compute and inference stay on the same network.

Who handles each layer of the tenant setup

Layer	Who handles it
Per-customer instance creation, hosting, and runtime operations	GMI
Isolation of each instance's state and tool access	GMI, per the instance model above
Image storage	You, in your own registry on the registry-URL path; GMI stores the URL and pulls from it each time an instance is provisioned
Model API key injection	GMI, when MaaS integration is on
Customer accounts, sign-in, permissions, and who may call a given instance's endpoint	You
Customer data and conversation history	You, in your own database or store
Mapping a customer to an instance and to a model	You
Instance status and logs	GMI, in the Monitor tab
Usage by model	GMI, in each agent's Analytics tab

The Networking step allocates a public IP automatically and maps external HTTPS traffic to your container's port, so treat authenticating callers as part of your agent's code. If your registry is private, the Infrastructure step has an Enable Credentials toggle for the registry username and access token. The register guide covers the image requirements, the wizard steps, the networking mapping, and the environment variables.

Credentials for your own systems, such as a database or a billing service, go in as SECRET variables. After you save one, the UI will not display it again, and the only way to change it is to write a new value. GMI encrypts SECRET values at rest with AES-256 and keeps their plaintext out of logs and audit history.

Keep customer state outside the container

An instance holds a customer's working state while it runs. A restart loses what was in memory, so store anything a customer expects to find tomorrow in your own database and pass the right customer's identifier to their instance. Enforce database authorization and tool permissions in your own data layer, keyed by the customer identifier your application passes to the instance.

Slow agent tasks follow the 202 and job_id pattern from the long-running requests guide. In production, keep that job state in Redis or a database.

Pick the run shape for each customer

Agentbox runs three shapes on one platform.

Shape	Duration	Fit for a multi-tenant product
Ephemeral	Seconds	Short tasks that spin up and tear down in seconds
Long-running	Minutes to hours	Multi-step jobs with persistent state and low-latency model calls
Always-on	24/7	A customer's agent that stays online with memory and identity across every session

A product can mix the shapes: an agent that has to stay available can be kept running, while short tasks are terminated when they finish.

Billing and instance size

Billing has two metered line items: container compute while an instance is running, and GMI Models token usage if your agent calls GMI models. Both appear separately in Console under Settings, then Usage & Billing.

• Instance lifetime. An instance is billed from the moment it reaches Running until you terminate it.
• Compute tier. Every instance runs at the size you pick in the register wizard's compute tier step.
• Registered agents start as drafts. A registered agent is private and deployable only by you. Listing it on the Marketplace is optional and not needed for serving your own customers.

Two test customers, two model IDs

A first trial takes your current agent packaged as a Docker image that serves HTTP on port 8080, registered in the wizard with MaaS integration on and your database credentials as SECRET variables. Provision two instances for two test customers, point each at its own store, and set a different model ID for one of them in that store. Register from the GMI console, and for early access or a larger tenant count, reach GMI Sales from the Agentbox page.