Over the past two weeks, I've been working on a proof-of-concept that I believe highlights the direction in which many AI features will be developed in the future: by integrating with platforms users already frequent daily, rather than trying to draw them to ours. This project involves users interacting with an AI agent directly through WhatsApp, leveraging the platform they already know and use extensively.

The concept is simple: a user opens WhatsApp, sends a message, and receives a reply from an AI agent that has contextual knowledge about their community. The agent can search for members, suggest events, and answer questions about people they should meet, all without requiring an app installation, password entry, or additional tabs. Essentially, it's just WhatsApp.

Choosing WhatsApp over developing an in-app chatbot was a deliberate decision. Although we could have easily integrated a chat feature within our existing web and mobile apps, that would have been a misstep. The friction with in-app AI is not the AI itself but the need for users to navigate to the app. People open WhatsApp over 30 times a day, while most other apps are accessed only once or twice. The key benefit of conversational AI is immediacy — you type something, and you get an answer. This immediacy is lost if users have to navigate to a different tab first.

The architecture of the system is straightforward:

WhatsApp → BSP (Twilio) → our backend → OAuth/auth layer → AI service → LLM

Each component in this chain plays a crucial role:

The BSP: Access to the WhatsApp Business API is through a Business Solution Provider, like Twilio in our case. The BSP manages the WhatsApp protocol while we handle the business logic. We set up sub-accounts under one parent to keep testing, EU production, and US production isolated in terms of billing.

The Meta Business Account + WhatsApp Business Account: This forms the gateway. Even with a BSP, a Meta Business Account and a WhatsApp Business Account are necessary. Verification can take days, and without these accounts, we can only use a Twilio sandbox number for development. It's important to plan for this lead time.

Inbound webhook security: We've implemented two layers of security: a URL-path token to make the webhook URL unguessable and an HMAC-SHA1 signature validation on every request. Twilio signs each webhook with our auth token, and we verify before processing. Skipping these steps would leave us vulnerable to security issues where anyone could send fake messages.

Auth-via-linking: This is the part I'm most proud of. Rather than matching phone numbers, which can be insecure due to potential theft or recycling, we use a 5-minute one-time "linking phrase." After the user authenticates normally, they send this phrase from their phone to our WhatsApp number. Our backend matches the phrase to the authenticated session, creates an OAuth refresh token bound to that channel, and saves the binding. From then on, every WhatsApp message from that user is recognized, maintaining their usual access controls.

Memory + LLM loop: Conversation history is stored in a JSONB column on the channel record, trimmed to about 20 turns with a 30-minute TTL. This full history is sent to the LLM with every call, keeping the LLM stateless. The agent loop can run up to N iterations, engaging in tool-use cycles like searching peers or finding events.

The cost economics of this system are reasonable, making it viable as a paid feature. Each WhatsApp message conversation costs about €0.005, and phone numbers cost a few dollars monthly. While these costs aren't significant individually, they do add up at scale. Therefore, a tiered billing model might be appropriate:

For a free tier, a small fair-usage limit per community could allow users to experience the value without impacting marketing budgets significantly. For a paid tier, we could offer either a pass-through with a small margin or a flat-rate "premium engagement channel" SKU. People are often willing to pay for convenience, and we're reducing interface friction, so charging for this feature seems fair.

Reflecting on the project, there are a few things I'd do differently next time. First, designing the authentication system should take precedence over other elements. The auth design influences everything downstream, from data access to account deletion processes. Additionally, it's crucial to avoid building channel-specific tools. All tools should communicate with the auth layer, not the channel, to maintain adaptability across different platforms. Lastly, the per-message overhead is considerable. Every inbound message refreshes a token, makes an LLM call, and may hit a search index or write back through the API. Planning for this overhead from the start is important, and integrating async processing early on simplifies future scalability.

We're transitioning from "AI as a feature" to "AI as a different way to access existing features." Most of what I developed isn't groundbreaking AI; it's an authentication chain, a webhook handler, and a tool-use loop wrapping our existing APIs. The real novelty lies in the channel. Today it's WhatsApp, tomorrow it might be SMS or RCS for US users, or another platform that emerges. The pattern remains: select the platforms your users are already on and build a thin adapter to expose your product through it.

If you're developing something that requires users to come to you, now is the time to question whether they really need to.