The decision is not "Which logo hosts the agent?" It is "Who can operate, inspect, restore, and change every part of the runtime?"
What does AI agent hosting include?
AI agent hosting includes the runtime and every dependency required to keep the agent's work available, open to checks, and ready to restore. Google Cloud's reference architecture separates the hosting platform from the connected parts (Google Cloud, verified 18 September 2026). Those parts include models, memory, vector databases, tools, and code execution (Google Cloud, verified 18 September 2026). Mastra also separates the runtime from model access, persistent storage, secrets, tracing, and tool calls (Mastra, verified 18 September 2026).
Use this ownership map:
- Compute and runtime. Record where the agent process runs and who can deploy, stop, restart, or update it. Cloud Run documents services, instances, worker pools, and jobs as different runtime resources for agent workloads (Google Cloud, verified 18 September 2026).
- Model access. Record every model endpoint, the account that owns it, and the person allowed to change it. Google Cloud's architecture shows the orchestration layer calling models hosted through several possible services (Google Cloud, verified 18 September 2026).
- Files and state. Record working files, conversation state, workflow checkpoints, memory, and the store used for each one. Mastra states that stateful agents need a durable store (Mastra, verified 18 September 2026). It also states that in-memory state does not survive a server restart (Mastra, verified 18 September 2026).
- Secrets. Record model keys, database credentials, and tool credentials, plus who can create, read, rotate, or revoke them. Mastra recommends keeping provider credentials server-side and using environment variables or a secret store instead of hardcoding them (Mastra, verified 18 September 2026).
- Logs and traces. Record which events are captured, where the records go, and who reviews them. Mastra describes traces spanning model calls, tool invocations, memory retrieval, and the final response (Mastra, verified 18 September 2026).
- Backups. Define which persistent stores, files, and configuration enter the backup scope. The sources establish that state must persist outside process memory; the exact backup scope remains a deployment decision (Mastra, verified 18 September 2026).
- Recovery. Name who restores each retained component and who accepts the restored service. Mastra identifies retries and failure recovery as production hosting concerns, while the actual recovery procedure remains specific to the deployment (Mastra, verified 18 September 2026).
The list exposes a common gap. A provider can operate the compute while your firm still owns model accounts, tool credentials, data stores, or recovery decisions. An operator-owned server can reverse the compute assignment while still calling outside models and tools (Google Cloud, verified 18 September 2026).
How do managed hosting and an operator-owned box compare?
Managed hosting and an operator-owned box assign the default runtime operator differently. Both still need an owner for every required duty. Mastra describes managed runtimes as a trade of operating work for dependence on a provider's abstractions and pricing model. It describes self-hosted servers as flexible deployments whose operator handles scaling, monitoring, and restarts (Mastra, verified 18 September 2026).
| Ownership row | Managed agent hosting | Operator-owned box | Evidence to collect |
|---|---|---|---|
| Compute. | Provider operates the supplied runtime within its documented service boundary. | Named operator runs the host or container. | Deployment target, administrator list, restart route. (Mastra, verified 18 September 2026) |
| Model access. | May be bundled or connected through a separate provider account. | Operator configures local or external endpoints. | Endpoint list, account owner, change authority. (Google Cloud, verified 18 September 2026) |
| Files and state. | Provider may supply storage, or the buyer may connect a store. | Operator selects and runs the persistent stores. | Store map, access roles, persistence test. (Mastra, verified 18 September 2026) |
| Secrets. | Platform secret store may hold credentials. | Operator selects the secret mechanism. | Credential inventory, rotation owner, revocation route. (Mastra, verified 18 September 2026) |
| Logs and traces. | Provider tools may capture selected events. | Operator selects and runs the logging tools. | Event list, destination, reader roles. (Mastra, verified 18 September 2026) |
| Backups. | Confirm the exact included stores and files. | Operator defines and runs the backup scope. | Retained components, backup owner, current record. (Mastra, verified 18 September 2026) |
| Recovery. | Confirm provider and buyer duties separately. | Operator owns the written restore route. | Restore owner, acceptance owner, recovery record. (Mastra, verified 18 September 2026) |
This table is a worksheet, not a vendor guarantee. Complete it from the selected service's current documentation, configuration, and operating record.
See the AI Jungle OS cockpit if you want to compare an operator-owned, done-with-you box against a managed runtime without hiding the responsibility split.
Can I host an AI agent?
Yes. You can host an AI agent with a resource that matches its work. Google Cloud maps stateless, request-driven agents to services and dedicated, stateful loops to instances (Google Cloud, verified 18 September 2026). It maps distributed background fleets to worker pools and bounded workflows to jobs (Google Cloud, verified 18 September 2026).
The deployment target is only part of the map. A hosted agent can call external models and keep memory in a separate store (Google Cloud, verified 18 September 2026). It can also query a vector database, use tools, and execute code (Google Cloud, verified 18 September 2026). Hosting succeeds as an operating decision only when those paths have owners too.
Match the runtime to the work:
- Use a service for request-driven work. Google Cloud presents services for stateless agents that respond to variable user traffic (Google Cloud, verified 18 September 2026).
- Use an instance for a persistent loop. Google Cloud presents instances for dedicated, stateful, always-on agent loops (Google Cloud, verified 18 September 2026).
- Use a worker pool for queued background work. Google Cloud presents worker pools for distributed agents that consume tasks from queues without a public HTTP endpoint (Google Cloud, verified 18 September 2026).
- Use a job for bounded execution. Google Cloud presents jobs for workflows that run to completion, including scheduled or batch work (Google Cloud, verified 18 September 2026).
These are examples from one platform's resource model, not universal product categories. Apply the workload description to every candidate and verify its actual limits.
Where should files, secrets, and logs live?
Place each work record in a named store, then assign its access and upkeep owner. A stateful agent needs durable storage when its state must survive a restart (Mastra, verified 18 September 2026). That state can include conversation history, working memory, or workflow checkpoints (Mastra, verified 18 September 2026). Google Cloud lists separate memory and vector-database components in its reference architecture (Google Cloud, verified 18 September 2026).
Do not collapse those stores into the word "data." Write a row for each type that the work uses. These types may include uploaded files, workflow state, conversation memory, retrieved documents, and final outputs. For each row, name the storage service, access roles, retention decision, backup scope, and recovery owner. The sources support separating memory, databases, and runtime state. The exact retention and recovery choices belong to the deployment (Google Cloud, verified 18 September 2026; Mastra, verified 18 September 2026).
Keep secrets separate from content. Mastra says model keys, database connection strings, and third-party tool keys should stay server-side in environment variables or an appropriate secret store (Mastra, verified 18 September 2026). Record who can alter each secret and how the operator revokes it.
Treat logs as their own data path. Mastra describes production traces that record model calls, tool invocations, memory retrieval, and the final response (Mastra, verified 18 September 2026). Decide which of those events the workload needs, where they go, and who can inspect them. Do not infer the answer from the compute location.
A box location is not a data map. The useful record names every store, credential path, log destination, and outside service used by the agent.
Who owns backups and recovery?
The backup owner preserves the agreed parts. The recovery owner restores them and presents the result for acceptance. Durable state keeps the running process from being the only copy of workflow state. Durable storage alone does not define a backup or restore plan (Mastra, verified 18 September 2026).
Write the handoff before launch:
- Scope. List the files, state stores, configuration, and records the backup includes. Mastra distinguishes application state and persistent storage from the runtime process (Mastra, verified 18 September 2026).
- Operator. Name the person or provider responsible for the backup process. Managed and self-hosted options assign operating work differently, so confirm the duty for the selected service (Mastra, verified 18 September 2026).
- Restore route. Write which component returns first and who performs each restore action. Mastra treats failure recovery as a production hosting concern but does not prescribe one universal procedure (Mastra, verified 18 September 2026).
- Acceptance. Name the person who checks that the restored agent can perform the approved workload. Google Cloud's resource model separates runtime types and connected components, so the acceptance scope must match the deployed architecture (Google Cloud, verified 18 September 2026).
- Evidence. Keep the latest backup and recovery record with the ownership matrix. The cited sources establish the components and persistence concern; this record is the operator's evidence for the chosen deployment (Mastra, verified 18 September 2026).
If a managed proposal says "backups included," ask which stores and configuration that phrase covers. If an operator-owned box says "we control the data," ask who runs the backup and who accepts a restore. Those are procurement questions, not claims about either model.
What are the best AI agent hosting platforms?
The best platform is the one whose documented runtime matches the workload and whose responsibility map your team can actually operate. This is an editorial decision rule, not a vendor ranking. The allowed sources document resource types and operating tradeoffs, but they do not establish one universal winner.
Compare each candidate against the same workload and ownership map. Record every external model, store, tool, secret, and log destination. Assign backup and recovery owners. Keep any missing answer visible as unresolved. This method lets a managed platform and an operator-owned box face the same questions.
FAQ
Can I host an AI agent?
Yes. Agent runtimes can be deployed as request-driven services, persistent instances, background worker pools, or jobs, depending on the workload (Google Cloud, verified 18 September 2026). You still need named owners for models, state, tools, secrets, logs, backups, and recovery.
What are the best AI agent hosting platforms?
The captured sources do not support a universal ranking. Compare the runtime type and the ownership of compute, model access, files, secrets, logs, backups, and recovery. Then choose the candidate that fits the workload and leaves no required duty unassigned.
See the AI Jungle OS cockpit to examine a done-with-you, operator-owned box with the responsibility map in view.
Written by Tileo, who operates a portfolio of internet businesses on this same cockpit.