A developer in India recently posted about the two months he spent building an AI sales agent for his family's clothing store in Jaipur.
The store runs entirely on WhatsApp. His brother was handling the same questions all day, every day — "what's available?", "my budget is 5,000 rupees, what can you show me?" — while Instagram kept sending new leads that nobody caught because his brother was already buried in the conversation.
So the developer built a system. 44 nodes. Two AI agents. Eight conversation stages. Google Sheets as the database. A vector search layer for FAQs. Customer status routing. A separate Order Booking agent that only activates when a customer is actually ready to buy.
It took two months, three major versions, and a lot of failures.
And here's the line that matters:
"The AI was not the hard part. Designing the state machine was."
Everyone focuses on the wrong layer
When most small business owners decide to use AI, they spend their energy on the model layer — which chatbot to use, which prompt to write, which tool to subscribe to. ChatGPT or Claude or Gemini. The prompt that gets better answers. The integration that hooks into their email.
This makes sense. The model is the visible part. It's what demos well. It's what you can test in five minutes.
But the model is not where AI implementations fail.
They fail at the layer around the model — the logic that decides when to invoke it, what context to give it, and what to do with what it produces.
The developer calls this the state machine. You can call it workflow logic, orchestration, business rules — the name doesn't matter. What matters is that it's the part most people skip.
What the state machine actually does
In the clothing store system, the state machine does things like:
Know who it's talking to. When a customer messages again the next day, the system knows they're a returning lead, not a stranger. It doesn't re-greet them. It doesn't ask for information it already has.
Route to the right agent. A customer mid-order doesn't get sent back to the sales agent. Someone who just texted "PP" (price please) gets routed to a price-lookup mode, not the full onboarding flow.
Know what it cannot do. The sales agent can never confirm an order. That happens in a separate agent, after the customer explicitly types "FINAL." The AI doesn't decide — the system decides when the AI can act.
Handle context switching. Real customers don't follow scripts. They ask about price mid-conversation, then go back to browsing, then ask again. The state machine knows where they are and what they need, even when they jump around.
This is not something you get from a chatbot. It's not something you get from a clever prompt. It's something you design, deliberately, before you write a single line of code or configure a single automation.
"If I were starting over, I'd draw the routing logic on paper before touching n8n at all."
Why this matters for your business
You probably don't have a 44-node n8n workflow. You might not even know what n8n is.
But the underlying lesson applies whether you're using a $20/month AI tool or building a custom system from scratch.
The question isn't "which AI tool should I use?" The question is: what decisions need to happen before and after the AI runs?
A few examples:
Customer support AI — When does a conversation get handed to a human? What happens if a customer is angry? What if they've already been contacted about this issue? The AI doesn't know any of this unless you build the logic that tells it.
Marketing AI — What makes a lead "qualified" before you invest in a follow-up sequence? What's the fallback if the AI generates something off-brand? Who reviews the output before it goes out?
Operations AI — Which tasks should the AI never do alone? When does it need a human to check its work? What's the trigger that escalates to you?
These aren't AI questions. They're business logic questions. The AI is just a component inside a process you design.
The thing the developer said that's worth sitting with
"Version 1 was embarrassing. A basic webhook that sent a canned reply. Fine for testing, useless for real customers."
Version 3 failed because there was no memory. The AI would greet the same customer every time they came back, and ask for information they'd already given.
He started over. Properly. The final system works because the business logic is solid — not because the AI is smarter.
His brother is no longer stuck on WhatsApp for hours every day.
That's the win. Not the technology. The freedom.
Before you pick a tool, answer these questions
- What is the trigger that starts the AI running? (Who sends the first message, clicks the button, submits the form?)
- What context does the AI need that it won't have automatically? (Customer history, previous conversations, current order status?)
- What should the AI never do without a human check?
- What happens when the AI gets it wrong?
- How does a conversation end — or escalate to you?
Write the answers on paper. Draw the flow. Then pick the tool.
The model is the easy part. You're ready for it once you know what goes around it.