AI Agent Hosting Is Two Problems, and Only One Is Solved

Say "ai agent hosting" to three people and you may get three answers. The first is a runtime for the agent: sandboxes, memory, tool access, tracing. The second is a place to run an MCP server the agent calls. The third is a place to run the software the agent wrote.

The first has a well-funded answer. On 9 April 2026 InfoWorld reported Anthropic's Claude Managed Agents as "a set of composable APIs for building cloud-hosted agents on the Claude Platform", with the agent running on Anthropic's infrastructure. Other vendors ship the same idea. That is agent hosting in the narrow sense, and this post is not about it.

This post is about the third kind of ai agent hosting. An agent produces a web app, an API and a database. Something has to serve it on Monday morning. That something is a hosting product, and it has to work for a customer that is not a person.

Start with what can be verified. The numbers below are about agents and code volume. None of them says where the code runs, and we should be plain about that gap.

Read together, the picture is of a lot more code being written with agents, and more of it in TypeScript. Octoverse reports TypeScript overtook both Python and JavaScript in August 2025 to become the most used language on GitHub. That matters for hosting because TypeScript means web apps, and web apps need somewhere to run.

It is a modest claim, and we would rather make it than a big one we cannot back. We do not know what share of agent-written apps ever reach production. A fair guess is "fewer than are written", because most generated code is a prototype.

On ai agent hosting choices, our view, which is opinion and not measurement, is that apps land wherever the agent's first successful command lands. Agents copy what they have seen most often in training data and documentation, and they take the path with the fewest blockers. If a host wants a form filled in, an email confirmed and a card entered, the agent stops there and asks its human, or picks a different host.

That makes the default hosts the ones with a CLI an agent can drive without a browser and a free tier that needs nothing. It is a distribution effect. It has little to do with which platform is best for the application in the long run.

It also creates a gap. A host that suits the agent's first minute may not suit the application's first year. We think the industry will spend some time sorting that out, and the platforms that make the agent's first minute pleasant and the second year sensible will do best.

Four things, in the order an agent hits them.

1. 1No signup wallAn agent cannot read a confirmation email or type a card number, and it should not. A host needs a way for an agent to try things with nothing, and a way for a person to keep what it built. On Helm7 that is cloud_init, which creates a temporary workspace and a scoped key with no email and no card, and cloud_claim, which returns a link for a person to keep it. The Trial plan expires after 72 hours and is for trying things, not for running anything real.
2. 2Structured, stable errorsA model recovers from an error it can read. Helm7 returns a code, a message, a remedy and a request id on every failure, and says to branch on the code and never the message. The remedy is the useful part, because an agent told only that it lacks a scope will tend to retry the same call.
3. 3A dry run before every changeEvery operation that changes infrastructure takes dry_run and returns the changes, the monthly cost and anything that cannot be undone. We wrote about the design in why a deploy should show a plan first.
4. 4A hard limit on spendA key with a monthly cap and an expiry turns the worst case into a number. See scoped credentials for agents for the checklist.

That line from the protocol's own changelog is the same point as the second item. Errors are part of the interface an agent uses to correct itself, so a platform that hides its errors in HTML pages is harder for an agent to work with.

MCP is how many agents call tools, and Anthropic's December 2025 announcement said it had been adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code, among others. Someone has to run the servers. Running an MCP server is a small web service with a long-lived connection and a credential check, and it fits any host that runs containers.

The more interesting question is the reverse. A host can be an MCP server, so that the agent manages the deployment itself. Helm7 does that, with the same operations available over REST and MCP so that neither offers something the other cannot. The agents page shows the session, and the MCP server guide covers the protocol from scratch. For the adoption figures in detail, see our earlier post on MCP growth.

It is a fair one. Stack Overflow's 2025 survey, which had 31,877 responses to its agents question, found that 14.1 percent of respondents used agents daily at work and 37.9 percent did not plan to. That survey ran in 2025, so it is older than our twelve-month window and we cite it only as the baseline that the 2026 announcement says has since doubled. When the 2026 results appear, check them before trusting our reading.

Agents are not mainstream. They do not need to be for a host to care. A growing minority creating and deploying applications quickly is enough to change what a sensible default looks like,.

Helm7 is new, runs in two EU regions and is best at Next.js. If your agent builds something that needs a US region, a GPU or an edge runtime, use a host that has one. If you want the agent itself hosted, use a runtime built for that. What Helm7 offers is narrower: a place for an agent to try things without a person, to be bounded while it does, and to hand over what it built. Start with the quickstart if you want to test that claim.

What would change our mind: evidence that most agent-built apps never leave the platform where the agent wrote them. If that turns out to be true, the host matters less than we are arguing here.