Agent 37 Cloud - Give every customer their own Hermes or OpenClaw agent

Agent 37 is managed hosting for persistent agents like Hermes, OpenClaw and ClaudeCode. So you don't need to run them on Mac minis or VPS yourself. One API call gives each of your customers their own always-on agent, from $3.44/mo. Founders use it to ship vertical agents to their own clients without babysitting servers.

Add a comment

Replies

Best

Congrats on the launch 🚀 Agent 37–38 looks sharp, excited to see how it pushes AI agents into real workflows!

 Thanks!

The per-customer agent model makes a lot of sense for vertical SaaS. What I keep thinking about is observability: how does a founder show their client what the agent actually did?

Logs the end customer can understand, or at least something you can point to when they ask, "what did it do this week?" Is that on the roadmap or already there?

 We do have observability at the container level and logs around that, but what happens inside a container is upto the user for now. We do provide default ready to use templates for hermes, openclaw etc. But it's extendible so that you can add-on observability as you see fit. Especially the one's I think you're referring to which is more for the end customer.

Love this! But - are you compliant with EU laws?
Under what jurisdiction does your company run and do you have a DPA for EU/GDPR compliance?

Thanks  We're currently US based but we have a few EU users who are also asking for GDPR compliance. We're working with them to get it ready for it, and will be adding EU servers soon so that it's an option for EU users.

This solves the exact tradeoff I keep running into. I looked at self-hosting part of my own AI agent stack to save on a per-minute provider fee, and the math always won on paper but lost in practice: the real cost wasn't the server, it was becoming the person who gets paged when an agent goes down for a paying client. $3.44/mo always-on, not-my-problem-to-babysit is the right price for that peace of mind. Curious how you handle noisy-neighbor isolation between customer instances at that price point.

 That's great to hear. Would love to hear what your product us doing where you're seeing this trade off ? Here's my calendar if you wanna chat -

We started off with a direct to consumer Hermes/Openclaw hosting and saw the same problems there where we run a large fleet of sandboxes. Interestingly what we've also noticed is when you have a large enough host and that coupled with the fact that agentic use cases like hermes, openclaw, claude code etc. are 90% idle CPU times, the noisy neighbor issue is rarely a problem.

The interesting constraint here is handoff quality: if each customer gets a persistent agent, the audit trail and failure state need to be as easy to inspect as the API call is to start.

 Agreed, for now we have resource monitor and logs in the dashboard to inspect which serves most of the needs. But we also plan to expose it as an API for more agentic debugging.

The unit economics here look incredible for SaaS teams wanting to deploy dedicated AI features. At $3.44/mo per customer agent, how do you handle resource provisioning if a client's agent suddenly experiences a massive spike in background workflows or data processing?

 Thanks yes. We strive to offer the best unit economics :)
We do have tier limits for now, for example a new account, starting with a tier 1 account can only scale to 10 instances limit. They will need to pre-pay a certain amount before we update it to tier 2 and so on unlocking more instances. This also gives us predictability of scale that we can account for.

Judging by the cost structure, this appears to be serverless. I’m curious about the latency on cold paths and whether usage-based billing will apply later on.

 The latency right now is 1-2 seconds for bootstrapping cold. For the use cases I'm seeing bootstrap time is not really a P1 concern so not something we're optimizing for.

It's already usage based billing btw, we don't bill the whole $3.74 initially, it's billed on an hourly basis based on how long the instance exists.

I can see this being useful for SaaS companies that want to give every customer their own AI assistant without building the backend themselves.

 absolutely!

The per-customer always-on agent angle is the useful part here. I’ve seen the same “agent infra becomes a babysitting job” problem once tools and permissions differ by client. Curious how you separate tenant secrets/tool scopes when an agent is idle most of the time but still persistent?

 Each tenant is given their own separate container inside of which all tool calls happen and it has it's own data. So this keeps it separate from each other.

what happens when one customer's agent goes rogue, infinite loops, runaway API calls to other services, anything that spikes cost or behaves unexpectedly? since each customer gets their own always-on instance, curious whether there's any per-agent resource capping or kill-switch a founder can configure, or if that's left entirely up to whatever the founder builds on top of Agent 37

 We do have resource monitoring to track and catch such things, but largely what a user runs inside their sandbox is upto them

 monitoring helps you detect it, but curious if there's anything automated that acts on it, like a default spend cap or auto-pause if a sandbox blows past expected usage, or is detection mainly there so you (Agent 37) can see what's happening, while the actual response (pause, kill, alert the founder) is something the founder has to build themselves on top

 Oh yes we do have monthly and total spend caps you can set when creating an instance. In Addition there's also monitoring dashboard where you can see peak CPU usage, RAM usage, how many times RAM hit peak, CPU wait time etc. We're adding more every week, but these are some things that already exists