I co-founded NxFlowAI, an AI automation agency. These boundaries apply whatever you build with.

When a small business asks a developer to "just add a chatbot", the first version is easy. The trouble starts when the bot needs to do something other than talk. This post maps five boundaries I see repeatedly, the line where off-the-shelf chatbots end and custom AI begins. For each one: what the hosted bot usually gives you, what the business actually needs, and a payload sketch.

1. Write-back with idempotency

Hosted bots often "sync to CRM" with a fire-and-forget webhook. The business needs exactly one lead record per person per enquiry, even when webhooks retry.

{ "event": "lead.upsert", "idempotency_key": "wa:+00000000000:2026-10-05T09:14", "match_on": ["phone_e164"], "fields": { "source": "whatsapp", "intent": "booking", "next_action_at": "2026-10-05T12:00:00Z", "owner": null } }

If your integration cannot express idempotency_key and match_on, retries create duplicates, and duplicates create two staff members calling the same customer.

2. Identity across channels

The same customer writes on Instagram, then emails, then calls. A hosted bot sees three strangers. The business needs one person.

{ "person_id": "p_123", "identities": [ {"channel": "instagram", "handle": "@example"}, {"channel": "email", "address": "someone@example.com"}, {"channel": "phone", "e164": "+00000000000"} ], "merge_policy": "manual_review_if_conflict" }

Note manual_review_if_conflict. Automatic merges on fuzzy matches are a quiet source of data loss.

3. Approval state

Hosted bots are built to finish conversations. Businesses need some messages to pause for a person.

{ "draft_id": "d_456", "channel": "whatsapp", "text": "Yes, we can do 10 units at the standard price.", "policy_flags": ["mentions_price"], "state": "awaiting_approval", "approver_role": "owner", "expires_at": "2026-10-05T18:00:00Z", "on_expiry": "notify_backup_approver" }

expires_at and on_expiry matter more than the model. An approval queue nobody watches is worse than no queue.

4. Long-running state and timers

"Follow up tomorrow if they have not replied" is a timer that outlives the conversation. Hosted bots typically reset when the chat ends.

{ "workflow": "quote_followup", "lead_id": "l_789", "steps": [ {"at": "+24h", "if": "no_reply", "do": "draft_followup", "approval": false}, {"at": "+72h", "if": "no_reply", "do": "assign_to_owner", "approval": false} ], "cancel_on": ["reply_received", "deal_closed"] }

On WhatsApp, also remember that messages outside the 24-hour customer service window require approved templates, so the follow-up step must know which mode it is in.

5. Business-outcome observability

Hosted bot dashboards report conversations, deflection and satisfaction. The owner wants to know: did leads get an owner, did quotes get chased, did anything silently stop?

{ "metric": "leads_without_owner_older_than", "threshold_minutes": 60, "alert": {"channel": "email", "to": "ops@example.com"} }

If you cannot alert on the business outcome, you will find out about failures from customers.

So, buy or build?

If a business only hits boundary 1 at a basic level, a hosted bot with a decent integration is fine. Once it needs 3 and 4 together (approvals plus timers across its own systems), you are building a workflow with a chat front end, and it is usually cleaner to design it that way from the start. Either way, do the mapping first; our owner-friendly workflow audit guide covers the non-technical half. Our own first audits take 72 hours.