Qontak | AI Agent | Meta Business Agent Integration — ANCHOR
ANCHOR PRD — the initiative master index. It orchestrates all phases beneath it and carries no single-delivery execution detail (Non-Goals, Constraints, Observability, and Dependencies live in the Phase PRDs).
HEADER BLOCK
| Field | Value |
|---|---|
| PM | Dimas Fauzi Hidayat |
| PRD Version | 1.6 |
| Status | DRAFT |
| PRD Type | ANCHOR |
| Anchor | Yes — this IS the Anchor |
| Labels | epic:qontak-chatbot | module:ai-agent | feature:meta-business-agent |
| Last Updated | 2026-07-21 |
Table of Contents
- HEADER BLOCK
- PHASE INDEX
- One-liner + Problem
- What Happens If We Don't Build This
- Target Users + Persona Context
- Success Metrics (Initiative-level)
- Key Decisions + Alternatives Rejected
- Open Questions
- PRD CHANGELOG
1. PHASE INDEX
This table is the source of truth for all phases. Goal column must exactly match each child Phase PRD's "Phase Goal" field.
| Phase | Goal | PRD Link | Epic Key | Status | Shipped |
|---|---|---|---|---|---|
| Phase 1: MBA-Aware Foundation | Make the Qontak inbox fully aware of MBA-run conversations — persist standby copies, track who controls each room, and let agents take over and hand back. | phase-1-mba-aware-foundation.md | TBD | 📝 Draft | — |
| Phase 2: MBA Management & Config Sync | Let org admins onboard, configure, and operate MBA from Qontak — eligibility → onboarding → allowlist → settings on the channel page, with admin-selected knowledge/persona synced from the existing AI agent on publish. | phase-2-mba-management-config-sync.md | TBD | 📝 Draft (gated: MBA GA + pricing in Indonesia) | — |
| Phase 3: Connector Gateway + Test/Eval | Let MBA execute Qontak-hosted actions through an authenticated connector gateway, and run existing AI agent test cases against Meta's agent test/eval APIs. | phase-3-connector-gateway-test-eval.md | TBD | 📝 Draft (sequenced after Phase 2) | — |
2. One-liner + Problem
One-liner: Enable Qontak organizations to run, observe, and control Meta Business Agent — Meta's hosted AI responder on WhatsApp — entirely from Qontak.
Problem:
Meta Business Agent (docs updated 2 Jul 2026) becomes the primary responder on a WhatsApp number when enabled, and the business app is demoted to a standby observer — but Qontak today does not process the standby or messaging_handovers webhook fields, has no Thread Control client, and exposes no MBA management surface. Any Qontak customer with an eligible WABA can enable MBA directly in WhatsApp Manager, at which point their inbox goes partially blind (agent replies invisible, control state unknown) and a human who takes over can never hand the conversation back. Left unaddressed, this displaces Qontak's core chatbot value proposition on its highest-volume channel and disintermediates Qontak into a passive inbox — while from 1 Oct 2026 Meta also meters every service message, changing the economics of the channel itself.
3. What Happens If We Don't Build This
- Blind inbox on first customer adoption — the moment one Indonesian customer enables MBA in WhatsApp Manager (Meta pilot posture suggests months, not years), their Qontak transcript silently loses MBA's replies and control state; support tickets follow.
- Disintermediation of the AI layer — customers who adopt MBA outside Qontak rationalize "Meta's agent, Meta's channel, one bill"; Qontak loses the chatbot seat and the data, keeping only human-handling scraps.
- No honest competitive data — without standby persistence Qontak cannot measure MBA containment vs its own AI agent side-by-side, so pricing/positioning decisions against MBA stay guesses.
4. Target Users + Persona Context
Primary Persona: CS Supervisor / Org Admin (WhatsApp-first support org)
| Field | Detail |
|---|---|
| Role | Supervisor or org admin running WhatsApp customer service on Qontak, evaluating or enabling Meta Business Agent on their number |
| Goal | Adopt Meta's AI responder without losing the Qontak inbox, transcript history, human escalation flow, and reporting they run the operation on |
| Pain | Enabling MBA today makes Qontak partially blind; there is no way to configure MBA from Qontak or return a conversation to it after a human steps in |
| Workaround | None — either don't enable MBA, or enable it in WhatsApp Manager and accept a broken inbox |
Secondary Persona: CS Agent (inbox user)
| Field | Detail |
|---|---|
| Role | Agent handling WhatsApp conversations in the Qontak inbox |
| Goal | See the full conversation (including MBA's replies), know who is driving, and take over cleanly when a customer needs a human |
| Pain | MBA-run conversations would appear with missing messages and no control indicator; after replying, the agent owns the room forever |
| Workaround | None — asks the customer to repeat context; room never returns to the AI |
5. Success Metrics (Initiative-level)
North-star metrics for the full initiative — per-phase metrics live in each Phase PRD.
Adoption & Usage:
| Metric | Definition | Baseline | Target |
|---|---|---|---|
| ⭐ MBA-through-Qontak attach rate | % of MBA-enabled customer WABA numbers where MBA is onboarded/managed via Qontak (vs. directly in WhatsApp Manager) | N/A — MBA not yet GA | ≥70% of MBA-enabled Qontak customer numbers within 2 quarters of Phase 2 GA |
| MBA-aware orgs | # of organizations with mba_aware_inbox active and ≥1 MBA conversation observed | N/A — new capability | 100% of orgs with MBA-enabled numbers (Phase 1 is the safety net, not opt-in value) |
Quality & Accuracy:
| Metric | Definition | Baseline | Target |
|---|---|---|---|
| Transcript completeness on MBA rooms | MBA-room messages persisted in Qontak ÷ messages delivered on standby/messages webhooks | N/A — standby not processed today (0%) | ≥99% within 30 days of Phase 1 GA |
| Control-state accuracy | Rooms whose displayed controller matches the last messaging_handovers event | N/A | 100% (measured in beta and continuously) |
Efficiency & Impact:
| Metric | Definition | Baseline | Target |
|---|---|---|---|
| Side-by-side containment comparability | Ability to report MBA containment vs Qontak AI containment per org (rooms resolved without human takeover) | Not measurable today | Reportable for 100% of MBA rooms from Phase 1 data (reporting itself ships via the AI ROI report initiative) |
| Time-to-take-over | Median time from customer message needing a human to agent's first reply on MBA rooms | N/A | ≤ existing human-first-response median on non-MBA WhatsApp rooms |
6. Key Decisions + Alternatives Rejected
6a — Decisions Made
| Date | Decision | Rationale |
|---|---|---|
| 2026-07-07 | Adopt MBA defensively inside Qontak (Track 1 of the three-track strategic response) rather than ignore or block it | If customers will get MBA anyway via WhatsApp Manager, running it through Qontak keeps the seat, the data, and the actions; code grounding shows ~90% of the config surface already exists |
| 2026-07-07 | Phase 1 (MBA-aware foundation) ships ungated; Phases 2–3 are gated on MBA GA + pricing in Indonesia | The blind-inbox risk exists the moment any customer enables MBA — awareness cannot wait for our management build; the management build shouldn't precede a sellable product |
| 2026-07-07 | The existing AI agent (Profile / Capabilities / Routing) is the single source of truth for MBA config; sync fires on the existing publish event | No second agent builder; mirrors how SyncToAiService already pushes config to Qontak's AI Service on publish — grounded against chatbot repo |
| 2026-07-07 | All MBA UI lands on existing pages (channel Account details section, Resources/Actions columns, inbox elements) — no new pages or routes | IA-alignment rule: existing pages already carry per-number Meta capability sections (call/catalog/commerce anatomy); wireframed field-accurate 2026-07-07 |
| 2026-07-07 | MBA connector tools will execute through a Qontak-hosted gateway (Phase 3), never customer-hosted endpoints | Keeps credentials and action execution in Qontak ("we keep the hands") — the strategic lock-in that survives even if Meta owns the conversation |
| 2026-07-18 | MBA and the Qontak AI agent live side-by-side at org level off one shared linked config, with scoped divergence on existing surfaces: per-source Meta-sync toggle (P2 S06), per-action expose toggle (P3 S01), per-field Profile Meta overrides (P2 S08), MBA-only operational settings on the channel section (P2 S07) | One authoring surface + opt-out/override beats a forked agent entity — no drift, no double authoring, no new pages; the one-AI-per-number guard is untouched (coexistence is across numbers, never two responders on one) |
| 2026-07-19 | Zero Mekari AI Services (DSAI) dependency across all MBA phases — the integration is wholly Qontak-owned: chatbot/hub-core talk to Meta directly, Meta does its own ingestion/crawling/embedding; AI Services remains only in the existing Qontak-agent path | PM requirement per the standing cross-team-dependency rule; technically free because Meta consumes raw bytes/URLs, not embeddings — code-verified that raw knowledge files already live in Qontak's OSS |
| 2026-07-18 | PRDs re-grounded against Meta's published MBA Platform API docs v2.0.0 (API surface & build maps: §7 of each Phase PRD) | Corrects Thread Control to release (P1 v1.4), adds settings/audience/follow-up + Business info + skills-collection reality (P2 v1.4), resolves the connector auth mechanism + adds tool smoke-test and connector-logs endpoints (P3 v1.4) |
| 2026-07-21 | Omnichannel-AI direction (vision — feeds the Automation Flow Builder initiative, does not change Phase 1–3 scope): (a) the AI provider is chosen per channel/number on the existing AI agents page — one "Runs on" column + one provider field in the existing deploy-to-channel drawer, no new page; (b) MBA additionally becomes a hand-off node in the generalized flow: a capability-gated terminal node (executes Thread Control release) with a fallback output port for channels/numbers where MBA is unavailable, guarded by NodeRegistry supported_channels/requires metadata + a save-time lint. No MBA-specific flow type — one multi-channel flow serves all providers. Coexistence accordingly evolves from per-number mutual exclusion (OQ-4) to composition: per number, either MBA-primary (flow dormant; Qontak observes on standby) or flow-primary (flow orchestrates; MBA reachable as a hand-off node) | Delegated providers can only be orchestrated at hand-off boundaries (release / take-over / observe — never per-turn; after release the flow receives only standby copies until a take-over), so the node is terminal by protocol. A dedicated MBA flow would fork the one-flow-many-channels model the flow builder exists to unify. The node lands with the Automation Flow Builder engine; the legacy tree gets it only if needed earlier |
6b — Alternatives Rejected
| Alternative | Why Rejected | Date |
|---|---|---|
| Do nothing / advise customers not to enable MBA | Unenforceable — MBA is a tab in WhatsApp Manager on the customer's own WABA; Qontak would still go blind on standby traffic | 2026-07-07 |
| Build a separate MBA console (new pages/module) | Inflates scope and drifts from the IA; the channel detail page already stacks per-number Meta capability sections that MBA fits exactly | 2026-07-07 |
| Duplicate persona/handoff config in the MBA section | Creates two sources of truth; persona, tone, language, and handoff already live in the AI agent builder and map 1:1 to MBA Skills/settings | 2026-07-07 |
| Wait for MBA GA before building anything (including awareness) | Leaves the blind-inbox window open for the entire pilot period; Phase 1 components (webhook fields, thread control) are small and reusable regardless | 2026-07-07 |
| Full build now (all 3 phases before GA) | Meta's allowlist/pilot posture and unknown pricing make the management surface premature; risk of building against a moving API | 2026-07-07 |
7. Open Questions
| # | Type | Question | Owner | Deadline |
|---|---|---|---|---|
| 1 | Open Question | When does MBA reach GA in Indonesia, and at what price? (Gates Phase 2 commit) | Dimas F — via Meta partner manager | 2026-08-31 |
| 2 | Open Question | BSP / Tech Provider terms for MBA: does managing MBA via BISU tokens carry revenue-share or ToS implications for Qontak — and how does Qontak obtain the bizai_wa_enterprise_api_3p_access tech-provider capability the MBA Platform APIs accept as the alternative to per-customer permissions (docs v2.0.0)? | Dimas F + Partnership | 2026-08-31 |
| 3 | Open Question | Packaging: is MBA management a paid add-on (WhatsApp-commerce upsell pattern) or included (WhatsApp-call pattern)? | Dimas F + Pricing | 2026-09-15 |
| 4 | Assumption | One AI responder per number: enabling MBA requires disabling the Qontak bot flow / AI agent on that number, and migration UX is a Phase 2 concern — long-term direction: this guard evolves to composition via the Automation Flow Builder hand-off node (§6a, 2026-07-21); until that engine lands, this assumption governs Phase 2 | Dimas F | 2026-08-15 |
| 5 | Risk | Meta bundles MBA free/cheap with WABA, undercutting Qontak's AI pricing — Mitigation: Track 3 system-of-record principle (transcript, connector gateway, scorecard stay in Qontak regardless of who answers) + Track 2 offensive plays ship first | Dimas F | 2026-10-01 |
| 6 | Risk | Building Phase 2 against a pilot-stage API that changes at GA — Mitigation: Phase gating (Open Question 1) + Phase 1 limited to webhook/thread-control surfaces already shared with the stable Handover Protocol | Dimas F | 2026-08-31 |
Risk-type rows carry mitigation paths — required before this ANCHOR can move to ACTIVE.
PRD CHANGELOG
| Version | Date | By | Section | Type | Summary |
|---|---|---|---|---|---|
| 1.0 | 2026-07-08 | Claude | All | CREATED | Initial ANCHOR PRD created from the MBA strategic-response grounding (code + design/IA grounding of 2026-07-07). |
| 1.1 | 2026-07-08 | Claude | Phase Index | MODIFIED | Phase 2 and Phase 3 PRDs drafted (ahead of their gates, per PM) — links added, statuses moved to Draft. |
| 1.2 | 2026-07-18 | Claude | Phase Index | MODIFIED | Phase 2 goal now reads "admin-selected knowledge/persona" — per-item MBA-vs-Qontak scope choice added across Phase 2 (per-source Meta sync toggle, MBA2-S06) and Phase 3 (expose-toggle scope semantics, MBA3-S01/AC-3); goal wording kept verbatim-matched with the Phase 2 PRD (v1.3). |
| 1.3 | 2026-07-18 | Claude | 6, 7 | MODIFIED | API-grounding sweep vs Meta MBA Platform docs v2.0.0 (API surface & build maps in each Phase PRD §7): side-by-side + scoped-divergence model recorded as a decision; child PRDs bumped (P1 v1.4 release fix, P2 v1.4 S07–S09, P3 v1.4 auth/smoke-test/logs); OQ-2 extended with the bizai_wa_enterprise_api_3p_access tech-provider capability. |
| 1.4 | 2026-07-18 | Claude | 6 | MODIFIED | Standalone documentations/mba-api-development-inventory.md removed per PM instruction — each Phase PRD's §7 now carries its own "Meta API surface & build map" slice (P1/P2/P3 → v1.5); decision + changelog references updated accordingly. |
| 1.5 | 2026-07-19 | Claude | 6 | MODIFIED | Zero-Mekari-AI-Services decision recorded (PM requirement): MBA path is wholly Qontak-owned, AI Services stays Qontak-agent-only (P2 v1.6 §5 constraint + P3 v1.6 §5 mirror). |
| 1.6 | 2026-07-21 | Claude | 6, 7 | MODIFIED | Omnichannel-AI direction recorded (vision): provider choice on the existing AI agents page + MBA as a capability-gated hand-off node (fallback port) in the Automation Flow Builder; coexistence evolves from per-number mutual exclusion to composition (OQ-4 pointer added). Lifecycle wireframe set (Onboard/Configure/Operate + HTML index) added under wireframes/. Phase 1–3 scope unchanged. |