AI Agent Hosting vs. AI Agent Runtime: Why Hosting Isn't Enough
This post was drafted with AI assistance and is reviewed and published under a human byline.
If you search "AI agent hosting" you get a familiar list: Railway, Render, Fly.io, maybe a VPS roundup. These are good articles about a real question. Where do I run this thing? But they all answer a subtly wrong question for teams putting agents into production.
Hosting answers: where does the process live? What teams actually need answered is: who owns memory, credentials, approvals, retries, observability, and recovery once the agent is live?
That second question is the runtime layer. This post explains the difference and how to tell which one you're actually buying.
What hosting gives you (and what it doesn't)
A hosting provider gives you compute, a network endpoint, a deploy pipeline, and usually some logs. For a web service, that's most of the problem. For an agent, it's the easy 20%.
An agent in production needs things hosting platforms deliberately don't provide:
- Persistent, structured memory. Agents that restart stateless forget everything between runs. Hosting gives you a disk. It doesn't give you a memory system with lifecycle semantics, retrieval ranking, or isolation between agents.
- Credential and connection management. Your agent calls HubSpot, Stripe, GitHub, your warehouse. Each connection has tokens, scopes, and rotation. Hosting stores env vars. It does not govern which agent can use which credential, or audit when it did.
- Human approval gates. Before an agent sends the email, refunds the charge, or merges the PR, a person should be able to review the exact action. Hosting has no concept of "pause this tool call until a human approves it in an inbox."
- Scheduling and event triggers. Production agents run on cron, on data-change events, on thresholds. Hosting runs a process. It doesn't wake your agent when a deal stage flips in the CRM.
- Recovery and receipts. When a run fails at 3 a.m., who retried it, what was the agent about to do externally, and where's the receipt of what it actually did?
You can build all of this yourself on top of a host. Teams do. It typically takes longer than building the agent did.
The runtime layer, defined
An AI agent runtime is the operating layer between your LLM and your production systems. It hosts the agent and owns the operational responsibilities around it:
| Responsibility | Hosting (Railway/Render/Fly) | Agent runtime |
|---|---|---|
| Compute & deploy | Yes | Yes |
| Persistent memory with decay/lifecycle | DIY | Built in |
| Structured records + knowledge graph for agent state | DIY | Built in |
| Credential scoping per agent | Env vars | Governed connections |
| Human approval before external actions | DIY | Inbox-gated tool calls |
| Scheduling + event triggers | Cron at best | Native triggers and data watches |
| Run logs, receipts, audit trail | App logs | Per-action receipts |
| Multi-agent coordination | DIY | Org charts, escalation paths |
This isn't a knock on hosting providers. They're excellent at what they do. The point is that "we deployed the agent to Railway" and "the agent is operated safely in production" are different claims.
A concrete example: the 3 a.m. refund
Say you have a support agent that can issue refunds. On bare hosting:
- The agent calls Stripe directly with a key in an env var.
- It hallucinates a refund amount at 3 a.m.
- You find out from a customer email. The log line, if it exists, says
POST /v1/refunds 200.
On a runtime with approval gates and receipts:
- The agent proposes the refund. The external action is captured as a pending approval with the exact arguments.
- A human approves or rejects it in an inbox. Nothing executes until then.
- The platform stores a receipt: who approved, what ran, what the API returned.
Same model, same prompt. Completely different operational posture.
What a runtime looks like in practice: SchemaBounce
SchemaBounce is a hosted AI agent harness. The runtime layer, not another hosting provider. Concretely:
- Agents run on schedules and triggers, not just chat. Cron, data watches, and event-driven wake-ups are native.
- The Agent Data Layer (ADL) gives each workspace a private store: persistent memory with decay classes (ephemeral/working/durable), typed entity records, a knowledge graph, and hybrid retrieval (vector + lexical). Memory isn't a bolt-on API. It's the same substrate agents read and write for state.
- External actions are approval-gated. Any effectful tool call (send, publish, charge) is captured as a pending action in the workspace Inbox. A human approves. The platform executes and writes a receipt. Chat messages saying "approved" don't count. Only the Inbox does.
- Connections are governed. MCP servers (256+ in the marketplace: HubSpot, Stripe, GitHub, Snowflake) attach with credentials stored server-side and scoped per agent.
- Multi-agent teams get org charts, escalation paths, and shared context, so a research agent's findings are queryable records for the writing agent, not text pasted between prompts.
- Bring your own model. Claude, GPT, Gemini, Llama, Kimi. Switch per agent without re-platforming.
You can still run your own services on Railway or Render alongside this. The runtime doesn't replace your hosting. It replaces the six months of glue code you'd write to make agents trustworthy on top of it.
How to tell which one you need
Ask these questions about your agent:
- Does it take actions outside your system (email, payments, posts, writes to a CRM)? If yes, you need approval gates and receipts. That's runtime territory.
- Does it need to remember anything between runs? If yes, you need a memory system, not a disk.
- Does more than one agent need shared context? If yes, you need structured shared state, not log shipping.
- Does it run unattended on a schedule or on data changes? If yes, you need native triggers with failure recovery.
- Is it a stateless request/response tool a human invokes directly? Then hosting is probably fine. Enjoy the simple life.
The category question isn't "where should I host my agent." It's "who operates it after I ship."