360Películas, my online store for pre-cut car window tint, gets questions on WhatsApp, by email and on Instagram. For months, customer support rested on an AI agent wired straight into WhatsApp and a handful of ad hoc tools. At today's volume, that stopped being enough.
This autumn I started building something else, in three pieces: a new back office in the store's application, Chatwoot as the single inbox, and an agent platform, Rakazo, for the background work. It is still in progress. This post covers what changed, the rules I put around the agents, what it cost and what I learned along the way.
Before: a good agent with no inbox
The store's WhatsApp agent went through several models, first Grok and then other providers, and it answered well about what it knew: prices, order status, tracking. The trouble was not the answers it gave. It was everything around them.
- Forgotten conversations. When a conversation needed a person, it could sit for several days without a reply. There was no organised inbox and no way to see at a glance who was waiting, and for how long.
- No clear owner. Tickets existed, but only for WhatsApp and only after the agent handed a conversation over. Nobody was clearly on duty to watch them, and there was no view of how long each customer had been waiting. When everyone can reply, often nobody does.
- Scattered channels. Email and Instagram lived elsewhere, each with its own history. The same customer could write on all three and nobody put the pieces together.
- Tone and facts. Some automatic messages addressed customers with the informal Portuguese «tu», which is not the store's tone. And the agent sometimes got things wrong, such as saying we only sold full kits, when the rear windshield is sold on its own from 89 €.
None of this is fixed by a better model. It is an organisation problem, and the organisation had to exist before putting more AI on top.
Three pieces, one job each
The store's application holds the data and makes the decisions. Chatwoot is where the conversations live. Rakazo's agents do the background work, and they only reach the store through the application, never the database directly.
The back office: where the facts live
In another post I described how orders left Notion and Filament gave way to a custom back office. That was the foundation for everything else: an agent can only answer well about an order if the order lives somewhere with rules. Since then the back office has gained what customer support needs.
- Orders, tracking and the supplier balance, now with supplier credits recorded as entries of their own.
- Refunds and proposals. An action that touches money or an order can start as a proposal and is only carried out once approved.
- A communications log. Every email, message and notification sent to a customer, in one place.
- History with before and after. Every change to an order keeps the old value and the new one, such as "Status: Shipped → Delivered", and who made it.
- Returned orders, with a status of their own, "Devolvida" (returned), instead of a note lost in a comment.
- A page for tracking problems, to see in one place the orders whose shipment needs attention.
- Notifications on hold. Automatic notifications are held for 30 minutes before they go out, so they can be reviewed. I explain why further down.
Chatwoot: a single inbox
Chatwoot is an open-source customer support platform. I host it on my own server, and it is now the single inbox for WhatsApp, email and Instagram. WhatsApp reaches it through a bridge from the WhatsApp API the store already used, WhatsMiau. Every conversation has a status, an owner and a priority, and anyone on the team can see at a glance what is waiting for a reply.
Chatwoot is the interface. The brain is still the store's application: Chatwoot hands every new message to an Agent Bot, which is the application itself, and the application decides what to do.
- Tools, not memory. To answer, the bot looks up the order status, tracking, the catalogue and prices, and the knowledge base.
- Handover with a note. When it passes a conversation to a person, it leaves a private note with what it has already found out, so whoever picks it up does not have to read everything from the start.
- Quiet hours. Anything written to a customer at night waits until 09:00.
- Automatic priority. The bot's classification of the conversation sets its priority. It only ever raises it, never lowers it, and stops touching it as soon as a person changes it.
- One customer, several channels. The same customer on WhatsApp, email and Instagram is linked to a single contact, with the history together.
"@bot" notes
This is the piece I like most. In a private note, which the customer never sees, the team can give the bot an instruction. A real example:
@Bot 360p vai buscar a fatura do fornecedor e manda para a ups diretamenteIn Portuguese, that reads "fetch the supplier invoice and send it straight to UPS". The bot fetches the supplier's invoice from our system, emails it to the carrier in a separate conversation the customer never sees, and tells the customer only that it is being handled. One sentence in a note replaces downloading a document, writing an email and coming back to the conversation to update the customer.
Rakazo: agents for the background work
Rakazo is an open-source agent platform by elie222, which I also host on my own server. Each agent has instructions, tools, routines and, when it needs one, a computer with a browser. Today there are three kinds:
- The "CEO". It runs support and operations three times a day: it sweeps the conversations, proposes refunds, replacements and replies for approval, and follows up on whatever is pending.
- Ops Fornecedor (supplier ops). It talks to the supplier through a browser, the way a person would.
- Support agents per channel, for email, Instagram and WhatsApp.
An MCP server instead of a robot clicking around
Moving the agents onto my own server made me think about efficiency. The obvious route was a "master bot" clicking around the back office in a browser, the way a person would. It works, but it is slow and expensive: every screen it reads costs tokens and time, and everything depends on the screen not changing.
Instead, I built an MCP server tailored to the system. The agents talk to the store's application directly, through tools with a limited scope, guards and an audit log. It is faster, cheaper and safer. The browser is kept for where there is no alternative, such as talking to the supplier.
The MCP server is reserved for staff, with one token per agent and access limited to what each one needs. The tools are few and generic:
- Reading orders, conversations and tracking, and searching the knowledge base.
- Proposing a change. Nothing happens without approval. When I approve, the action runs: the reply goes to the customer or the replacement is created.
- Sending a support message, with guards on the server: it respects quiet hours, it does not talk about money unless a refund has actually been carried out in the back office, it never uses the informal «tu», and it sends no more than three messages per customer per day.
There is a practical reason for keeping them few: Rakazo only shows up to 20 tools per server directly. It looked like a limitation and turned out to be good design. Instead of one tool per case, there is a small set that covers almost everything, and the important rules live on the server, not in each agent's instructions.
The guards
Agents with access to customers and money need limits that do not depend on what the instructions say.
- Approval before money moves. Refunds and replacements are proposals. A person approves them.
- Everything audited. Every action an agent takes is recorded: who, what and when.
- Capped costs. Once, a browser run got out of hand and cost about 48 dollars. Now routines run three times a day, an alert fires above 4 dollars a day or 1 dollar per run, and each agent has a maximum number of screen actions per run.
- Brakes. Safety holds, and switches that turn off each automation without touching the code.
- Notifications on hold. A re-check of old shipments sent customers "shipment update" emails about orders that had nothing new. Since then, every automatic notification waits 30 minutes, on a page where the team can review it before it goes out.
- Personal data kept out of instructions. No customer data goes into the agents' instructions, and audit logs are stored with personal data redacted.
What it cost: AI did not solve everything
It would be easy to tell this as if AI had done the work. It did not. Mostly, it sped up writing the code. The reason I am still talking about it is that there is always something to adjust, and only hours of work get you through most of the real cases and make everything truly ready for production.
- Time. I picked two calm days and went all in. That was the start, not the end: the tuning goes on.
- AI usage. Getting everything to work well came at a large cost in AI, both for coding and in the agents themselves.
- Patches to applications that already work. Chatwoot is good, but it was not born for my system. It needed a custom Docker image to fit the store and WhatsMiau, the WhatsApp bridge.
- One more machine. I set up a new VPS just to host this: Chatwoot, Rakazo and the agents. It is one more server to maintain and update.
For me it was worth it, because the underlying problem was real. But it is best to go in knowing that AI shortens the road, it does not remove it.
What I learned
- Organisation before intelligence. The forgotten conversations were not the model's fault. They came from having no inbox, no clear owner and no view of waiting times.
- Instructions guide, the server guarantees. No informal «tu», no money talk without a refund, no messages in the middle of the night: all of this is in the tool's code, not only in the prompt.
- Approving is faster than writing. My job moved from drafting replies to reading proposals and pressing approve, or correcting them.
- A bot has to know when to stop. It hands over with a note, lets go of the priority once a person changes it, and has a daily message limit.
- A few generic tools age better than many specific ones.
- Agents in a browser spend money in unpredictable ways. Cost limits have to exist before the first routine, not after the first bill.
Where it stands
It is too early for numbers, and I will not make them up. What is already clear: no conversation is forgotten for days, there is one inbox for the three channels, I approve instead of typing everything, and the bots know when to stop.
Since then, this is done too:
- A store panel inside Chatwoot. With Chatwoot's Dashboard Apps, the order, the shipment and the scheduled messages show up next to the conversation, without switching tabs.
- OAuth on the MCP server. The same server connects as a connector in ChatGPT and Claude, with the same tools and the same guards.
The rest is fine-tuning: every new case that shows up becomes one more rule or one more guard.
If your business's customer support is spread across WhatsApp, email and social media, and you want to bring it together with automation that knows when to stop, you can get in touch.