WhatsApp AI Agent
Recovery: n8n OpenAI

A customer messages a Brazilian business on WhatsApp asking about a product, the way thousands had before, and then waits. Nothing comes back. The message reaches the system, moves through the usual steps, and stops dead at the point where a reply should be written. No error appears anywhere. The workflow that runs the whole thing cannot even be switched on. For a sales team that had come to rely on an agent answering every enquiry, the quiet was costly and invisible at the same time.

WhatsApp AI Agent Recovery is the project where we found why that agent went silent and brought it back. The setup is a chain of parts: messages arrive through Evolution API, an n8n workflow looks up the contact and buffers what they send, an OpenAI-powered agent writes the reply, and the answer goes back out to WhatsApp, with a hand-off to a person when the conversation needs one. Something in that chain had broken, and because it failed without an error, nobody could point to the cause.

Put simply, the same agent that had stopped answering was traced fault by fault, fixed with a backup before every change, tested with a real message end to end, and then hardened so the main failure cannot happen again. The client did not want a rebuild. They wanted their own agent working, and that is what they got back.

The Starting Point: A Silent Agent With No Error to Chase

The brief was narrow and the risk was high. A live sales channel was down, several services sat between the customer and the reply, and any clumsy change could lose contacts or chats for good. That set a short list of conditions the work had to meet before a single setting was touched.

• Restore, do not replace. The client wanted the existing agent fixed, not a new one built, so every change had to respect the workflow they already ran.
• Work across many moving parts. WhatsApp, Evolution API, n8n, OpenAI, Supabase and Redis all had to line up, and a fault in any one of them could break the whole reply.
• Back up before touching anything. Configs, both databases, workflows and credentials needed a full backup first, so nothing was lost while the causes were still unknown.
• Find root causes, not quick patches. Several faults had built up unnoticed over months, so each one had to be traced to where it started rather than papered over.
• Survive the next upgrade. An automatic container upgrade had already wiped part of the setup once, so the fix had to hold through the next one.
• Prove it with a real message. The job was only done when a message sent from a real phone came back answered, with the quote link opening correctly.

The Build: Tracing a Broken Chain Back to Working

Recovering a dead automation across six services, without an error to follow, is the kind of work an artificial intelligence development company takes on when a client has an agent they trust and need back rather than a fresh project. The faults were separated one by one, each checked against the logs before anything was changed. The work ran as an ordered sequence:

1. A full backup of the configs, both databases, the workflows and the credentials, taken before any setting was altered.
2. Server fixes: the n8n interface language was switched so its nodes loaded again, persistent storage was added and the version pinned, the missing Evolution API webhook was configured, lost node settings were rebuilt in the main agent and the human-handover flow, and the step saving contacts to a deleted Supabase project was pointed back at the live one.
3. A plain-language report for the owner, covering the billing and WhatsApp steps that only he could action.
4. Reconnection: the old client version that WhatsApp was rejecting was corrected, the session was re-paired, and Evolution API was upgraded after a rehearsal on a copy of its database.
5. A live test, in which a message from a personal phone was answered end to end, after which a duplicate agent run for new contacts and a doubled link in replies were fixed.

The likeliest reason the agent had gone quiet without complaint was the one that is easy to miss: the OpenAI account had run out of credits, so the model step produced nothing at all. Getting the replies flowing again meant treating the model layer with the same care as the rest, which is why the same discipline we bring to building OpenAI-powered apps applied here, from the billing that keeps answers coming to the way split replies and quote links are formatted.

Technical Architecture

The agent runs as a Docker setup on the client’s own Linux VPS, with each service doing one job and feeding the next. The hard part was never writing new code. It was reading a system that had failed quietly, confirming each cause with evidence, and fixing it in a way that would not come apart at the next automatic update.

• Orchestration. n8n in Docker runs the workflow that filters messages, buffers them, looks up the contact, calls the agent, splits the reply, and hands over to a person.
• WhatsApp gateway. Evolution API holds the WhatsApp session, receives messages through its webhook, and sends the replies back out.
• The model. OpenAI writes the agent’s answers, and its account balance has to stay funded for any reply to appear.
• Data and memory. Supabase stores contacts and conversation data, while Redis buffers messages that arrive in a quick burst so they are handled as one.
• Hosting and safeguards. The client’s own VPS runs it all, now with persistent storage for the community nodes and a pinned n8n version so an upgrade cannot wipe them again.

The piece that needed the most care was the join between a received message and a written reply, because that is exactly where the silence lived. A message could pass every visible step and still produce nothing if the model had no credit or the WhatsApp session had been logged out, and neither of those shows up as a workflow error. Checking each service in turn, rather than trusting the lack of red flags, is what surfaced the real causes.

Challenges Solved

The hardest problem was a failure with no error. The agent did its visible work and then produced nothing at the model step, so there was no single log line to chase. Walking through each service by hand surfaced the two causes outside the server: an empty OpenAI balance and a WhatsApp session that had been logged out months earlier. Re-pairing then failed because WhatsApp rejected the old client version Evolution API was reporting, which had to be corrected before the session would connect.

The second hard problem was a fix that kept undoing itself. The WhatsApp community node vanished every time the containers were recreated, because they had no permanent storage. Adding that storage and pinning the n8n version stopped it, and a container was recreated on purpose to prove the node now survives. The Evolution API upgrade carried its own risk, so it was rehearsed on a copy of the database first, which kept instances, chats and contacts intact and the WhatsApp connection live when the real upgrade ran.

The Result

In the final live test, a message sent from a personal phone was answered by the agent through WhatsApp, and the quote link opened correctly. The client confirmed it was working and released the remaining milestone, with a support period and step-by-step notes for future phone changes. The same agent now answers again, every customer message gets a reply, and the main failure is blocked by permanent storage and a pinned version rather than left to chance.

The recovery worked because it was built on evidence and backups rather than guesswork, fixing each cause where it started. If an automation you depend on has gone quiet, you can hire AI agent developers who diagnose n8n and WhatsApp pipelines fault by fault, or tell us how your agent is set up and our US-registered team will trace it end to end. It suits any sales and customer-facing business running an AI agent on WhatsApp.

Frequently Asked Questions

What was wrong with the WhatsApp AI agent?

Several separate faults had built up over months and then combined into a silent failure. n8n could not load its nodes, the WhatsApp community node had been wiped by an automatic upgrade, the Evolution API webhook was missing, a step pointed at a deleted Supabase project, the OpenAI account had run out of credits, and the WhatsApp session had been logged out. Each one was traced and fixed in turn.

Why did the agent fail without showing any error?

The agent completed its visible steps and only produced nothing at the model step, where an empty OpenAI balance and a dead WhatsApp session leave no workflow error. Because the system looked fine on the surface, the causes only appeared once each service was checked by hand against its logs and status rather than trusting the lack of red flags.

Did you rebuild the agent from scratch?

No. The client wanted their existing agent restored, not replaced, so the work stayed inside the workflow they already ran. Every change was made after a full backup of configs, both databases, workflows and credentials, and each fault was repaired where it started rather than worked around.

How is the same failure prevented from happening again?

The community nodes were given permanent storage and the n8n version was pinned, so an automatic container upgrade can no longer wipe them. A container was recreated on purpose to confirm the node now survives, and the Evolution API upgrade was rehearsed on a copy of its database before being applied to the live system.

Can you recover an agent built on a stack like this?

Yes. This agent ran on n8n, Evolution API, OpenAI, Supabase and Redis in Docker on a Linux VPS, and the same evidence-first approach applies to similar pipelines. The method is backup first, trace each cause with logs and tests, fix at the source, then prove it with a real message answered end to end.