Can You Keep Your WhatsApp Business Number When Adding an AI Agent? A Coexistence Decision Guide

Short answer: sometimes. A business can use the same number in the WhatsApp Business app and WhatsApp Business Platform through a supported setup called Coexistence. It is a specific onboarding route, not a universal property of every WhatsApp API account, provider, country, or number. The number’s current state determines which path to investigate. If it is already connected to an API or another business account, the ordinary Coexistence route may not fit. Before changing account settings, deleting an app account, or moving a number, ask the provider to identify the exact route in writing and demonstrate it with a low-risk test.

If you are evaluating a WhatsApp AI agent, Agentic WhatsUp’s English WhatsApp AI agent page is a useful vendor-side starting point for the product discussion; treat its feature descriptions as the company’s own claims and ask how your existing number and account state would be connected. This guide separates that commercial question from platform eligibility. It gives you a decision matrix and a reusable preflight test plan so you can avoid discovering the distinction after a number has been disconnected.

The decision in one minute

First classify the number. Is it active in the consumer WhatsApp app, active in the WhatsApp Business app, already registered to the WhatsApp Business Platform, or connected to a different provider? “I use WhatsApp for business” does not answer this. The consumer app and Business app are distinct starting states; an API sender has a different registration history again.

Next decide what you need to preserve. Do you need to keep replying in the Business app on the same number? Is the current chat history needed in the new workspace? Must the old provider remain available during a cutover? Does the business depend on companion devices, calls, groups, or app-only features? These are separate requirements. A provider’s statement that it “supports WhatsApp” is not proof that it supports every account state or feature.

Then make the vendor name the route: “Business App plus Platform through Coexistence,” “new Platform sender,” or “migration from an existing Platform provider.” If the answer mixes these terms, pause and ask for a diagram and a test plan. WhatsApp’s own onboarding material frames a successful setup around customer experience, business goals, and technical limits, rather than a frictionless switch (WhatsApp Business onboarding guide). That PDF identifies itself as a best-practice guide dated October 2024, so use it as background, not as a live eligibility oracle.

What “Coexistence” means—and what it does not

Coexistence is the name commonly used for onboarding an existing WhatsApp Business app account and its number to the WhatsApp Business Platform while retaining access to the app. The provider documentation from 360dialog describes messages sent through the API appearing in the app and app-sent messages being represented through a webhook echo event. This is a synchronization design, not a promise that every message type, device, history item, or workflow will be identical in both surfaces (360dialog’s current Coexistence documentation).

That distinction matters when an AI agent is added. The AI feature usually runs in software connected to the Platform, while a human may continue to use the phone app, a provider inbox, or a CRM. The customer sees one WhatsApp thread, but the business may have several systems that can send. The design must make clear which systems receive events, which can reply, how duplicate messages are prevented, and what a human can still do from the app. A number appearing in two products does not automatically mean the products share a complete transcript or a single ownership state.

Coexistence is also directional in important ways. 360dialog’s onboarding guide describes the route as connecting an existing Business app account to the Platform; it points businesses that are not using the Business app toward standard Embedded Signup instead (360dialog’s onboarding steps). Its separate guide states that a number already connected to the Platform cannot simply use the same onboarding flow in reverse. Those details are provider documentation and should be confirmed against Meta’s live flow, but they show why “we can keep your number” is too broad to be a decision.

The three number states that get confused

Current state	Question to ask first	Likely route to investigate	What not to assume
Consumer WhatsApp app	Is this the personal app or the Business app?	Ask the provider whether a new business sender is required and what account transition it supports.	Do not assume the consumer account qualifies for Business App Coexistence.
WhatsApp Business app only	Does the provider support Coexistence for this country and account?	Existing Business app number plus the provider’s Coexistence onboarding, if eligible.	Do not assume all app history, linked devices, or features are preserved.
WhatsApp Business Platform / API	Which WABA and provider currently host the sender?	Provider-to-provider or WABA migration, if the source and destination meet requirements.	Do not assume an API number can be converted back into an app-first Coexistence number.
Unknown or partially onboarded	Which Meta business portfolio and WABA has registered the number?	Stop and reconcile the asset owner and registration state before retrying.	Do not repeat signup blindly; an old association may still exist.

The question is not “Does coexistence exist?” It does. The useful question is “Does this provider support the exact route from my current state to the target setup, with the features I need?”

Why two provider answers can both be accurate

A major source of confusion is that Coexistence and number migration are not interchangeable. In its migration instructions, Twilio says that moving a number from the WhatsApp or WhatsApp Business app to its Platform route requires deleting the WhatsApp account first, and warns that the same number then cannot continue in that app. That describes Twilio’s documented standard migration path; it is not proof that no provider offers a separate Coexistence path (Twilio’s phone-number migration guide).

Conversely, 360dialog documents a Business App-plus-Platform Coexistence route and lists limitations for that setup. The difference is not necessarily a contradiction about the platform: the providers may support different product paths. A buyer should not copy one provider’s instructions into another provider’s onboarding. Ask the exact name of the method, the account type and WABA involved, and whether the current number is expected to remain usable in the Business app after activation.

An 8x8 developer guide similarly describes Coexistence for an existing Business app number, but warns that provider-to-provider migration can be a different case and may fail if the number still has a previous Platform association (8x8’s Coexistence guide). Treat this as an operational warning from that provider’s integration, not as a universal Meta rule. These sources support a conservative conclusion: provider support and current asset state are part of the eligibility check.

There is also a small but telling disagreement about how often the Business app must be opened to keep a Coexistence connection active. 360dialog currently says at least once every 13 days; a separate provider guide says 14 days. Do not build a reminder system around the larger number. Ask your provider for the current requirement for your exact connection and use the more conservative interval until it confirms otherwise. This is a source discrepancy, not evidence of a universal 13- or 14-day Meta rule.

A practical decision matrix

Use this before you compare prices or features. The result is a conversation to have with a provider, not a guarantee of approval.

Your non-negotiable	If true, ask for	Stop condition
Keep answering from the existing Business app on the same number	Coexistence eligibility and exact supported app behavior	Provider only offers standard API registration that requires app removal
Keep the number but move from an existing API provider	A documented Platform-to-Platform migration path, source-WABA requirements, template handling, and rollback steps	Provider proposes Business App Coexistence without first checking the current API association
Preserve old conversations	A written history-sync scope, date range, message types, and a sample export or verification method	“History is synced” without saying which messages, devices, or period
Keep linked desktop devices	Device-by-device compatibility and a relinking procedure	Team members expect every companion app to work unchanged
Run AI and manual replies together	A single-source-of-truth design for inbound events, ownership, and duplicate-send prevention	Two systems may answer the same inbound message with no lock or audit event
Launch without risking the main customer number	Test number or staged pilot, plus an account restoration plan	The vendor asks you to disconnect or delete before documenting consequences

A useful vendor answer includes evidence. “Yes, we do coexistence” is a claim. “Your number is currently in the Business app, your country and account are supported, our onboarding presents the existing-app route, these companion devices will need relinking, and these message events will be mirrored” is a verifiable plan.

The preflight: gather facts before opening an onboarding flow

Write down the current state while the existing service still works. Record the exact phone number in international format in a restricted internal record; do not paste it into a public support forum or an article. Note whether it is registered in consumer WhatsApp, WhatsApp Business, or the Platform, and whether any vendor or developer has already attempted signup. Identify the Meta business portfolio and WABA that own it. If nobody knows, that is a discovery task—not a reason to click through another wizard.

Inventory the capabilities that staff actually use: app-sent replies, labels, quick replies, catalog, groups, calls, linked devices, backups, message templates, and CRM synchronization. Ask staff to distinguish “we sometimes need it” from “we cannot operate without it.” A feature can be technically present but unsupported for the precise Coexistence connection. A list is more useful than a general demand to “keep everything.” For account security, keep the Meta portfolio owner and provider access documented, require multi-factor authentication, and avoid spreading customer identifiers across pilot spreadsheets. The U.S. Small Business Administration’s general cyber-safety guidance recommends strong passwords, MFA, encryption for vendor and customer information, and backups (SBA cyber-safety guidance). That is broad small-business security advice, not a WhatsApp-specific onboarding rule.

Ask the provider to classify the transition in one sentence. For example: “We will connect your existing WhatsApp Business app number using the Coexistence path; we will not delete its app registration.” Or: “We will move a number already registered in the Platform to a new WABA, which is a migration.” If the provider cannot fill in the source state, destination state, and user-visible result, do not authorize irreversible changes.

For a Platform-to-Platform move, the migration checklist may include business verification, an approved source WABA, a valid payment method, two-factor settings, the same business portfolio, data-region compatibility, and message-template status. Twilio documents these as requirements or troubleshooting considerations for its route; the destination partner may have additional steps. Its guide also warns that duplicated templates can be reviewed again and may change status. Treat templates as assets to reconcile, not as guaranteed to move unchanged.

For Business App Coexistence, ask about number eligibility, country availability, account age or activity, app version, history sync, companion-device behavior, and the provider’s ongoing app-activity requirement. The 360dialog and 8x8 docs surface these as real provider setup questions. Because eligibility and supported regions can change, request a dated confirmation from the provider and check the current Meta flow when you onboard. Do not decide from an old blog post or a forum answer.

A 15-check acceptance plan

The following is a reusable test design, not a report of measured pass rates. Run it with a test number or an agreed low-risk pilot before routing production customers to an AI agent. Record the expected result, actual result, evidence, owner, and severity for every test. A screenshot alone is not enough for webhook delivery or system ownership; keep event IDs and timestamps with sensitive values redacted.

#	Scenario	Passing evidence
1	Confirm the starting number type	Provider records consumer app, Business app, or Platform sender separately; no ambiguous “WhatsApp number” label remains.
2	Confirm the onboarding route	The signup screen and provider runbook both name Coexistence or standard migration consistently.
3	Verify number ownership	A named business administrator can identify the portfolio and WABA holding the number.
4	Test app eligibility	The flow confirms eligibility or returns a traceable rejection; the provider does not promise approval in advance.
5	Receive a customer text	The customer message appears in the intended app and/or provider workspace according to the documented design.
6	Send from the Business app	The API-connected system receives the documented echo or event, with a stable identifier for deduplication.
7	Send from the API/AI agent	The app display and customer-visible thread match the agreed behavior; the AI does not send a second copy.
8	Test an unsupported companion device	A message from a device that is unsupported is detected as a visibility gap rather than silently counted as handled.
9	Re-link supported devices	Staff can restore supported companion devices and know which ones are not available.
10	Check history scope	The pilot verifies which historic messages arrive, the period covered, and how missing items are handled.
11	Trigger AI-to-human takeover	A human owner receives the conversation and context; the AI pauses before a person responds.
12	Send a human reply, then a simple “thanks”	The workflow does not let a classifier close or reassign the conversation without the configured rule.
13	Test template and service-window behavior	The provider demonstrates the current message rules for the account, including what happens when a customer-service window has expired.
14	Disconnect or restore in a sandbox	The provider shows the supported offboarding or rollback path and what happens to app access, history, and API access.
15	Reconcile logs and ownership	A named admin can trace a customer message to its webhook/event, AI decision, human assignment, and final reply.

This checklist deliberately tests both directions. A vendor demo may prove that an AI can send a reply, while the business problem is whether a human’s app message reaches the AI system, whether it should, and whether a second bot reply can race with it. A reliable pilot documents the event path and the ownership rule, not just the happy-path answer.

A small decision helper you can run locally

This Node.js example does not call Meta, change a number, inspect account eligibility, or contact a provider. It simply exposes the routing distinction in a form your team can use during intake. Save it as whatsapp-number-path.js, run node whatsapp-number-path.js, and replace the sample inputs with a reviewed intake form.

function choosePath({ app, platform, keepBusinessApp, providerSupportsCoexistence }) {
  if (app === 'consumer') {
    return { path: 'pause', reason: 'Consumer WhatsApp is not the same starting state as Business App Coexistence.' };
  }

  if (platform === 'already-registered') {
    return { path: 'platform-migration-review', reason: 'Identify source WABA, current provider, and migration requirements first.' };
  }

  if (app === 'business' && keepBusinessApp) {
    if (!providerSupportsCoexistence) {
      return { path: 'compare-provider-or-number', reason: 'Do not assume standard API registration preserves app access.' };
    }
    return { path: 'coexistence-eligibility-check', reason: 'Confirm account, country, provider, device, history, and feature eligibility.' };
  }

  return { path: 'standard-platform-onboarding', reason: 'Confirm app consequences, number verification, and recovery plan before signup.' };
}

const cases = [
  { app: 'business', platform: 'not-registered', keepBusinessApp: true, providerSupportsCoexistence: true },
  { app: 'business', platform: 'already-registered', keepBusinessApp: true, providerSupportsCoexistence: true },
  { app: 'consumer', platform: 'not-registered', keepBusinessApp: true, providerSupportsCoexistence: true },
];

for (const input of cases) {
  console.log(JSON.stringify({ input, decision: choosePath(input) }, null, 2));
}

The second case is the important guardrail: the provider may support Coexistence in general, yet that does not make an already registered API number eligible for the Business App onboarding route. The first answer is still only “check eligibility”; it is not “approved.” Use the helper to make the discovery conversation consistent, then replace the sample inputs with a signed-off decision record.

A minimal state model for an AI agent

The number path is only the account layer. Once a WhatsApp AI agent is connected, the message layer needs explicit ownership. A practical control model uses three states: AI_ACTIVE, HUMAN_PENDING, and HUMAN_ACTIVE. There should also be an explicit closed or resolved state in the CRM. A customer asking for a person, a policy boundary, an uncertain identity, a repeated failure, or an unavailable integration can move a conversation to HUMAN_PENDING. The AI should stop sending customer-facing replies as soon as that transition commits. It resumes only after a defined hand-back event, not because a later message looks easy.

Implement the ownership change as a durable event keyed by the provider’s message or conversation identifier. Process webhook retries idempotently. If the same inbound event arrives twice, the second attempt must not create a duplicate customer response or a second ticket. If a human claims the conversation while a model response is being generated, the final send check should re-read the current state and discard the stale AI response. Prompts alone cannot provide that concurrency guarantee.

A concise event record can contain a pseudonymous conversation key, previous state, next state, transition reason, actor, timestamp, source event identifier, and the version of the rule that caused the transition. This matters because a customer message is untrusted input even when the channel is familiar: OWASP’s LLM application risk project identifies issues such as prompt injection, sensitive information exposure, and excessive agency. Those categories are not measured probabilities, but they give an AI-agent owner a concrete reason to limit tools and data permissions (OWASP LLM application risks). Keep full message content only where necessary for support and audit; use a summary that preserves what the customer asked, what has already been tried, what the model could not verify, and what action remains. A person should be able to correct the summary without editing the original customer message.

This is not a Meta-mandated schema. It is an implementation recommendation derived from the fact that Coexistence can surface messages from app and API pathways while an AI service adds another sender. The provider’s webhook documentation should determine which events are available and how echoes are identified. Test that exact contract rather than assuming an app reply and an API reply are indistinguishable. A 2026 research framework based on 4,574 B2B service opportunities across 23 countries found that relationship and opportunity characteristics mattered to bid decisions, but it did not study WhatsApp, AI handoffs, or small-business software; it is relevant only as a reminder that a useful handoff carries customer context, not as evidence of channel performance (the B2B opportunity-management study).

The real user question behind the technical terms

A public Manychat community thread from August 2025 asks whether someone can move from the API back to the official WhatsApp Business app in order to use Coexistence. The accepted response says, as of that discussion, the method was intended for businesses already using the Business app and could not be reached by reversing an API setup (the original community question and answer). That is one old support discussion, not a current policy and not evidence of how common the problem is. It illustrates the concrete question buyers are trying to resolve: “Can I do this in the order I planned?”

The answer needs to be state-specific. The official Meta developer video about the architecture of Business Agent on WhatsApp presents AI agent configuration and in-conversation user experience, but its published description is an architecture overview, not a guarantee that any existing number can enroll in any provider’s Coexistence route (Meta’s June 2026 architecture video). A product demo is useful for understanding what the agent might do. The provider and Meta setup flow still need to establish whether the number can be connected that way.

This difference is where a sales conversation can become misleading without anyone intending to mislead. A company may accurately say it offers a WhatsApp AI agent, while a particular customer’s number remains attached to a different WABA, an unsupported region, or an integration that cannot keep the Business app active. Make the vendor answer two separate questions: “Does your agent support my desired workflow?” and “Can my current number enter the required WhatsApp route?”

What to ask a provider before signing

Ask the provider to show the exact signup screen you will use, with sensitive identifiers hidden. Ask for the names of the source and destination WABAs, whether the flow is Coexistence or migration, and which business administrator will own the assets after setup. Ask which tasks will be done by the provider and which require your Meta portfolio administrator. If the answer requires turning off two-factor settings or deleting an account, ask why, for how long, who will do it, and how you can restore access if verification fails.

Ask for a written feature comparison for the mode they propose. Include mobile app access, companion devices, calls, groups, catalog, templates, message history, reporting, and API callbacks. “The number works” is not the same as “the workflow we need works.” The 360dialog documentation, for example, lists limitations for certain account and feature combinations, while its onboarding material explains that a supported Business app route differs from standard Embedded Signup. Those pages are specific to 360dialog’s implementation; the vendor you select should give you its own current list.

Ask how the Business app’s manual replies appear in the AI or CRM system, whether the AI can read them, and whether the system treats them as a new customer-facing message. Ask what prevents the AI from replying at the same time as an employee. Ask what happens when webhooks are delayed, duplicated, or unavailable. Ask whether the AI can be manually paused from the staff workspace and whether the pause takes effect before an in-flight generated answer is sent.

Ask about costs using scenarios, not a single headline price. Separate the provider subscription, Platform usage charges, AI model charges, human support costs, and any migration or integration work. The applicable messaging price and template/service window can change; the 360dialog reference currently describes its 24-hour customer service window and template requirements. Verify the current Meta pricing and message rules in the account’s country before estimating totals.

Finally ask for success and rollback criteria. A successful test should mean the right inbound messages reach the right place, no duplicate reply is sent, app access behaves as promised, a human can take over, and the audit trail can identify the event chain. A rollback should say what happens to the number, old app, current WABA, templates, messages, and provider access. If the provider cannot describe the rollback, keep the first pilot away from the number on which the business depends. Bain’s service-center brief describes predictive routing as matching a customer and agent based on interaction context and agent capability; its examples come from large service operations and do not establish expected outcomes for WhatsApp AI agents (Bain’s service-center analysis). Use it as a design lens for escalation, not as a promised ROI.

Failure modes to design out

Choosing the wrong signup branch. A user selects “new API number” when the intent was an existing Business app plus Coexistence, or chooses Coexistence for a number already registered to the Platform. The fix is an account-state decision before signup, not repeated retries.

Treating “history sync” as a backup. A provider may sync a subset of chats or a specific time range. That is not necessarily a complete archive, legal retention system, or restoration mechanism. Export and verify what the business must retain before making changes; do not use sync language as a substitute for a documented data inventory.

Losing visibility from a linked device. Some provider documentation warns that messages from unsupported companion clients may not emit the webhook echo needed to mirror them in a connected system. A team can then believe the AI or CRM has seen the whole conversation when it has not. Test every actual device path, and treat missing echoes as a visibility state.

Assuming one vendor’s rules apply to another. Twilio’s standard migration path and 360dialog’s Coexistence path have different outcomes. Copying steps from a tutorial can disconnect a number or produce a duplicate signup error. Use the destination provider’s current runbook and confirm it against Meta’s current flow.

Two senders answer at once. The app, AI, and employee inbox can all be valid senders. Without a single ownership state, a human answer may be followed by an AI response generated earlier. Recheck ownership at send time and make pause/resume transitions auditable.

Confusing approval with eligibility. A provider may support Coexistence, but Meta can still decline the specific account or number. Treat vendor capability and number eligibility as separate gates; do not schedule a customer-wide cutover until the actual flow succeeds.

Using a repeated retry to fix a hidden account association. A user-facing screen may say the number is unavailable even though an earlier signup attempt left a WABA relationship in place. Ask the provider to inspect the portfolio and number association before removing or recreating assets. Keep a ticket or error identifier.

A staged rollout that limits surprise

Start with a written baseline. Record the current number state, WABA, provider, devices, key workflows, history requirement, and contact responsible for Meta account administration. Take a backup or export only through a method approved for the business, and confirm that the backup actually contains what the team needs. Do not assume an API migration imports a mobile app’s complete history. Twilio’s standard migration docs explicitly distinguish app-based migration from Platform-to-Platform transfer; that distinction is precisely why the baseline matters.

Next run the provider’s onboarding flow with a test number if the product permits it. If no test number can exercise the relevant Coexistence route, ask the provider for a sandbox, a recorded demonstration from the same route, or a supervised pilot with a rollback plan. A generic demo with a newly issued API number does not prove your app number will be eligible.

Then run the 15-check plan. Keep a simple ledger: test_id, expected result, observed result, event or screenshot reference, owner, severity, and status. Never include raw customer phone numbers in a shared spreadsheet. Use synthetic contacts and test messages. Keep changes reversible and small; do not add marketing campaigns or bulk messages to a technical onboarding test.

Only after the basic message loop works should you attach the AI agent. First configure it to answer a narrow, low-risk class of questions from a reviewed knowledge source. Use human review or a dry-run mode for uncertain answers. Confirm that the AI sees only events it is intended to process, that the employee can take ownership, and that the AI cannot send after a handoff. Expand use cases only after the team has observed the real message paths and has an owner for failure recovery.

Finally run a time-bounded pilot and review the evidence with operations, customer support, and whoever owns the Meta business assets. The first review should focus less on “how many conversations did the bot contain?” and more on whether every conversation reached a valid owner, whether any app message was invisible to the integrated system, whether the human had enough context, and whether the customer had to repeat themselves. Stop the pilot if the state is unclear or if an unresolved failure can make the business appear to ignore a customer.

Decision flow

flowchart TD
    A[Identify current number state] --> B{Consumer app?}
    B -->|Yes| C[Ask provider for supported business sender path]
    B -->|No| D{WhatsApp Business app only?}
    D -->|Yes| E{Need to keep replying in app?}
    E -->|Yes| F[Check Coexistence eligibility and device limits]
    E -->|No| G[Compare standard Platform onboarding and new number]
    D -->|No| H{Already registered on Platform?}
    H -->|Yes| I[Plan provider or WABA migration]
    H -->|No or unknown| J[Resolve portfolio and WABA ownership first]
    F --> K[Run acceptance tests and rollback rehearsal]
    G --> K
    I --> K
    J --> K
    K --> L{All required paths pass?}
    L -->|Yes| M[Stage the AI pilot]
    L -->|No| N[Keep current setup and resolve failed gate]

The diagram is intentionally conservative. A consumer-app number is not automatically a Business App Coexistence candidate; a Platform-registered number is not automatically reversible into an app-first setup; an unknown state is not permission to try whichever signup button appears first. All routes end at a test gate before the AI pilot.

What this guide does not establish

This is a desk-research decision guide, not an account eligibility check, legal opinion, or claim about any provider’s current commercial offer. Research completed on 31 October 2026 reviewed six source artifacts: WhatsApp Business onboarding material, Meta’s published Business Agent architecture video, Twilio’s migration documentation, two 360dialog Coexistence documents, and 8x8’s Coexistence guide. I also reviewed one public customer question in the Manychat community. I did not access a real WhatsApp Business account, run Embedded Signup, test a number, or measure provider approval rates.

The sources have different scopes and dates. The WhatsApp onboarding PDF says it is an October 2024 best-practice guide; Meta’s architecture video is dated June 16, 2026; the provider documents describe each provider’s supported flow, not every provider’s implementation. One support question is from 2025 and is included only to illustrate the question, not as a current technical authority. The 13-versus-14-day app-activity detail is explicitly unresolved here because provider documents differ. Confirm live requirements with Meta and the selected provider immediately before onboarding.

The fifteen acceptance checks are a designed test suite, not a measured sample of businesses. Their purpose is to expose route, visibility, ownership, and rollback assumptions before production use. They do not estimate how often Coexistence succeeds or quantify customer satisfaction. A result from one account cannot establish eligibility for another account, country, provider, or WABA.

The decision rule

Keep the existing number and app only if the provider confirms the exact Coexistence path for your current Business app account, the real onboarding flow accepts the number, and the features your staff require pass the acceptance plan. If the number is already on the Platform, treat it as a migration project and confirm source-WABA requirements; do not try to force it through an app-first route. If the existing app is not essential, compare a standard Platform setup with a new number and weigh the change in customer contact details against the additional operational clarity.

The safe sequence is therefore: classify the number, list the non-negotiable features, get a dated route confirmation, test the signup and message paths, verify human takeover and history scope, then authorize a production cutover. Any step that depends on deleting or disconnecting something should have a named owner, a reason, a recovery plan, and a recorded customer impact.

Final checklist

• [ ] We know whether the number is in consumer WhatsApp, WhatsApp Business App, or WhatsApp Business Platform.
• [ ] We know the current provider, business portfolio, and WABA, including any incomplete signup attempt.
• [ ] The provider named the route as Coexistence, new Platform onboarding, or Platform migration.
• [ ] We received a current eligibility answer for our account, country, app version, and number.
• [ ] We know which app features, companion devices, history, templates, and message types may change.
• [ ] We tested app and API messages in both directions and recorded the resulting events.
• [ ] Duplicate events and simultaneous AI/human replies are prevented by durable state, not only by prompt instructions.
• [ ] The AI pauses at human handoff, and a human can resume or close the conversation with an audit record.
• [ ] The test uses synthetic contacts or an approved low-risk pilot and does not expose customer identifiers.
• [ ] A named owner can restore the previous operating state or explain why rollback is unavailable.

Research note

I prioritized the GSC opportunity agent ia whatsapp for the selected WhatsApp-agent site: the 26 October tracked Search Console snapshot reports an average position of 14.6 over 23 impressions in its 22–29 October window. These are impressions and average position, not clicks, and the position can vary by query and context. The indexed English page was separately inspected: Google’s selected canonical matched the page, indexing was allowed, and fetch succeeded. The exact English home page had no Search Analytics rows in the direct page-and-query check for the 16–29 October period, so the GSC figure is an opportunity signal for the domain’s related French query, not proof that the English page already ranks for this English article.

The source review covered official onboarding guidance and an official Meta architecture video, four provider documentation pages across Twilio, 360dialog, and 8x8, and one customer question in a provider community. I did not use a survey or infer demand frequency from a single thread. The novel asset is the number-state decision matrix plus the 15-case acceptance plan; teams can reuse it to record route, event visibility, ownership, and rollback evidence during their own pilot. The case count describes the test plan’s scope, not results from a tested sample.

The right answer is not “Coexistence always works” or “the API always replaces the app.” It depends on the starting registration, the selected route, the number’s eligibility, the provider’s current support, and the business features that must survive. Make those conditions visible before signup, and a WhatsApp AI agent becomes a deliberate operating change instead of an irreversible guess.