How to programmatically enable/disable or restart Meta AI Agent replies per thread using Baileys?

[phoenix-nproduction]

Hi everyone,

I am trying to programmatically toggle or restart the Meta AI Business Agent (also known as Meta AI Business Assistant / MAIBA) for specific chat threads on a WhatsApp Business account.

Our goal is to pause the AI replies when a human agent takes over the chat (human takeover), and then re-enable/reactivate the AI replies when the human agent is finished (equivalent to the WhatsApp Web context menu feature "Restart AI replies").

I have inspected the Protobuf definitions in @whiskeysockets/baileys (WAProto.proto) and noticed a few relevant fields:

1. maibaAiFeaturesControlAction (SyncActionValue field 68)
2. maibaAiThreadEnabled (Conversation field 54)
3. AI_HANDOFF in LabelEditAction

What we have tried

We tried using appPatch with the index key 'maiba_ai_features_control' (matching IndexMaibaAIFeaturesControl from other Go implementations like whatsmeow):

await sock.appPatch({
    syncAction: {
        maibaAiFeaturesControlAction: {
            aiFeatureStatus: 0 // ENABLED = 0 (or 1 for DISABLED)
        },
        timestamp: Date.now()
    },
    index: ['maiba_ai_features_control', targetJid], // We also tried global: ['maiba_ai_features_control']
    type: 'regular',
    apiVersion: 1,
    operation: 0 // SET
});

Result: The appPatch request is sent successfully via WebSocket without throwing any errors, but it does not actually affect the state of the Meta AI replies on the physical WhatsApp Business device. The AI agent replies do not turn on/off.

Our Current GraphQL Fallback (that works)

Currently, we have to fall back to an HTTP request mimicking WhatsApp Web's graph query:

POST https://graph.facebook.com/graphql
Doc ID: 27506359585667043
Variables: { consumer_lid: "...", phone_number: "...", thread_status: 'ENABLED' }

While this HTTP approach works, it requires extracting an ephemeral, short-lived access_token from an active WhatsApp Web session, which makes it unstable for fully headless backend automation.

Questions:

1. Has anyone successfully toggled or restarted Meta AI replies natively via Baileys using WebSocket/Protobuf updates?
2. What is the correct way to construct the appPatch for maibaAiFeaturesControlAction or update maibaAiThreadEnabled in Conversation?
3. Do we need to send a specific stanza/node or utilize AI_HANDOFF to properly trigger the AI activation/deactivation on WhatsApp servers?

Any guidance, example code, or insights on how to reverse-engineer this sync action would be highly appreciated!

[yudin-s]

I would separate two things here: Baileys knowing the protobuf shape, and WhatsApp accepting that change as an authoritative server-side control.

The fields you found are real in WAProto.proto, but that only means Baileys can encode/decode that part of app state. It does not necessarily mean a client can toggle MAIBA by sending an arbitrary appPatch. In particular:

• maibaAiThreadEnabled on Conversation looks like replicated conversation state. Updating the local app-state copy is not the same as asking WhatsApp's server to restart AI replies.
• maibaAiFeaturesControlAction is present as a sync action value, but the correct app-state collection, index tuple, version/MAC handling, and server-side permissions still have to match what WhatsApp Web sends.
• AI_HANDOFF is a label type, so I would not expect it by itself to trigger the Business AI control flow.

The fact that your WebSocket patch is accepted without error but the physical Business device state does not change is a strong signal that this is not the complete control path, or that the server treats it as a non-authoritative replicated patch.

Your GraphQL fallback is probably closer to the actual product operation because it is the endpoint WhatsApp Web uses for the Business AI feature. I would not replace that with Baileys until someone captures the exact WhatsApp Web operation and maps it to a Baileys-supported send path.

For reverse-engineering, I would test in this order:

1. Capture the network/app-state traffic from WhatsApp Web while clicking "Restart AI replies" for one known thread.
2. Check whether it sends only the GraphQL mutation, or whether it also writes an app-state patch afterward.
3. If there is an app-state patch, copy the exact collection/index shape and action payload. Do not infer the index from the proto field name alone.
4. After sending with Baileys, fetch/sync the same thread from a second client and verify whether the server state changed, not just whether the socket write succeeded.

So the short answer is: I do not think maibaAiThreadEnabled can be safely treated as a direct Baileys toggle today. The stable implementation should keep using the product operation you already found, or wrap it behind a session-refresh layer, until Baileys has a confirmed helper or a tested low-level example for this specific MAIBA action.

If this distinction matches what you are seeing, please mark the answer so others do not spend time on a protobuf-only patch that the server ignores.

[phoenix-nproduction]

Thank you so much for the detailed and insightful explanation!

Your point about separating the protobuf shape (which is just replicated state) from the authoritative server-side control makes perfect sense. It completely explains why my appPatch request is accepted silently by the WebSocket without actually affecting the AI agent's behavior on the physical device. I was likely just updating a local copy of the state rather than sending the actual command.

It seems highly likely that WhatsApp Web relies entirely on that GraphQL mutation as the main trigger. Based on your recommendations, my next steps will be:

1. Sticking to the GraphQL fallback for now and building a more robust session-refresh layer to handle the access_token lifecycle.
2. Inspecting the WhatsApp Web traffic more closely to see if an appPatch is only sent after the GraphQL mutation just to sync the UI/local state.

I've marked your response as the answer so others know not to go down the same protobuf rabbit hole. Thanks again, I really appreciate your answer.