Meta added a native AI agent to WhatsApp Business, and that changed the question many companies had been asking. It is no longer "is automating WhatsApp worth it?", but a more uncomfortable one: if the platform already ships an agent, when does building your own make sense?
This post is a decision guide, not a sales argument. If you finish it concluding that the native agent is enough for you, we will have done our job.
The dividing line: where does the answer live?
Every business conversation on WhatsApp can be sorted with a single question: does the answer already exist written down somewhere, or does someone have to go fetch it from a system?
"What are your opening hours?" already exists in writing. It sits in the business profile.
"How much do I owe?" is written nowhere. It lives in an accounts receivable table, it changes when a payment lands, and it is different for every person who asks.
That is the line. On one side, conversations resolved with published information. On the other, conversations that require checking the real state of the operation at the moment someone asks.
The four-question test
This helps you place yourself without calling anyone. Answer all four about the conversations your company receives on WhatsApp in a normal week:
- Are most of them answered with catalog, hours and business details? The native agent is enough for you.
- Does a meaningful share require looking at that person's balance, order or history? You are at the data query step.
- Does what gets discussed end up transcribed by hand into a system? You are at the write step.
- Are there processes involving your own systems or third-party services? You are at the API step.
If you answered yes only to the first, you do not need to buy anything. That is a valid outcome and worth knowing before sitting through a demo. The rest of this post is for those who answered yes from the second onward.
What the native agent solves, and where it stops
According to Meta's announcement, the agent answers questions about the business, recommends products from the catalog, books appointments, qualifies leads and hands the conversation to a person when needed. Its knowledge comes from chat history, the business profile and the catalog. It activates in minutes, with no implementation project.
For a huge share of businesses, that is all they needed: a restaurant answering hours and menu, a shop showing catalog products, a clinic booking appointments.
Where it stops is at your systems. Sources agree: the native agent neither reads nor writes to your ERP or your internal database, and external integrations are not available at the self-serve tier. Meta is building a platform for larger enterprises to connect systems like Shopify, Zendesk and Shopee, but according to TechCrunch that rollout is limited.
Those names deserve a pause: they are e-commerce and help desk platforms. None of them is the system where a mid-sized or large company in the region keeps its receivables, its invoicing and its inventory. That system is usually an ERP — off-the-shelf or custom-built — running on-premise or on a private server. No vendor's connector reaches there by default.
Step 1 — Querying a database
This appears when the answer depends on who is asking. A customer writes "what is my balance?" and the agent has to identify them by their number, find their account, add up outstanding invoices, subtract applied payments and return a correct figure. None of that lives in a catalog.
The typical cases repeat across almost every mid-sized company: account statement and overdue balance, order or shipment status, customer purchase history, real inventory availability — not the published catalog's.
Technically this is the most accessible step. The agent connects with a read-only user and queries views built over the critical tables. The risk is low: in read mode, the worst possible error is a wrong answer that gets caught and corrected. Nothing breaks.
Step 2 — Running a process in the ERP
Different in nature, not in difficulty. Here the agent stops reporting and starts producing effects.
A customer replies "I will pay you on Friday". If the agent only reports, that promise gets lost in the thread and somebody transcribes it by hand. If the agent writes, it is recorded with date and amount, and triggers the follow-up. The same applies to creating an order out of a sales conversation, updating contact details the customer corrects in the chat, or logging an interaction so the team knows what was discussed without reading the full thread.
This step demands more care, and it is worth being blunt about why: an agent that writes to the ERP can write badly. That is why the sensible order is reads first, writes second, with scope narrowed to specific, auditable operations.
The question that settles the decision is operational rather than technical: how much manual transcription work does WhatsApp generate today? If the answer is "one person spends several hours a week on it", the step pays for itself.
Step 3 — Talking to an API
This shows up when the data or the action does not live in a database you can reach directly. It happens with cloud ERPs that expose a REST API and block access to their database. It happens when the process involves an external service: checking shipment status with the logistics operator, validating information against a system your company uses but does not own.
It appears internally too. Many mid-sized and large companies have their own systems — a customer portal, a dispatch module, a tool the IT team built years ago — exposing internal endpoints.
The choice between database and API is rarely a preference: the system imposes it. If the ERP allows database access, that path is more direct. If it only exposes an API, you go through the API. If there are several systems and more agents are planned, it pays to build an intermediate layer with the MCP protocol and do the integration once. The detail lives in how to connect your ERP with WhatsApp.
Why this separates companies by size
It is not a matter of revenue but of structure, even though the two usually travel together.
A small business keeps its information concentrated in few places, often in the heads of one or two people. Its conversations are answered with what is published, and adding an integration layer gives it complexity without solving a problem it has.
A mid-sized or large company has the opposite: information is spread across an ERP, some in-house database and third-party systems, and no single person holds all of it. When a customer asks about their balance, answering requires entering a system. That is the work a connected agent removes.
There is a second difference, less visible and more decisive: in a company with volume, every conversation ending in manual transcription multiplies by hundreds per month. The cost is not in the individual conversation but in the administrative work it accumulates. That is why the same agent that would be an unnecessary luxury at a small business becomes profitable in an operation with volume. What it does stays the same: what changes is how many times it multiplies.
How Pacunex does it
Pacunex works on the right side of the line. The agents connect to the systems where the real information lives and answer on WhatsApp with current data, not published content.
It is worth being explicit about the state of our integrations, because overstating things in this field is expensive. Pacunex has one integration in production: Asinfo's AS2, resolved by reading its database, which runs on MS SQL Server, PostgreSQL or MySQL depending on the installation. With any other ERP the honest answer is that it can be connected through one of the three paths described, and that the specific connector gets built by the team during the pilot. What we will not tell you is that we already have a tested connector for your ERP brand if we do not.
The two approaches coexist without conflict: the native agent can keep handling general queries while the connected agent takes the ones that require entering the systems.
The useful question, then, is not which agent is better, but what share of your conversations needs a piece of data that today lives inside a system. If that share is low, the project ends at the native agent. If it is high, no amount of catalog configuration will close the gap, because the problem is not configuration but data access.
If you want to review your case with someone who will tell you honestly which side of the line you are on, let's talk on WhatsApp. No form, no credit card. For companies evaluating their first connected agent with direct support from the team, the Pioneers Program has special terms.