How a WhatsApp Side Project Became OpenAI's Newest Agent Bet

In January 2025, a developer named Peter Steinberger published a side project on GitHub. He had wired WhatsApp to an AI agent so he could text it tasks and have them completed without opening a browser or an app. Manage the inbox. Book a restaurant table. Adjust the smart home settings. The key detail was that the agent completed these tasks end to end rather than answering with suggestions. He called it Claudebot and shared it openly. Within days it had 201,000 GitHub stars, more than two million unique visitors in a single week, and had become the fastest growing open source project in GitHub history.

I am Madhuranjan Kumar. The reason I cover that story is not the numbers, though the numbers are remarkable. It is what the numbers say about appetite. People did not respond that way to another chatbot or another demo. They responded that way to something that did work for them, and that appetite tells you something concrete about where business automation is going and what to build next.

This piece is a practical playbook for setting up the same kind of agent capability for a real business task, based on what the OpenClaw project demonstrated works and what the security incident it triggered demonstrated goes wrong. The steps below are named for the concrete decisions involved, not generic stages.

Connect a messaging channel to a model that executes actions, not one that only replies

The distinction between an agent and a chatbot is not the model. It is what happens after the model produces a response. A chatbot produces text. An agent takes an action in a real system based on what the model decided: books a slot in a calendar, updates a row in a spreadsheet, sends a confirmation message, creates a ticket in a project tool. The messaging channel is where the human inputs the request. The action layer is where work actually gets done.

For a business starting with this setup, the messaging channel is almost always a phone-based app the team already uses for customer communication or internal coordination. WhatsApp and SMS are the most common for small businesses because that is where customers already are. The model is chosen based on what the task requires. For most business automation tasks, booking, follow-up, status checks, information retrieval, the reasoning requirement is modest and a capable mid-tier model handles them well.

The business case for this layer is what OpenClaw demonstrated at scale. Two million people in a week did not discover that an AI could answer questions. They discovered that an AI could handle something they would otherwise have to do themselves, and they responded with immediate, intense interest. For a business, the same dynamic shows up as bookings captured after hours, inquiries answered in seconds, and follow-ups sent consistently without requiring a staff member to remember to do them.

Wire the agent to exactly the tools your chosen first task requires, nothing more

The scope of what an agent can access should match the scope of the first task you are assigning it, not the scope of everything you eventually want it to do. This is the most common place where the setup gets complicated before it needs to be. An agent wired to every tool in the business stack from day one is harder to test, harder to debug, and introduces more risk than an agent wired to the two or three specific tools the first task actually needs.

For a business that wants the agent to handle after-hours booking inquiries, the tools required are the calendar or scheduling system (to check availability and write new bookings), the messaging channel (to read incoming requests and send confirmations), and possibly a contact record system to log the interaction. That is a narrow, well-defined integration surface. The agent can be fully tested on that surface in a closed environment before it handles any real customer interaction.

The second task, whether that is invoice follow-up, review requests, or something else entirely, gets wired after the first task is running cleanly without any manual intervention. This constraint matters because each new tool integration introduces a new failure mode and a new credential to manage. Keeping the scope narrow at the start keeps the system understandable and keeps the failure modes visible and correctable before they compound.

For a plumbing business, the first task might be after-hours booking capture. A customer texts the business number at 9pm reporting an emergency. The agent reads the message, identifies the urgency, checks the dispatcher's calendar for available emergency slots, offers the next two options, books the one the customer selects, sends a confirmation with the technician's name and arrival window, and logs the job. No staff member is needed. The revenue that would previously have gone to voicemail is captured. That is the complete first task, and it is narrow enough to test properly in a closed session before going live.

Lock down authentication before the agent touches any live service

The OpenClaw security incident is the clearest available demonstration of what happens when this step is skipped. Researchers found more than 30,000 instances of the tool running online with no authentication protecting the interface. Each exposed instance was leaking email access, calendar access, Slack messages, and API credentials from the connected services to anyone who could find it. Gartner called it an unacceptable cybersecurity risk. Madhuranjan Kumar spent significant time and effort managing the fallout. The security failure was not in the model or in the task logic. It was in the deployment: the tool was made accessible on the public internet before authentication was in place.

For any business deploying an agent that connects to real services, authentication has three layers that all need to be closed before the agent handles live interactions. The first layer is the interface itself. The endpoint the agent listens on for incoming messages must require authentication so only authorized senders can reach it. For a WhatsApp or SMS channel, the messaging platform's webhook verification handles this at the platform level, but it still needs to be configured correctly. For a web interface, a session token or API key requirement on the listening endpoint is the minimum.

The second layer is the agent's access to the tools it calls. Every integration, calendar, CRM, email, messaging system, uses credentials that must be stored in environment variables on the server, not in the code itself. Code gets shared, cloned, put in version control, and read by people who should not have the credentials. Environment variables stay on the machine that runs the agent. This one habit, credentials in .env, never in code, is the difference between a shareable codebase and a security incident waiting for the first repository clone.

The third layer is the boundary on what the agent is permitted to do within each connected system. An agent wired to a calendar should be able to read availability and write new bookings, but it probably should not be able to delete existing bookings or access other users' private calendars. Configure the narrowest possible permission scope for each integration and the blast radius of any compromise is limited to what the agent was actually authorized to do.

Run the first task in a closed test for one week before pointing it at real customers

The week of closed testing before going live is not optional for a workflow that touches real customer interactions. It is the step where the failure modes that only appear on real input show up in a safe context rather than in a live booking conversation.

During the closed test, route representative inputs through the agent manually and review every output before it would go to a customer. The inputs that cause the agent to produce a wrong or confusing response are the ones you need to find now, not after the first real customer gets a garbled confirmation. Common issues that show up in closed testing: the agent handling ambiguous messages in an unexpected way, the calendar integration returning availability windows in a format the agent does not parse correctly, the confirmation message containing information that is slightly off because the agent misread part of the booking request. These are all fixable, but they are much easier to fix before the workflow is live than after.

The closed test week also establishes the baseline you compare against after going live. How often does the agent produce a correct booking with no intervention? What share of the test inputs required a manual correction? If the agent needs a human to check one in five bookings during closed testing, it is not ready to run unsupervised against real customers. If it handles 19 out of 20 test inputs correctly and the one failure is always the same edge case, you fix that edge case, run another test batch, and check again before going live.

The OpenClaw story is instructive here not just for the security incident but for the speed of deployment that made it possible. The project went from side project to the fastest growing repository in GitHub history in days. That speed is part of what made it remarkable. It is also part of what created the conditions for a large number of users to deploy it insecurely before proper hardening guidance was in place. For a business deploying an agent to handle real customer interactions, the goal is not to be first. The goal is to be right and then to be fast.

Add the second task only after the first runs a full week with zero manual interventions

The criterion for expanding the agent's scope from one task to two is not that the first task is mostly working. It is that the first task is running for a full week with no manual interventions required and no error cases that a human had to catch and correct. That is a higher bar than it sounds, because the early days of any agent workflow tend to surface edge cases that the testing phase did not catch. A real customer asking an ambiguous question, a booking request that arrives in an unusual format, a calendar state the agent has not seen before: these situations show up when the input set is real and unpredictable rather than a curated test batch.

Once the first task clears that bar, the second task gets scoped the same way: one specific workflow, one narrow set of tool integrations, one week of closed testing before it goes live. For the plumbing business, the second task might be the invoice follow-up sequence. The agent sends a polite reminder at the three-day mark after a completed job, a second reminder at seven days for unpaid invoices, and a more direct message at fourteen days. Each of those messages is templated and reviewed during the closed testing week. When it goes live, it runs automatically on every completed job without requiring a staff member to track which invoices are outstanding and how many days old each one is.

The compounding nature of this build is what the OpenClaw project demonstrated at a viral scale, and what a business adding one task per month demonstrates over a year. For a business running Facebook and Instagram ad campaigns, an agent that automatically follows up on every inbound lead within seconds can double the conversion rate on the same ad spend without changing the targeting or the creative. Each new automated task recovers time, captures revenue that would otherwise be missed, or ensures a customer interaction that would previously have been inconsistent is now consistent. The CRM and website stack that connects these workflows together grows more capable with each addition, and the compound effect on how the business operates becomes increasingly visible by the second and third quarter.

Peter Steinberger went from a WhatsApp side project to a GitHub phenomenon to a job at OpenAI focused on building personal agents for mainstream users, all in a matter of months, because the underlying idea was right. People want an assistant that completes real work on their behalf. That appetite exists at every scale, from a solo service business to a major software platform. The businesses that build toward it carefully, starting narrow and adding scope only after each layer is working reliably, are the ones that end up with an agent that handles meaningful work without the oversight that an insecure, over-scoped deployment requires. Start with one task. Lock down the credentials first. Test before going live. Then build from there.