Meta Business Agent, Explained for Wedding & Event Businesses

On June 3, 2026, Meta launched Meta Business Agent — its own hosted AI that answers your customers on WhatsApp, in your brand's voice, around the clock. Meta says more than a million businesses were already using it at launch, seeded by roughly two years of pilots in India, Mexico and Brazil. If you run a wedding or event business on WhatsApp, you have either seen the pitch already or you will soon.

Weddingkart is a Business Solution Provider (BSP) on the WhatsApp Business Platform — we operate WhatsApp infrastructure for wedding businesses every day, so we read every page of the new developer documentation. This guide covers what the agent actually does, what is confirmed versus still undocumented, and how an events business should decide. The short version: Meta Business Agent solves the front-desk problem — one business, one knowledge base, one stream of customer questions. Weddings have a context problem — hundreds of guests whose answers depend on who they are and which wedding they belong to. Those are different problems, and it pays to know which one you have. (If you're evaluating vendors at this infrastructure layer, compare with tools like AiSensy or Wati.)

What Meta Business Agent actually is

Per Meta's developer docs, it is "an enterprise AI agent that engages your customers on WhatsApp in your brand's voice." It handles conversations autonomously and escalates to your team when needed. You feed it knowledge — business information (hours, locations, policies), FAQ pairs, your website (crawled), uploaded files, and your product catalog — and define "skills" that set its tone and priorities. Everything is configurable through WhatsApp Manager or through a set of APIs: onboarding and eligibility, knowledge management, settings, and testing.

The most important capability for any real business system is Connectors: you can register your own external APIs so the agent can take actions, not just answer — Meta's docs name booking an appointment, confirming a payment, and checking order status. Meta's launch post says the platform connects to "hundreds of systems" including Shopify and Zendesk. Note two caveats we could not get past: reporting from several WhatsApp vendors places Connector/API access in the enterprise platform tier (early access, waitlisted as of July 2026), not the free self-serve product; and no page in the primary documentation states connector rate limits, payload limits, or authentication constraints.

Pricing, as of this writing: activation is free, and Meta says paid subscription offerings arrive "in the coming months," with launch-day reporting pointing to WhatsApp Business Premium tiers for smaller businesses and token-based usage billing for large ones. One July report (unconfirmed by Meta) says the free window ends August 1, 2026. Also worth knowing: despite the global launch headlines, Meta's own help page for the small-business product still says it is available "in limited countries to select businesses," with a waitlist. Treat every pricing and availability claim — including ours — as dated.

Confirmed vs unclear, as of July 23, 2026

Confirmed in Meta's primary documentation: the knowledge sources listed above; skills for tone and brand voice; Connectors that call your APIs; an Eligibility endpoint that checks a specific WhatsApp Business phone number; enablement by BSPs and Tech Providers on behalf of client accounts (via Business Integration System User tokens); coexistence with your own application through the messages, standby and messaging_handovers webhooks; Thread Control with a pass action to return control to the agent; and Agent test and Agent eval endpoints for pre-launch evaluation. Availability is restricted to approved countries and verticals: Automotive, Consumer Packaged Goods, Professional Services, Retail & Ecommerce, and Travel, across 182 countries including India.

Not documented anywhere we could find — and we looked adversarially: whether the agent's knowledge base is scoped per phone number, per WhatsApp Business Account, or can be segmented per conversation; concrete Connector limits; and whether a business gets transcript-level access to what the agent actually told each customer. Meta's announcement promises "enterprise-grade controls, guardrails, and measurement," but the only documented surfaces are pre-deployment testing and evaluation endpoints. There is also no guidance on whether a wedding or events company qualifies under Professional Services — the five-vertical list simply has no events category. These gaps matter more for events businesses than for most, as we'll get to.

Where Meta Business Agent genuinely works well

Credit where due: for a single-brand business whose customer questions are FAQ-shaped — a store, a salon, a travel agency, a restaurant — this is a serious product, not a toy. One knowledge base genuinely describes the business. The agent answers at 2 a.m., recommends from your catalog, books appointments through a connector, and hands off to a human when it should. It costs nothing to try (today), needs no engineering for the basic setup, and Meta's model quality and distribution are as good as it gets on WhatsApp. If that describes your business and your country and vertical are eligible, trying it is a reasonable default. Two years of piloting in India also means it is not a US-first product bolted onto Indian usage patterns.

Why weddings are a harder problem: tenant context

A wedding company's WhatsApp number does not serve one business. It serves many weddings at once — each one a temporary tenant with its own guest list, its own schedule of ceremonies, its own venues, room blocks and travel plans. A planner running six weddings is, from a messaging perspective, six businesses that happen to share a phone number. And the guests' questions are not FAQ-shaped. "What time is the sangeet?" depends on which wedding. "Is my room booked?" depends on who is asking. "Am I invited to the haldi?" is a database lookup keyed to a phone number, a guest record, and one specific event — not a paragraph anyone would put on a website.

Meta Business Agent's documented knowledge sources are all business-level: FAQs, business info, websites, files, catalogs. Nothing in the documentation describes per-conversation tenant segmentation — the ability to answer guest A from wedding 1's data and guest B from wedding 2's, on the same number, without leakage. Could you build it with Connectors? In principle, yes: a connector can look up per-customer data, and that is confirmed. But walk through what that means. You would be building the guest database, the phone-number-to-guest resolution, the per-wedding routing, and the privacy rules — the entire specialist system — and then running it inside an agent whose knowledge scoping, connector limits, and conversation logs are not yet documented. You would own all of the hard parts and control none of the runtime.

The audit gap deserves its own paragraph. In ordinary customer support, a wrong AI answer is an annoyance. At a wedding, "the baraat starts at 3" when it starts at 1 puts real families in the wrong place on a day nobody gets to redo. An events business needs to see exactly what was said to every guest, and needs errors surfaced to the planner — the person who can actually fix the plan. As of today, Meta's documentation does not describe transcript-level audit access to agent conversations. That is not an accusation — the product is seven weeks old — but it is a fact a wedding business should weigh before delegating guest-facing answers to it. A guest list is also personal data: who is invited, where they sleep, when they travel. Answering those questions safely needs per-guest permissioning that no current documentation addresses.

Shared number or your own number: the architecture that decides it

Events businesses run WhatsApp in two shapes. Some use a platform's shared channel — many weddings behind one professionally-run number. Others connect their own number through Embedded Signup and send as their own brand. Meta Business Agent is enabled per phone number (the Eligibility endpoint checks exactly that), so the shared-channel case is the hardest possible fit: one agent, one knowledge base, hundreds of overlapping weddings. But note that the per-business number does not escape the problem — a planner's own number still serves every wedding on their roster. The tenant-context problem follows the business model, not the phone number. Before planning anything, run the eligibility check for your number and confirm your vertical classification with Meta or your BSP; "Professional Services" may or may not cover events, and the documentation does not say.

Can you run Meta's agent alongside your own bot?

Yes — and the mechanics are worth knowing, because they are the part most coverage gets wrong. Per the setup documentation, your application subscribes to three webhook fields: messages, standby, and messaging_handovers. When Meta Business Agent is enabled, it becomes the primary responder; your own application becomes a standby participant that still receives conversation traffic on the standby field. Your app takes control simply by sending a message — no takeover call — and hands control back using the Thread Control endpoint's pass action. (If you have built on Messenger before: this is not the old Handover Protocol, which Meta retired; WhatsApp thread control is its own mechanism.) BSPs like us can enable and operate all of this on behalf of client accounts using Business Integration System User tokens. That distinction matters: it's the sanctioned path for a BSP to act on a client's behalf, not the unofficial workaround-style automation that gets accounts banned — see why WhatsApp blocks unauthorized automation for what actually trips their detection.

So coexistence is architecturally real. What the documentation leaves to you is everything that makes coexistence safe: deciding which questions belong to which system, keeping the two agents from contradicting each other, logging what each one said, and making sure an escalation lands with a human who has the wedding's context. Routing ownership is an engineering discipline, not a webhook subscription.

Should you turn it on? A decision guide

Turn it on if: you are a single brand with one coherent knowledge base; your customer questions are mostly FAQ-shaped (hours, prices, offerings, policies); your country and vertical pass the eligibility check; your pain is after-hours coverage; and the answers you need do not depend on looking up who is asking. A venue answering "do you allow outside caterers?" or a decor company answering "do you serve Jaipur?" fits this well.

Hold off if: one number serves many events or clients; the answers guests need are per-person (invitations, rooms, travel, seating); you need an auditable record of what was said to each guest; you already run a specialist bot and cannot yet invest in routing ownership; or your vertical eligibility is unclear. In these cases the generic agent does not fail loudly — it answers confidently from business-level knowledge, which is precisely the failure mode a wedding cannot afford.

Either way: run the Eligibility endpoint for your number before you plan anything, re-check pricing on Meta's own pages before you commit (the free window is reportedly closing), and if you enable it next to an existing bot, decide on paper which system owns which question before the first guest message arrives.

Where Neeti fits

We build the specialist layer this article keeps referring to. Weddingkart's AI assistant, Neeti, is wedding-context by construction: it knows which wedding each guest belongs to, reads the live guest list, RSVPs, ceremony schedule, rooms and travel records, answers each guest personally in their language, and logs every exchange where the planner can see it — with anything it cannot answer routed to the planner, never guessed. Meta Business Agent is the front desk; Neeti is the operations desk. If Meta's agent fits your business, use it — genuinely. If your problem is guest operations across weddings, that is the problem we built Weddingkart for.