This series is about what it takes to move an AI agent from first working version to something a paying customer relies on every day. I built a managed AI agent on top of OpenClaw, the open-source agent runtime, and deployed it for real customers. The flagship deployment supported a procurement research consultancy that evaluates vendors, reviews contracts, and scores RFP responses for clients, with sustained daily use that made the platform work visible fast.
This piece covers what the deployment actually was and the product lessons it produced. The companion pieces cover the agent-safety controls, the OpenClaw stability war stories, and the unit economics and release-governance bill.
What the deployment was
The deployment ran on hardened agent hosts. Each company gets its own Azure VM and Tailscale tailnet, with isolated agent tenants underneath: each agent has its own Linux user, database, memory workspace, resource budget, and connected accounts. Access is managed through ACL roles such as operator, editor, admin, and super admin. The customer never sees any of that. What they see is a Telegram contact.
The procurement team used it the way you would use a sharp junior analyst with infinite patience. A typical request: "Compare the liability clauses across these five vendor contracts and tell me where we're exposed." The agent would read for an hour, documents from the mailbox, notes from its workspace, and come back with a structured comparison. Requests compounded over days: "Given everything we discussed this week about this vendor, what's our best counter-offer?"
The same agent could be personal, shared by a team, or available across an organization, depending on the access model around it. Account connections were self-serve from inside the chat: a /connect command produced a normal browser consent screen, and the OAuth tokens landed on the agent's host, readable by no one else, including us, as part two will detail. Capabilities shipped as a versioned, checksummed skills bundle, procurement skills like vendor evaluation matrices and contract redline prep alongside general knowledge-work tasks, pinned per release, so an agent's abilities changed only when we decided they should.
It worked. Sustained, multi-hour research sessions, day after day, at a token cost that part three unpacks. The interesting part is not that an LLM can summarize contracts. It is what holds up, and what surprises you, when an agent becomes a coworker someone is quietly relying on.
Five things production taught us
1 Meet people in the channel they already live in
The assistant lived in Telegram, because that is where the team already coordinated their work. Adoption was never a project; it was a contact card. Every piece of product surface we considered adding, connecting a Google account, checking status, tuning behavior, we made available through the chat channel, and the product was better for it. An agent you have to go visit is a tool; an agent in your messages is a colleague.
2 Memory is the product
The single feature the team valued most was not a skill or an integration. It was that the agent remembered. "Given everything we discussed this week about this vendor, what is our best counter-offer?" only works when workspace memory persists across sessions and days, without the user rebuilding context every morning. Most of what felt like intelligence to the customer was actually continuity.
3 Real teams want a shared assistant, not seats
A tenant was an agent, not a company. An agent could be assigned to one person, shared by a team, or opened to a whole org through ACL roles, while its memory stayed scoped to that agent. The per-seat consumer model, one human, one assistant, one context, is an artifact of how chat products are priced, not how teams operate.
4 A cheap model with good scaffolding beats an expensive model alone
The workload was sustained reading, comparison, and structured summarization: contracts, RFP responses, vendor documents. A cost-efficient model, routed per agent, kept token costs to a fraction of what a frontier model would have charged, without changing the outcome the customer saw. The scaffolding around the model, memory, skills, prompts, retries, did more work than the extra model capability would have.
5 The platform is most of the work
The production platform dominated the engineering effort around the agent. OpenClaw provided the runtime, but tenant isolation, OAuth credential plumbing, version pinning, monitoring, watchdogs, backup and restore, and release discipline are what kept the deployment usable in production.
The two hard problems underneath
Everything above is the visible product. Underneath it sat the two problems that consumed most of the engineering effort, and that anyone deploying agents for real customers will meet:
Trust. An agent with mail, calendar, and file access is a security product before it is a productivity product. Inbound email has to be treated as data, not instructions, because the agent reads messages from strangers all day. The agent-safety field notes walk through the posture we built: runtime identity separation, seven layers of isolation, an OAuth broker that cryptographically cannot read the tokens it carries, privacy controls with known limits, egress audit posture, and prompts the agent cannot edit.
Ground truth instability. I pushed back hard on OpenClaw at first, then saw at HumanX 2026 how many companies were shipping production agents on it, and decided to try. The runtime surface was real: channels, tools, skills, cron, sessions. But it ships date-versioned feature trains with no patch releases, and defaults can move between releases. A routine upgrade can change what your customer sees in chat. We ended up building KissClaw, a stability fork with SemVer governance, to make the ground hold still. The OpenClaw stability war stories cover the upgrade spiral, restart-message leaks, and tool-progress leak that made release governance non-optional.
Deploying agents for real users?
The work that keeps an agent useful in production is architecture: isolation, credentials, cost tracking, and release governance. I help teams build that architecture with the lessons already learned.
Stay Updated
Subscribe for frameworks and engagement briefs on production AI, agents, and governed autonomy.