Most AI companion products are self-contained apps. You download, you chat, everything happens inside their walled garden. But a growing subset of the market takes a different approach: building AI companions that live inside existing messaging platforms like WhatsApp and Telegram.
This architectural choice introduces a completely different set of engineering challenges. Here is what it actually looks like under the hood.
Why build on messaging platforms
The user experience argument is straightforward: people already live inside their messengers. Meeting users where they are, instead of asking them to download another app, reduces friction and increases engagement.
But there are also technical advantages. Messaging platforms handle the entire client-side stack — UI rendering, push notifications, media delivery, offline queuing. Instead of building and maintaining native apps for iOS and Android, you build a backend that communicates through messaging APIs.
The trade-off is control. You cannot customize the chat UI, you are subject to the platform's rate limits and content policies, and you depend on third-party API stability.
The WhatsApp integration landscape
WhatsApp offers two integration paths, and they serve very different use cases.
The official WhatsApp Business API (through Meta's Cloud API) is designed for businesses sending notifications and handling customer service. It requires business verification, enforces template-based messaging for outbound messages, and charges per conversation. It is not designed for AI companion use cases and the content policies would likely flag this type of application.
The alternative is unofficial API providers. Services like Green API or Evolution API provide WhatsApp integration through web client automation or multi-device protocol implementation. Green API operates as a cloud service — you get an API endpoint, send messages, receive webhooks. Evolution API is self-hosted — you run the infrastructure, which gives more control but requires DevOps work.
The architectural pattern for either approach looks like this:
User sends WhatsApp message to the AI number. The API provider receives it and sends a webhook to your backend. Your backend processes the message through the AI pipeline (orchestration, model inference, memory lookup, response generation). The response is sent back through the API provider to the user's WhatsApp.
Latency management is critical here. WhatsApp users expect near-instant read receipts and responses within seconds. The AI pipeline — especially if it involves multiple model calls — can take 3-10 seconds. Solutions include sending read receipts immediately (before processing), showing "typing" indicators during generation, and streaming responses where the API supports it.
Telegram's bot API
Telegram is more developer-friendly for this use case. The Bot API is official, well-documented, free, and explicitly supports conversational bots.
But for AI companions that need to feel like real contacts rather than bots, some platforms use user accounts through libraries like GramJS or Telethon instead of the Bot API. A user account can have a profile picture, status, and appears in the regular chat list rather than being marked as a bot.
This approach is technically against Telegram's terms of service for automated usage of user accounts, but it is widely practiced. The risk is account suspension, which means having backup accounts and rotation strategies.
The state management challenge
Messaging platform integrations are inherently stateless from the API perspective. Each webhook is an independent HTTP request. But AI companion conversations are deeply stateful — you need to track conversation history, character state, memory, and ongoing context.
The standard architecture uses Redis for hot state (current conversation context, recent messages, active session data) and PostgreSQL or similar for cold state (long-term memory, user profiles, conversation archives).
Each incoming message triggers a pipeline: load hot state from Redis, enrich with relevant cold state from database, run through AI pipeline, update state, return response. The entire cycle needs to complete within the messaging platform's timeout window.
For a platform handling thousands of concurrent conversations, the state management layer is often the bottleneck. Each conversation maintains its own context window, memory index, and character state. Multiplied by thousands of active users, this requires careful memory management and connection pooling.
Proactive messaging architecture
One of the most interesting engineering challenges in messenger-based AI companions is proactive messaging — having the AI reach out to the user without being prompted.
This requires a scheduling system that evaluates when and whether to send a message to each user. Factors include: time since last interaction, time of day in the user's timezone, conversation momentum (was the last exchange engaging or winding down), and character personality (some characters are more initiating than others).
The scheduler typically runs as a separate service, scanning active conversations on a regular interval and queuing proactive messages that pass the evaluation criteria. Rate limiting is essential — too many unprompted messages becomes spam.
This is where the experience diverges significantly from app-based companions. The AI feels like a real contact in your phone because it behaves like one — messaging when it has something to say, not just when you open an app.
The scaling economics
Running AI companions on messaging platforms has a different cost structure than app-based products.
You save on: mobile app development and maintenance, push notification infrastructure, client-side media handling, app store fees (15-30% on in-app purchases).
You spend on: messaging API costs (Green API charges per instance), model inference (unchanged), state management infrastructure, compliance with messaging platform policies.
For early-stage products, the messenger approach is significantly cheaper to launch. No app review process, no client-side bugs across hundreds of device configurations, no app store politics. Ship a backend, connect it to a WhatsApp number, and you are live.
For scale, the economics depend heavily on the messaging API pricing model and your inference costs. The companies getting this right are using cost-efficient models (DeepSeek and similar) for the majority of messages and reserving expensive models for high-complexity interactions.
The messaging-native approach to AI companions is still early. But the engineering patterns are maturing fast, and the user experience advantages are real. If you are building in this space, it is worth evaluating whether you really need your own app — or whether the messenger is the app.
Top comments (0)