“We wanted to deploy agents for our users, and we want someone else to manage those agents on our behalf. We don't want to get into this DevOps business. When I saw your platform I thought, you are solving the right problem. Let's do a partnership.”
The problem
Perflo is a bank account an AI agent can actually use. A real account, a virtual card with its own balance, limits the owner sets, and withdrawals only the owner can make. Yeshu Agarwal built it across roughly 30 local banking partners, so a customer gets an account issued where they live.
What he did not have was a way to hand a customer an agent. Onboarding was an Add to Claude button, an Add to ChatGPT button and an MCP install, and their own customer interviews had already told them how that goes.
“Many people are not having even Claude accounts. Many people are not even having a Claude subscription. MCP doesn’t work seamlessly here.”
The launch was two weeks out. They needed something a non-technical customer could just use.
Why they didn’t build it
Perflo is seven people. Two of them are engineers, and both were busy with the banking partners, the licenses and the compliance, which is the part only Perflo can do.
“We don’t want to get into this DevOps business.”
Running an agent for every customer is not a one-time build. It is provisioning, isolation, restarts, credentials scoped to one customer, and someone on call. Hiring for it would have cost them the launch.
The security question came first
Perflo’s agents move money, so Yeshu opened with security rather than features.
Every agent is private by default: no public address, no inbound shell, and nothing reaches it except through an authenticated edge on the ports Perflo names. Outbound it can reach the public internet and nothing else on our side, not the machine it runs on and not another customer’s agent.
Their model key never goes near a container either. Each agent gets its own scoped credential and model traffic routes back through Perflo’s proxy, so the key stays on their servers and they see every call they pay for.
What they run now
A customer signs up with Perflo’s own login, Perflo’s backend makes one API call, and that customer has an agent that stays on. The first one was running two days after our first call.
It runs Perflo’s image, not ours, with their CLI baked in and nothing in it carrying anyone else’s name. They publish a new version whenever they want and the fleet moves onto it.
The chat, the files, the schedules and the spending panel are all Perflo’s. They took the API and built their own product on it, and never asked us for a UI.
Always on matters for what they sell. Buy gold every morning at nine needs an agent that is awake at nine.
The parts they did not build
Customers reach their agent from iMessage, WhatsApp, Telegram, Slack or Discord, in an app they already have open. iMessage took an afternoon.
Gmail, Calendar, Notion and roughly a thousand others connect from Perflo’s own dashboard with one click, so a customer can tell their agent to read an invoice out of their inbox and pay it. Perflo wrote none of those connectors.
The outcome
- They launched on time: First agent running two days after our first call, with no hire and no infrastructure work.
- One always-on agent per customer: Every one of their customers gets an agent that remembers them, with its own files, history, credentials and spending limits.
- Channels and apps they never built: iMessage, WhatsApp, Telegram, Slack and Discord, plus roughly a thousand apps their customers connect with one click.
Perflo kept the banking. We took the fleet.
See how white-label works