Chat-Man Proposes Shared WhatsApp Access for AI Agents

Fabian introduced Chat-Man on Hacker News on September 16, 2026, as a shared way to give AI agents access to WhatsApp without wiring in a separate WhatsApp library for each new project Hacker News.

The post describes a WhatsApp MCP server, a connector that lets an agent programmatically read, search, extract and send messages, plus a web UI built for non-technical users. The announcement points to https://chat-man.net.

It also says the system can receive webhooks, automatic alerts for incoming messages, for starred conversations only. That is the extent of the public claim. The idea is reuse.

From a builder's perspective, the appeal is easy to see. Each project today tends to redo the same work around session handling, which means keeping the WhatsApp login alive, parsing message formats, and managing the send path. A shared server would move that work behind one stable tool boundary. Agents would call read, search, extract and send. The server would own the WhatsApp specifics.

In my view, those four verbs matter more than they first appear. Read and send cover transport, moving messages in and out. Search and extract treat past conversations as a store that can be queried, which matches how agents actually use messaging. They rarely need every message as it arrives. They need to find an earlier answer, pull out an address or order detail, and act. Keeping those steps as separate, testable tools keeps the instructions to the model simpler.

The broader context here is how agents hear about new messages. Agents that only check on a schedule, by polling, can miss timely prompts. Agents connected to everything get flooded with noise and take on wider access than they need. Limiting automatic alerts to starred conversations keeps the opening small. Starring works as access control and attention control at once, set by the user rather than guessed by the model. It is the same explicit-subscription pattern used in many notification systems, where clear choice beats guesswork when reliability matters.

Worth flagging is the two audiences implied by the design. The MCP server serves developers. The web UI serves operators, account owners or others who will never write a tool call. That split often decides whether an agent survives daily use. Someone has to connect the account, star the right threads, check what was read or sent, and step in when the agent misreads a message. Putting those controls outside the chat window keeps the agent accountable to people who do not work in code.

For teams weighing real-world use, familiar questions remain unanswered in the announcement. They cover who holds login credentials, how sessions are kept separate, how long messages are kept, and exactly how webhook delivery behaves. They do not need answers for an early release. They will decide fit for anything beyond testing, especially where WhatsApp carries sensitive personal or customer conversation.

What this approach could enable, if those answers hold up, is less custom glue work and more focus on behavior. WhatsApp is where many practical conversations already happen. Meeting agents there, with limited alerts and searchable history, would remove an integration cost now paid on every project. On paper that is a small saving. Across many teams, it is how agent tooling stops being one-off craft and starts becoming infrastructure.