Built a way to give every customer their own AI agent with one API call
Over the last few months, we kept seeing the same problem.
Founders wanted to build AI agents for their customers but once they moved beyond a prototype, infrastructure became the real challenge.
Each customer needed their own agent, memory, files, tool connections and isolated environment. That usually meant managing VPSs, containers, networking, state, monitoring, and a lot of operational work that had nothing to do with the product itself.
So we built https://www.agent37.com/cloud.
The idea is simple: every customer gets their own persistent AI agent.
One API call creates a dedicated agent instance. Another API call lets you message it. The agent keeps its files, memory, connected tools, and conversation history until you decide to remove it.
Here's what creating an instance looks like:
Once the instance is running, you can interact with it through a simple API.
Under the hood, each customer gets their own isolated environment, whether they're using Hermes, OpenClaw, or a custom setup.
A few things the platform supports today:
Persistent memory and storage. Hermes and OpenClaw hosting, Custom Docker images. Gmail, Slack, Notion, and 1000+ integrations. Terminal, desktop, and file browser access. Scheduled runs and background tasks
Usage based pricing starting around $3.44/month per always-on agent
And here's what the dashboard looks like when managing multiple customer instances:
Looking for feedback from builders who are working on AI products.
If you're building AI agents today, what's been the bigger challenge for you:
Building the agent itself, or operating it reliably for real customers?
this is useful. congrats!
Thank you for the encouragement!
This is one of those products where the value becomes obvious once you've tried managing agents in production. Building is fun. Maintaining everything around it is usually the hard part.
Yeah, that’s exactly what we kept running into. Prototype stage feels simple, but once you start handling real users, the “everything around the agent” layer becomes the actual product — state, isolation, failures, retries, tool drift, all of it starts compounding. Have you seen any part of that become the biggest pain for you specifically?
this is the part most builders underestimate. shipping the agent is easy, keeping it stable across thousands of users is the hard work
Exactly. Getting an agent to work is often the easy part. Keeping it reliable, consistent, and observable across thousands of users is where the real engineering challenge begins. That's the gap we kept seeing, and a big reason we decided to focus on the operational layer rather than the agent itself.
The architecture question I'd push back on: in enterprise deployments, the hard part isn't provisioning one agent per customer — it's defining what each agent is authorized to decide vs. what it needs to escalate. We've had clients where agents technically completed tasks correctly, but made decisions that required human sign-off under their compliance framework. Nobody had written that down before the agent went live. The "one API call" abstraction is elegant. The accountability layer underneath it is where most B2B deployments stall.
That's a great point. Making agent deployment simple doesn't remove the need for clear boundaries around what an agent can and can't do. In many enterprise environments, the challenge isn't whether a task can be automated—it's knowing when human review or approval is required. The infrastructure layer solves one part of the problem, but accountability, governance, and decision boundaries are equally important for real-world deployments. Appreciate you highlighting that distinction.
Creating the instance looks like the easy part. Keeping hundreds of stateful agents observable and upgradeable is probably where things get messy.
How are you handling rollbacks and version changes without breaking customer memory or files?
You're absolutely right that creating the instance is only the beginning. Once you have hundreds of persistent agents, observability, upgrades, and reliability become much bigger challenges than provisioning itself. A lot of the complexity lives in making changes safely while preserving the state and continuity that users depend on. Those operational concerns are exactly what pushed us toward focusing on the infrastructure layer in the first place.
the operations side is definitely the harder problem long term. building the agent is a weekend project now, but the moment you need per-customer isolation with persistent memory and reliable tool access, you're basically running a mini cloud provider. smart to abstract that away — most teams I've seen underestimate the infra cost until they're 3 months in and spending more time on container orchestration than on the actual agent logic.
Appreciate this. That's exactly the shift we kept seeing. Building an agent has become increasingly accessible, but operating large numbers of customer-specific agents reliably is a very different challenge. The "mini cloud provider" comparison is surprisingly accurate. Once you add isolation, persistence, integrations, and reliability requirements, a lot of the work moves away from the agent itself and into the infrastructure around it. That's the layer we're trying to simplify for builders.
The part I’d be most interested in is the runtime/action boundary.
If a customer can spin up a persistent agent with memory, files, tools, scheduled runs, terminal access, and integrations, the security question is not only whether the instance is isolated. It is also:
who authorized this agent to exist,
which tools is it allowed to use,
what source triggered this action,
what evidence supports it,
and why is it allowed to execute now?
Sandboxing protects tenants from each other. But high-impact actions inside the sandbox probably need their own gate too, especially for exports, record changes, messages, workflow triggers, terminal commands, or billing/security-sensitive operations.
The "one API call per customer" approach is exactly how this should work. Most frameworks force you into using their specific dashboard or UI, but if you're actually trying to build a native feature into an existing app, you just want a clean backend service you can query. "Render for agents" is a great way to look at this. Nice work, Vishnu.
Thank you, really appreciate that. That was a big part of the thinking behind it. Many teams want to embed AI agents directly into their existing products, not force users into a separate interface. The goal is to make the infrastructure disappear into the background so builders can create the experience they want on top of it. Glad the approach resonates, and thanks for the support.
This is the part that feels most important to me too: prototype UX is not the same as production reliability.
I am working on Tokens Forge from the other side of the stack, mostly model routing, usage tracking, and giving builders one OpenAI-compatible API for multiple model families. The pattern I keep seeing is similar: the agent itself is only one layer; the hard parts are isolation, routing, observability, cost controls, and clear failure states.
For your customer-specific agent instances, how are you thinking about debug visibility for the end customer? Do they get enough trace/history to understand why an agent failed, or is that mostly an operator-facing tool right now?
That's a great question. We think visibility is a critical part of making agents usable in production. Infrastructure is only half the problem—when something goes wrong, builders need enough context to understand what happened and debug it quickly. We're spending a lot of time thinking about observability and traceability because an agent that can't be inspected is difficult to operate at scale.
Smart to charge per always-on agent instead of per seat. It ties your revenue to your customers' growth, which compounds when they scale, but it also means your MRR rides on their retention, so the founders you onboard need to be ones who actually ship. At $3.44 a month the moat won't be the infra, it will be the integrations catalog and uptime, because that is the piece a customer can't rebuild on a weekend.
Really appreciate this perspective. You're right that long-term value comes from much more than simply running an agent. Reliability, integrations, and the overall developer experience become increasingly important as customers scale and depend on the platform for real workloads. I also agree that our success is closely tied to our customers' success. The more they can ship, grow, and serve their own users without infrastructure becoming a bottleneck, the better the outcome is for everyone involved.
The infrastructure problem you're pointing to is real and it's still massively underestimated. Getting an agent to work in a prototype is genuinely easy. Making it work reliably for 50 different customers, each with their own memory, their own tool connections, their own execution history, is a completely different challenge. One thing I'd push on is that isolation is only half the answer. The other half is shared context across the system — not shared between customers, but shared between the agents serving a single customer across different sessions. Without that, agents restart every conversation with no awareness of previous decisions, previous constraints, or previous failures. You end up with inconsistency that's hard to diagnose because nothing technically breaks. One thing worth thinking about early: logging the "why" of a decision alongside the output, not just the output itself. When something goes wrong at scale, having decision traceability is what separates teams that debug quickly from teams that start over. What's your current approach to surfacing when agent behaviour drifts from expected output across different customer instances?
Really appreciate this thoughtful perspective. I completely agree that isolation alone isn't enough. Persistent context, decision history, and continuity across sessions become incredibly important once agents are handling real workflows over time. The point about logging the "why" rather than just the output also resonates—many of the hardest issues aren't outright failures, they're subtle behavior shifts that only become visible later. Observability and traceability are definitely areas we're spending a lot of time thinking about, because as you said, reliability at scale depends as much on understanding agent behavior as it does on running the infrastructure itself.
AI costs are becoming a real issue for small teams. I've been experimenting with multi-model setups to reduce cost.
Absolutely. As teams move from experimentation to production, AI costs become much more visible. Multi-model setups are an interesting approach because not every task needs the most expensive model. We've seen more builders thinking about routing workloads based on cost, latency, and capability rather than relying on a single model for everything.
the framing of "infrastructure became the real challenge" past prototype is the part that rings true, the demo of "give your customer an AI agent" is easy, the part that actually eats months is exactly what you listed, isolated state per customer, monitoring, what happens when one instance misbehaves. curious what the actual breaking point was for you, was there a specific moment building your own product where the infra work started outweighing the product work, or did it become obvious gradually
This hits on such a real pain point. So many founders nail the prototype but then drown in infrastructure once they try to give every customer their own persistent agent with memory, tools, and isolation.
The “one API call per customer” approach looks super clean. How’s the pricing structured? Is it usage-based or per agent?
Also curious — who do you see as your early users? SaaS companies embedding agents for their own customers, or smaller teams that want to offer AI agents without managing all the DevOps headache?
Nice tool.
The distribution challenge here is wild — not the tech, but getting from "one customer has an agent"to "100 customers adopt it." How are you thinking about expansion? Land-and-expand per customer, vertical wedge where one industry unlocks the rest?
This is a massive pain point for developers building multi-tenant AI systems. The architecture looks clean, and managing custom VPS/containers
for each user manually is indeed a huge operational overhead. Congrats on the launch!
Thank you, really appreciate that! That's exactly the problem we kept running into. Managing isolated environments for customers can become a significant operational burden long before teams expect it. Glad the approach resonates, and thanks for the support.
This is very useful. I am also planning to launch new AI tool and it would be great help to me. I will dig how to use this in my tool.
Thank you, really appreciate that! Best of luck with your AI tool launch. If you're building customer-facing agents, hopefully this can save you some time on the infrastructure side and let you focus more on the product itself.
Wishing you a successful launch!
operating it reliably, 100%. building the agent is the fun part. the moment you have real users with real data, you're suddenly debugging edge cases at 2am that you never imagined. we had a similar thing building aisa.to — the conversational AI itself was the easy bit, making it score consistently across thousands of different users was a completely different problem. your infra play makes sense because most builders underestimate the ops side until they're drowning in it
Appreciate this, and that resonates a lot. The 2am edge case debugging is very real. Things that never show up in testing suddenly appear once you have real users, real data and thousands of different interactions flowing through the system. Consistency and reliability at scale end up being a completely different challenge from getting the AI working in the first place. That's exactly the gap we're trying to help teams avoid having to build from scratch.
The infrastructure-per-customer problem is genuinely underrated, most people don't hit it until they're already mid-scale and it becomes painful fast. What I find interesting here is the pricing model, $3.44/month per always-on agent is low enough that it doesn't become a blocker for the founder selling to their own customers. The isolated environment approach also solves a compliance and data separation headache that nobody talks about until a customer asks "where does my data live?" Curious how you're handling agent cold start times when an instance hasn't been active for a while, that's usually where the "persistent" promise gets tested.
Really appreciate this thoughtful breakdown. You're right that many of these challenges don't become visible until teams have enough users and agent instances for operational complexity to start compounding. Data isolation and customer-specific environments are also things that often seem secondary early on, but quickly become important once customers start asking deeper questions around reliability, security, and ownership of their data. On pricing, a big goal was to make the operational layer affordable enough that teams can focus on building their product rather than constantly worrying about infrastructure costs.
This hits close to home — we ran into the exact same isolation problem building ThirdOS (AI website manager for local businesses).
Our architecture ended up being kind of wild: we boot the agent environment from a VHDX image — either directly on the client's machine as a VM, or on an NVIDIA Jetson Nano sitting on their local network. The Nano approach is underrated for small business clients who don't want cloud latency touching their site edits.
The piece that made it all click: a reverse SSH tunnel proxy back to our central infrastructure. The client machine or Nano initiates the outbound connection — no open ports, no firewall drama, no IT guy required. The tunnel keeps the agent's state tethered back to home base even when the edge device is behind a random router.
On top of that we run what we call StateOS internally — a persistent environment layer that keeps the AI's memory, tool context, and session state alive across reboots. Context drift was wrecking us until we treated state as a first-class citizen living OUTSIDE the model context window.
We went per-client domain licensing instead of per-instance because local businesses want to feel like they OWN their AI, not rent a slice of one. Different GTM but same isolation philosophy as what you're building.
Curious — how are you handling state persistence across instance restarts? Is memory attached to the container or externalized?
Really appreciate you sharing this. The reverse SSH tunnel + StateOS approach is fascinating. We came to a similar conclusion that state needs to be treated as a first-class concern rather than living purely in the context window. Different GTM models, but very similar thinking around isolation and ownership. Always interesting to see how teams converge on the same challenges at scale.
One of my friends is a non-technical founder with customers waiting for their agent, but having issues building and shipping it in a way that works. Have you thought about packaging this for everyone to be able to create it from UI, and even be able to just prompt to create and edit their agent?
That's a really interesting direction, and something we've thought about quite a bit. Right now we're focused on making the infrastructure layer simple for developers and teams building AI products. But the idea of letting non-technical founders create, configure, and manage agents through a UI or even through prompting—is definitely compelling. We've seen the same pattern where the demand for AI agents often exists before the technical resources to build and operate them. Lowering that barrier could open up a much broader set of use cases. Really appreciate you bringing it up.
Good work
The per-customer isolation is the right call, but the failure mode I'd watch isn't the agent misbehaving — it's config drift between instances. I just lost hours to a bug where a local .env baked into a Docker image silently overrode my production secrets: same code, different environment, no error thrown, completely different behavior. Multiply that across N isolated customer environments and "works in instance A, silently wrong in instance B" becomes the scary one. Any guardrails planned for surfacing when an instance's effective config doesn't match what the dev expects?
ran into this building pm workflow agents. the infrastructure problem is real - you've abstracted the hard part. but what nobody talks about: when a customer's agent does something wrong, who explains it? one API call doesn't answer that.
That's a great point, and I completely agree. Making agent deployment a one-API-call experience doesn't remove the responsibility of understanding what the agent did and why. In many cases, explainability, observability and debugging become just as important as the agent itself. Our focus is on reducing the infrastructure burden but you're right that operational visibility is a critical part of making agents usable in production. An agent that can't be understood when something goes wrong is difficult to trust, no matter how easy it is to deploy.
yeah that's the part that bites you in production. had a case where the agent did exactly what I asked - but the intermediate steps were wrong in a way I only caught because I kept a trace. without that it would've just looked like a success.
“This resonates — we’ve been seeing the same pattern building AI agents: context drift after long sessions is the #1 silent failure mode. Curious how you’re handling token cost as conversations grow? We ended up building real-time compression for exactly this.”
This definitely resonates. Context drift is one of those issues that often stays hidden until agents have been running for a while with real users. It's easy to overlook during demos but it becomes a major reliability challenge over time. Real-time compression sounds interesting. We've found that long term memory management ends up being just as important as the model itself once conversations and agent histories start growing.
this is cool and really usefull
Thank you for the appreciation!
In the fantastic world of AI, more and more tools are emerging, making it increasingly difficult to stand out in this veritable red ocean. Any tool that saves TIME and MONEY will naturally stand out in the market, and this tool seems to be one that could achieve that goal, which is half the battle won. Congratulations and best of luck on your journey that has just begun.
Thank you for the thoughtful comment and encouragement. I completely agree that the space is becoming increasingly crowded, which makes it even more important to solve a real problem rather than just add another AI layer. Our goal is simple: help teams save time and avoid spending months building infrastructure that isn't core to their product. We're still early, but it's encouraging to see so many builders resonate with the operational challenges around running agents in production.
This is really cool, Vishnu! I'm actually building something very similar as a feature for my current job, so I completely understand the infrastructure challenges you're talking about here.
Thank you, really appreciate that! If you're building something similar, then you probably know firsthand how quickly the infrastructure side starts taking over. The agent is usually the easy part—it's everything around persistence, tooling, isolation, and reliability that gets interesting. Wishing you the best with your project as well. It's always great to hear from people tackling similar challenges.
This solves a problem i keep hearing from teams building AI products. Getting agent to work is one thing but managing persistent state, integration, isolation and reliability across real sustomers is a completely different challenge. I like that you are focusing on the operational layer rather than just agent itself.
Really appreciate that. That's exactly the pattern we kept seeing. Most teams can get an agent working but once real customers start using it, the operational challenges quickly become the bigger problem. State, integrations, isolation, reliability and all the edge cases around them tend to consume far more time than expected. That's why we decided to focus on the infrastructure layer and make those pieces easier to manage.
Great work!
Thank you, really appreciate it!
increibleee
Thank you! Really appreciate the support
Interesting idea. How are you handling costs for agents that stay persistent but aren't actively being used?
Great question. A big focus for us has been making persistent agents affordable enough that teams don't have to constantly think about spinning instances up and down. We optimize around keeping agents available while minimizing idle infrastructure overhead behind the scenes. The goal is that builders can treat an agent more like a long lived customer workspace rather than something that needs to be recreated every time a user comes back.
This is a strong direction — and you’re clearly describing a real shift from “agent building” to “agent operations.”
What stands out here is that you’re not competing on the model or the agent logic anymore. You’re abstracting the hardest part most teams underestimate: isolation, state, tool access, and lifecycle management per customer. That’s actually closer to “Render for agents” than an agent framework.
The positioning is strongest when framed less as “build agents easily” and more as “run agents in production without infra overhead.” Because most teams can prototype an agent in a weekend — but very few can reliably run 100+ stateful, tool-using agents with memory and integrations without building internal infra.
The real validation question for something like this won’t be “can it host agents,” but:
does it remove enough operational pain that teams stop stitching together their own container + queue + memory + tool stack?
On your main question — in practice, most teams hit the same wall you’re targeting: building the agent is the fun part, operating it is the product.
Really appreciate this breakdown.
The "agent building vs agent operations" distinction is exactly what led us to build this. We found that once teams moved beyond a prototype, most of the engineering effort shifted away from prompts and workflows and toward isolation, state management, tool reliability, and lifecycle management.
I also like the "Render for agents" comparison. Our goal is to let teams focus on the agent experience itself instead of assembling and maintaining the infrastructure stack around it.
And I agree with your validation point — hosting agents isn't the challenge. The real test is whether we can remove enough operational complexity that teams no longer feel the need to build and maintain that layer themselves.
This capture a real shift in the space. Building agents is straightforward compared to everything required to run them reliably in production with real users , state and integrations. Strong execution on a very real pain point.
Appreciate that. That shift is exactly what pushed us in this direction, prototypes feel deceptively simple, but production quickly becomes an infrastructure problem more than an AI problem. Most of the real complexity shows up around state, integrations, reliability, and all the edge cases that don’t appear in demos but matter a lot with real users. That’s the gap we’re trying to abstract away.
We ran into something similar, orchestration becomes the real product once you go beyond a few agents. I like the approach here of abstracting away infra complexity so builders can focus more on actual agent behaviour.
Yeah, this resonates a lot. Once you move past a handful of agents, orchestration stops being “supporting infrastructure” and effectively becomes the product itself coordination, state flow, retries, and tool interactions start defining the system more than the individual agents. That’s exactly the layer we’re trying to hide so builders can stay focused on agent behavior and outcomes rather than spending most of their time wiring everything together.
This hits very accurately. The agent itself is usually the easy part but once you go into production, keeping state, tools and integration reliable becomes a completely different problem. Most people underestimate that shift until they hit it.
Yeah, exactly that’s the part that doesn’t really show up in demos. Everything feels clean when it’s a single agent in isolation but once real users, state, and external tools come in, the system complexity grows way faster than the actual AI part. That shift tends to surprise people the first time they run into it at scale.
This is one of those ideas that looks simple on the surface but gets complex very quickly in practice. Once you scale even small issues like memory drift or tool instability start compounding. Solid direction tackling it at the infrastructure level.
Appreciate that. That's exactly what we kept seeing in practice. A single agent demo can look great, but once you have real users, persistent state, and multiple tool integrations, small issues start compounding very quickly. A big part of what we're trying to do is remove that operational burden so teams can spend more time improving the agent itself instead of constantly managing the infrastructure around it.
This comment was deleted 3 months ago