Everything this guide builds is available as a ready-made flow — clone it and adjust instead of starting from scratch.
Open the templateAsk an AI agent to build you a Telegram bot and it will: write the handler, wire up the webhook, ship it. Most "AI builds your bot" demos stop right there, at the moment the code compiles, as if that were the finish line.
It isn't. The finish line is where someone who didn't write the prompt has to trust the thing with real customers. Code doesn't get you there. A canvas does.
We build a visual flow editor, so for about a year we watched the "agents replace interfaces" story with the obvious professional anxiety. Then we shipped an AI flow assistant and an MCP server so agents could build inside FlowCastle — and the story flipped.
Agents didn't replace the canvas. They became its most prolific users. What changed is who drags the steps around, not whether the steps need to exist.
Two things "the agent just builds it" assumes
That you can read the code. Fine if you wrote the prompt and read that language fluently. Plenty of people building bots don't — and the ones who do don't want to be the only person on the team who can open "the lead qualification bot" and say what it actually does. A generated if-chain across a few hundred lines isn't self-documenting just because a model wrote it instead of a person.
That it will do the same thing twice. Ask again with a slightly different prompt, or a different model, and you can get materially different branching — with nothing to diff, because there was no artifact. Just two independent generation runs. Tolerable for a one-off script. Bad for something that runs unattended against paying customers for months, gets "improved" by a second prompt three weeks later, and hands off to a teammate who joined after both.
Neither problem is about intelligence. Reasoning-model output can be excellent and still be undebuggable at 2am by someone else — because "debuggable" isn't a property of how smart the author was. It's a property of the artifact.
What the assistant actually hands you
A plain-language brief goes in:
A real flow comes out — not a paragraph describing one:
Welcome message, a branch on what the visitor wants, lead capture with named variables, a booking step, a fallback. Steps you can click into.
The mechanics are identical when an agent drives through the MCP server: read the current structure, fetch the design guidelines and worked examples, then propose a change. Every edit is validated against the same schema the visual editor enforces before it touches your flow. An agent cannot:
- invent a template function the runtime doesn't have
- reference a variable that was never created
- leave a branch with no destination
The write is rejected — not silently accepted, then discovered by your first real user. The assistant proposes; the schema decides.
So what lands is a draft, ready for the review you'd give a junior teammate's work. Does the fallback make sense? Is the booking step asking for the right fields? Does this sound like the business it's for?
You answer those by looking at a flow, not by reading a diff of generated TypeScript. Here's the editor end to end:
What the agent doesn't hand you
A correct-looking draft is not a working system. The gap between them is mostly boring infrastructure with nothing to do with how good the model is:
- Rate limits. Telegram caps bots on several axes at once — roughly 30 messages a second across different chats, about one a second into any single chat, slower still into groups. "Send this to everyone who clicked" doesn't respect that unless something in the execution path enforces it.
- Payments. They have to reconcile with a provider and survive retries without double-charging anyone.
- Broadcasts. Four thousand sends that fail partway through need a delivery ledger, not a best-effort loop.
None of this is where models are weak. It's where "the agent wrote the logic" and "the system is production-grade" quietly stop being the same claim. That infrastructure lives in the runtime underneath the flow — not in anything either of you reasons about turn by turn.
Should the agent just run the show?
The strongest counter-argument isn't "AI-generated code is bad". It's a real design choice: skip the fixed flow entirely and let an agent decide live, per message, what to say next. We didn't build our AI reply step to fight that — a flow can call a model at one specific point, for exactly the open-ended stretch of a conversation. That pattern is worked through in our guide to building an AI support bot.
| Let the agent decide live | Draw it as a flow |
|---|---|
| Open-ended support conversations | Refunds, paywalls, compliance answers |
| Research and summarising | Anything the business must guarantee |
| A response space too wide to draw | Cost and latency at scale |
| Low stakes if it improvises | Handoff to people who never wrote it |
That last row is the one that bites. Six months in, when the person who wrote the original prompt has left and support is three people who never touched it, "ask the agent what it does" is not an audit process. A flow you can open and read is.
The answer isn't "never let the agent decide". It's make the AI step legible as a step — bounded, visible on the canvas as one node among others, inside a graph a human can still read end to end.
Where this breaks down
- Review only works if someone actually does it. An AI draft that gets rubber-stamped without anyone reading the branches produces the exact unaccountable outcome the canvas was supposed to prevent. The artifact was readable; nobody read it.
- We learned that one the hard way. An early AI-assisted build grew past two dozen steps on a single canvas before we added rules pushing the assistant to split large flows into linked sections. The canvas didn't catch it — it just made the mess visible enough that we did.
- A canvas has a ceiling that code doesn't. Which is why ours has an escape hatch: an HTTP-request step, and a sandboxed custom-code step with access to your flow variables — rather than pretending every bot fits as boxes and arrows.
- Visual isn't automatically simple. A large, deeply branched flow is its own kind of hard to read. That discipline stays with whoever builds it.
The canvas is the audit trail
This isn't an argument against AI writing automation. Ours writes plenty of it — that's the point, not a hedge.
It's an argument about what form automation has to take once a real business depends on it: something a second person can open cold and understand, something you can diff against last week, something where an invalid change is caught by a schema instead of by a customer.
Code an agent writes for itself doesn't have to satisfy any of that. Automation an agent hands to a team does. That's the bet behind wiring an assistant and an MCP server into a visual builder instead of a chat window.
If you're weighing platforms on exactly this, our comparison of Telegram bot builders covers where each one sits.