From OpenClaw to Hermes: when an insurance agency outgrows its AI assistant

The starting point: an OpenClaw assistant that did its job

Let's be honest first: OpenClaw was not a mistake.

For months, the assistant was useful exactly as intended. The owner wrote to it on WhatsApp like to a colleague. A morning brief with the day's meetings and hot topics. A question about a policy while on the road. A draft reply for an unhappy client. A summary of a long email thread before calling a policyholder back.

The assistant knew his context. His writing style, his priorities, his branches, his habits. That is the whole idea of OpenClaw: a personal copilot that lives in your messaging apps, keeps the memory of your exchanges and prepares work on demand.

For an owner who spends his days between five branches, an insurance company and clients, that copilot has real value. It avoids reopening ten tabs to rebuild context. It saves time on writing. It helps him decide faster.

So the problem was not what the assistant did. The problem was what it could not do, by design.

Why an AI assistant stops improving

An AI assistant plateaus because all of its value flows through the requests you make. Once it knows its user, there is not much left for it to learn, and nobody hands it the work they never think to ask about. The remark "it has stopped getting better" describes a precise phenomenon, not a vague impression.

In practice, an assistant improves fast in the first weeks. It learns your preferences, your tone, your shortcuts. Every conversation makes it more relevant. Then the curve flattens.

And this is where many business owners get the diagnosis wrong. They think the tool has reached its technical limits. In reality, the tool has reached the limits of its role.

An assistant works when you ask. All of its value flows through the person asking the question. If the owner does not think to ask, nothing happens. If a branch employee does not know how to phrase the request, nothing happens either. The assistant amplifies the person using it, but it does not improve how the business runs.

Concretely: every week, the owner asked for the same kinds of drafts, the same summaries, the same checks. The assistant produced them very well. But nobody was asking the assistant to handle the certificate requests landing in the branches' inboxes, to chase missing documents on a claim file, or to prepare the month's policy renewals. That was not its role, and not how we had scoped it.

The improvement this owner was waiting for could not come from a smarter assistant. It had to come from a system that takes ownership of processes, without waiting for a human to ask.

Five branches, one assistant: hitting the scalability wall

A personal assistant cannot carry the load of a multi-branch agency, because it is connected neither to the channels where client requests arrive, nor to the teams who handle them. That is the second limit this owner ran into, and it is even more concrete than the first.

In an independent insurance agency, inbound requests are massive and repetitive. Insurance certificates for a landlord, a school or an employer. Claim declarations. Quote requests for car, home or health coverage. Vehicle changes, address changes, added drivers. Questions about a renewal date or a debit. Cancellation requests. Claim history statements.

Multiply that by five branches and you get a permanent flow arriving by email, by phone and at the front desk, handled by teams for whom it is only part of the job.

Facing that flow, the owner's assistant could do nothing, for a simple reason: it was the owner's assistant. A personal copilot, plugged into his own conversations. Client requests never reached its channels. Branch teams had neither the habit nor the framework to go through it.

We could have opened the assistant up to the teams. We considered it. But we would have hit questions that go beyond a copilot: who is allowed to see what across branches, how to guarantee consistent replies from one branch to another, how to keep a record of what was sent to a client, how to handle fifty simultaneous requests when the assistant works one conversation at a time.

In insurance, these questions are not a comfort feature. The duty to advise requires keeping a record of what you tell a client. An approximate answer about coverage can create liability for the agency. A document sent to the wrong recipient is a GDPR incident. That level of requirement cannot be managed inside a WhatsApp thread.

The need had changed in nature: it was no longer about helping one owner work better, but about running request handling at the scale of five branches. That is exactly the boundary between an assistant and an agent.

AI assistant or AI agent: what is the difference?

The difference fits in two sentences. An AI assistant works when a person asks, and its value depends on the questions it receives. An AI agent is triggered by the workflow itself, and its value depends on the business rules it has been given.

Let's unpack that. An AI assistant answers when you ask. It helps the person talking to it: research, writing, summaries, preparation. Its value depends on the quality of the requests it receives. OpenClaw belongs to this family: a multi-channel copilot with memory, serving one person or a small team.

An AI agent takes ownership of a process. It is triggered by the flow itself: an incoming email, a submitted form, an approaching deadline. It reads the context, applies business rules, executes what is well-framed and routes what is sensitive to a human. Hermes belongs to this family: an agent connected to the agency's tools, working whether anyone is watching or not.

Here is the grid I use with business owners to locate their need:

This distinction is not academic. It determines the budget, the scoping, the guardrails and the return on investment. Many SMEs buy an "AI agent" when what they need is an assistant. This agency had the opposite problem: it was using an assistant where an agent was needed.

What the migration to Hermes actually changed

The migration did not start with technology. It started with a week of work on the agency's real protocol.

For each type of inbound request, we had to write down what actually happened: who handles certificates, which checks come before sending a claim history statement, which documents to request depending on the claim type, which requests require a conversation with the client, what varies from one branch to another and what must never vary.

This work looks a lot like what I described in my field story about the Hermes agent of a multi-property Airbnb host: the core of the project is not the AI model, it is turning what the business already knows into rules a system can read.

An interesting detail: the months spent with OpenClaw were not wasted, quite the opposite. The history of the owner's requests to his assistant was an X-ray of what the agency was missing. The drafts he asked for most often became Hermes' first reply templates. The memory the assistant had accumulated fed the scoping work. Without anyone planning it, the assistant had played the role of a process revealer.

Once the protocol was in place, Hermes was connected to the agency's channels, not the owner's: the five branches' inboxes, the calendar, and the business tools used for policies and claims. It is the same principle of workflow automation as in my other projects: the AI understands the request and picks the action, the workflow executes it cleanly in the tools.

Today, when a request reaches a branch, Hermes identifies it: client or prospect, request type, policy concerned, branch, urgency. It gathers context from the authorized tools. Then it classifies the request into three levels.

Level one, it handles alone: a personalized acknowledgment, a request for missing documents with the exact list for that file type, answers to questions that are fully framed and carry no commitment.

Level two, it prepares and a human approves: a draft reply to a claim declaration, a pre-filled quote file for the advisor, a follow-up to a client whose file has been incomplete for several days.

Level three, it escalates without acting: a complaint, a cancellation request, anything touching the duty to advise, an inconsistency in a file, a visibly unhappy client. In those cases, Hermes gathers the facts and hands the file to the right person, with the context already prepared.

I apply this three-level separation on every agent project. I explained why in my guide on human approval for AI agents in production: in a regulated sector, an agent without readable guardrails is a risk, not progress.

What the owner sees, on his side

For the owner, the most visible change is not in the branches. It is in how he runs the business.

Every evening, he receives a summary per branch: requests handled, those waiting for approval, files that are dragging, cases escalated and why. Where his assistant used to answer when he asked a question, the agent shows him what he would not have thought to ask.

This is the point that answers his original remark. Hermes improves over time, not because the model learns on its own, but because every escalated case is an opportunity to refine a rule. A misclassified request becomes a corrected classification rule. A reply approved with edits becomes a better template. After a few weeks, the share of requests handled or prepared correctly on the first pass goes up, and it shows in the evening summary.

An assistant plateaus once it knows you. An agent keeps improving as long as you refine its rules. That is the whole difference in trajectory.

And what about OpenClaw? The owner still uses it. His morning brief, his personal drafts, his research, his summaries before an important meeting. The two systems coexist very well, because they do not do the same job: the assistant helps him, the agent runs the request handling. The migration did not replace one tool with another. It put each tool in its right place.

Five signs you need an AI agent rather than an assistant

If you already use an AI assistant in your SME, five signals indicate you have reached the same boundary as this agency.

You ask your assistant the same things every week. If your requests have become repetitive and predictable, the need is a process, not a conversation.

The value depends on who asks. If the AI is very useful to you but barely used by your teams, the problem is not adoption. It is that the tool is a personal copilot, not a team system.

Inbound volume grows faster than your capacity to handle it. An assistant does not absorb a flow: it helps whoever handles it. If the flow overwhelms you, you need a system triggered by the flow itself.

You need traceability. As soon as a reply to a client can create liability, a conversation history is not enough. You need an action log: what was read, prepared, sent, approved, refused.

You cannot say what the AI did for the company this month. With an assistant, that question is almost unanswerable, because its value is diluted in everyone's work. With an agent, it can be read in the counters: requests handled, files prepared, cases escalated.

None of these signals means your assistant was a bad choice. In this specific case, starting with OpenClaw was even the right decision: controlled cost, fast rollout, and months of real usage that served as the specification for the agent. The trap is rather to stay stuck at the assistant stage waiting for it to turn into an agent by itself. That will not happen, whatever the quality of the model.

Where to start if this sounds like you

The good news is that the transition is not an overhaul. It happens flow by flow.

I recommend starting with a single process, chosen with three criteria: it comes back every week, it forces you to cross-check several pieces of information, and it costs real money when it is mishandled or forgotten. In this agency, it was the handling of inbound email requests. In another SME, it will be quotes, follow-ups or tracking incomplete files.

Then write down the real rules of that process, with the teams who run it today. Not a perfect rulebook: just enough structure for the agent to know what to do in the common cases and what to escalate in the others.

Then test on real cases, starting with low autonomy: the agent prepares everything, humans approve everything. Autonomy then widens, rule by rule, where the agent has proven reliable.

If you first want to clarify what your company needs, assistant or agent, that is exactly the kind of question we settle in a few sessions of an AI consulting engagement. And if you are starting from scratch, without an existing assistant, the AI agents page describes how I scope these projects.

Conclusion

This insurance agency did not change tools because the first one was disappointing. It changed tools because its usage had outgrown what an assistant can do.

An AI assistant helps one person work better. An AI agent moves a process forward for a whole team. The first plateaus once it knows you. The second keeps improving as long as you refine its rules on real cases. Between the two, there is no software upgrade, but real scoping work: writing the rules, choosing the autonomy levels, setting the guardrails.

If your AI assistant gives you that feeling of a ceiling, or if inbound requests are overwhelming your teams, the OpenClaw and Hermes pages describe both systems and where each one belongs. And if you are hesitating between the two, that is probably the best question to ask me.