The Bot Was Not the Hard Part

During my Ransack internship, I built a Telegram bot for a client, and the most important part was not the bot. It was figuring out what the bot was actually supposed to become.

The first request had the usual shape of real client work: a broad desire for automation, AI assistance, and easier access to workflow context, but no crisp product boundary yet. That ambiguity mattered because an AI automation can quickly become a pile of impressive parts that does not help with the daily job.

I met the client in person and tried to map the actual actions behind the request. What did they want to ask, what should be triggered, what answer would they trust, and what would make the system confusing when something went wrong?

Telegram fit the workflow because it was familiar and already part of how the client worked. Under the hood, the bot connected commands to Make.com webhooks and Make AI Agent, turning a chat message into a structured automation request rather than another dashboard to learn.

The happy path was straightforward: parse the command, call the right webhook, and return a readable response. The engineering lived in the edges — missing parameters, invalid commands, webhook failures, unclear AI output, and error messages that needed to help somebody recover instead of just announcing that the system was broken.

That was the AI engineering lesson I kept: the model is only one part of the product. The interface, parser, integration boundary, response shape, and failure handling decide whether the model feels useful or merely impressive.

The bot was the artifact. The real work was turning an unclear automation idea into a workflow that a person could understand, use, and trust when the happy path stopped being so happy.