Key takeaways
- A shared model does not create shared business context.
- Identity and consent must be resolved before private memory is used.
- Each channel needs its own format and compliance rules without changing company truth.
- One durable workflow should own the promise across every handoff.
Why channel-specific automation creates contradictions
A voice bot may know one price list, a WhatsApp flow another, and an email assistant a third. Even when all three use the same language model, separate prompts and separate customer histories can produce different answers.
The customer experiences one company. The architecture must therefore connect every channel to the same approved business state while still respecting the communication rules of that channel.
The context assembly before every interaction
Before speaking or sending, the employee should compile a fresh, bounded context packet for the exact customer, thread, purpose, and workflow step.
A safe packet includes only what is relevant and permitted. It should carry evidence references, freshness, consent, the current employee role, the workflow entry point, available tools, and an expiry. Unknown contacts remain in safe intake until identity is verified.
- Resolve tenant, employee, channel, customer, thread, and purpose.
- Read current consent, do-not-contact state, policies, and customer promises.
- Retrieve the smallest sufficient set of cited facts.
- Select the allowed workflow path and channel behavior.
- Bind tools, budgets, approvals, and expiry before model or provider use.
One meaning, different expression
Consistency does not mean copying the same sentence everywhere. A phone response should support interruption and natural pacing. WhatsApp should be concise and conversational. SMS should respect length and consent. Email can carry more detail and structure.
The company facts, promise, and decision stay aligned while the channel compiler changes format, timing, and interaction style.
The workflow, not the inbox, owns the commitment
Suppose a customer asks for an appointment by phone and later sends a document on WhatsApp. The employee should resume the same mission rather than create two unrelated conversations. The booking state, required evidence, pending approval, and next action belong to one durable workflow.
Every customer-visible side effect needs an idempotent receipt so retries cannot create duplicate bookings, messages, or charges.
Where the owner remains in the loop
The system should ask before unusual pricing, sensitive promises, refunds, policy exceptions, or other decisions the owner has reserved. The escalation should contain the customer context, options, evidence, urgency, and the exact action waiting to resume.
This makes human approval part of the workflow rather than an emergency handoff that loses context.
Clear answers
Frequently asked questions
Can one AI employee handle both calls and WhatsApp?
Yes, provided both channels use the same customer identity, approved company knowledge, workflow state, and permission system while preserving channel-specific rules.
What happens when the customer switches channels?
The new interaction should resolve the existing customer and mission, then compile fresh context from the latest approved state and open commitments.
Should all customer history be sent to the AI model?
No. Only purpose-relevant, permitted, cited, and fresh context should be included, within explicit source and token limits.
Make it operational
Start with one role, one workflow, and a clear owner boundary.
Founder 50 is a handheld path from business context to a supervised first employee. No prompt engineering or workflow canvas required.