Most bot platforms give you a flowchart. We gave the AI the tools.
For the last decade, bot platforms asked you to predict every possible customer interaction in advance. Keyword matches at the top, decision trees branching downward, hundreds of nodes mapping every edge case. It worked until it didn't—and usually that happened on a Friday when a customer asked something you didn't train the bot to handle.
We built bots differently.
How We Think About Bot Evolution
We think of bot evolution in three generations.
Gen 1: Static Bots — Keyword matching and decision trees. The bot recognizes patterns: "if message contains 'refund', go to node 47." It's brittle, requires hundreds of branches, and fails gracefully on anything unexpected. Most platforms you've used are still here.
Gen 2: RAG Bots — Vector search plus LLM. The bot retrieves relevant documents, reads them, and synthesizes an answer. This was real progress. Suddenly, bots could know things you never explicitly taught them. But they were read-only. A customer asked a question; the bot answered. It couldn't take action.
Gen 3: MCP-Orchestrated Agents — This is where we are now.
The difference between Gen 2 and Gen 3 isn't incremental. It's fundamental.
Gen 2 = Vector search + LLM. Read-only. The bot retrieves information.
Gen 3 = LLM orchestrates MCPs, Functions, and AI tools. Read + write + act. The bot decides what to do.
What Gen 3 Actually Does
Here's a real scenario:
A customer support bot is connected to a workspace with three MCPs: one for the customer database, one for order management, one for the shipping API. A user asks: "Where's my order?"
The bot doesn't follow a flowchart node. Instead:
The LLM reads the question and its available tools.
It decides: "I need to identify the customer, find their order, and check tracking."
It calls the customer DB MCP to look up the user.
It calls the order management MCP to fetch their latest order.
It calls the shipping API MCP to pull real-time tracking.
It stitches the results together and responds with tracking info, expected delivery, and relevant context.
There's no pre-built branch for "order not found" or "shipping info unavailable." The LLM handles those edge cases itself because it understands context, has access to tools, and can reason about failures.
The Flowchart Explosion Problem
Every edge case in a flowchart-based system is a new branch.
You need to handle:
Order not found
Order cancelled
Multiple orders
Shipping address changed
International delivery
Missing tracking info
Customer asking for a refund instead of tracking
That's not six branches. That's six multiplied by every combination of states. A support bot covering real edge cases becomes a tangle of nodes and branches — and it still won't handle the question you didn't anticipate.
We built a visualization of this problem:
The left side shows a traditional bot builder. Each box is a node. The lines are branches. It looks efficient at first. By the time you've handled real edge cases, it's a tangle.
The right side shows Gen 3. You write one system prompt: "You're a support bot. Your tools are: customer database, order management, shipping API. Answer customer questions about their orders." The LLM handles the routing, fallbacks, and composition.
Gen 2 was real progress — read-only intelligence. Gen 3 goes further. The bot has agency. It reads, writes, and takes action across multiple systems in a single turn.
What Gen 3 Looks Like in Practice
Let's walk through building a Gen 3 bot on Aerostack.
You start in the dashboard. You create a new bot and give it a system prompt:
You are a customer support agent. You have access to three tools:
1. Customer database MCP (read user info, lookup by email)
2. Order management MCP (list orders, get order details, cancel orders)
3. Shipping API MCP (get tracking, estimate delivery date)
When a customer asks about their order:
- First look them up in the database
- Then fetch their recent orders
- Finally pull tracking info if needed
Be concise and helpful. If you can't find something, say so.That's it. No nodes. No branches. Just a prompt and a list of connected MCPs.
Now you deploy it to Discord, Telegram, WhatsApp, Slack, and your website—all at once. Same bot, all platforms. One system prompt becomes a multi-channel agent.
A customer asks: "Can you reschedule my meeting with Sarah to next Wednesday and let her know?"
Your bot has calendar and email MCPs. It:
Checks your calendar for the meeting with Sarah
Looks up Sarah's contact email
Finds next Wednesday's availability
Reschedules the meeting
Drafts an email to Sarah
Sends it
Six tool calls. None of them hard-coded in this order. The LLM composed it because it understood intent, had the right tools, and could reason about what needed to happen next.
Try that with a flowchart. You'd need at least a dozen nodes.
Multi-Platform by Default
This is where Gen 3 becomes valuable at scale.
You build one bot. It runs on Discord, Telegram, WhatsApp, Slack, and your website. Same tools. Same prompt. Same behavior.
In Gen 1 and Gen 2, every platform had different quirks. Telegram's limits, Discord's permissions, Slack's interactive elements—you'd adapt the flowchart or write custom logic for each one.
Gen 3 doesn't care. The LLM drives the behavior. The platform adapter just shuttles messages in and responses out. Your bot is platform-agnostic because the intelligence is at the LLM layer, not the flowchart layer.
You maintain one bot definition, one workspace, and deploy to five channels.
The Read-Only Wall
This is the limitation that pushed us past Gen 2.
RAG bots are great for Q&A. But the moment a user says "Great, now can you update my record?" — the bot hits a wall. It can read. It can't write.
The workaround is always the same: either hard-code a function for that one specific action, or fall back to a human. Either way, you lose the point of having an agent.
Gen 3 removes the wall. The bot has MCPs for both read and write operations. It decides when to use each. A user asks for a refund. The bot reads the refund policy, checks if they qualify, submits the refund, and sends a confirmation email. No human in the loop. No custom code per scenario. The LLM composed the sequence from available tools.
If you've used a flowchart bot platform, think back to the last time you hit a wall — the question the bot couldn't handle, the action it couldn't take, the edge case that required a new branch. Gen 3 bots hit that wall less often because they're not following a predetermined path. They're reasoning about what to do next with the tools they have.
Tomorrow: confidence routing — how to stop paying for expensive LLM inference on questions a smaller model can handle.
