System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.2
Primary Location: MCR
Future Operational Destination: AIBS Brain, Customer Brain, Sales Brain, Automation Brain, Data Brain, Client AIOS Systems
Parent Page: AIBS Brain
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-21
Source / Origin: MWMS Client Communication Automation Framework v1.1 and AI Automations by Jack material covering WhatsApp, voice AI, chatbots, customer support, email retrieval, RAG-assisted email drafting, communication classification, appointment setting, call recording, transcript analysis, calendar booking, CRM routing, and post-interaction intelligence
MWMS Classification: Client Communication Automation Framework / AI Customer Interaction System / Voice And Messaging Automation Standard / Retrieval Assisted Email Standard / Client Facing AIOS Communication Layer
Primary Brain: AIBS Brain
Supporting Brains: Customer Brain, Sales Brain, Automation Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain, Product Brain, Content Brain, HeadOffice Brain
Related Pages: MWMS n8n Operating And Deployment Standard, MWMS Lead Intake Qualification And Follow Up Automation Framework, MWMS Client Intelligence Report Automation Framework, MWMS RAG Knowledge Base And Client Memory Infrastructure Framework, MWMS AI Agent Memory And Context Framework, MWMS Supabase RAG And Vector Memory Framework, MWMS Client AI Interface Selection Framework, MWMS AI Dashboard Capability Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Automation Security And Risk Checklist, MWMS Advanced AI Capability Activation Registry, MWMS AI Agent Operations Core, MWMS Automation Build Planning Framework, MWMS Automation Client Demo And Handover Framework, MWMS Client Context Isolation And Privacy Boundary Standard, MWMS Client Intelligence And Business Memory Automation Framework, MWMS Client Approval And Review Gate Protocol, MWMS Meeting Intelligence And Action Extraction Framework
Purpose
The purpose of the MWMS Client Communication Automation Framework is to define how MWMS should design, govern, automate, package, and safely deploy AI-assisted communication workflows for clients and internal systems.
This framework covers communication channels such as:
voice AI
chatbots
website chat
SMS-style messaging
customer support messages
sales inquiries
group messages
inbound customer questions
AI receptionist flows
AI support assistants
AI sales assistants
AI follow-up systems
appointment communication
client report delivery
internal handoff communication
This framework exists because communication automation is one of the most commercially powerful AIBS opportunities.
Businesses lose money when they:
miss messages
reply too slowly
answer inconsistently
fail to qualify inquiries
forget follow-ups
lose customer context
repeat the same answers manually
fail to escalate urgent issues
fail to learn from repeated customer questions
send poorly grounded replies
respond from stale information
send messages to the wrong recipient
lose important commitments inside email threads
AI communication automation can help solve these problems.
However, communication automation also creates direct customer, client, compliance, privacy, operational, and reputational risk.
The purpose of this framework is therefore not simply to help AI respond faster.
It is to ensure communication automation can:
identify the correct person
understand the communication channel
classify intent
retrieve approved context
distinguish knowledge from memory
draft or respond within scope
use tools safely
request approval where required
escalate to a human
log the interaction
extract useful intelligence
create follow-up actions
learn without changing live behaviour uncontrollably
Core Doctrine
The MWMS doctrine is:
Communication automation must not merely send messages.
It must manage a governed communication lifecycle.
The complete communication lifecycle is:
Communication Received Or Triggered
→ Verify Channel And Source
→ Identify Contact Or Treat Identity As Uncertain
→ Confirm Client And Context Boundary
→ Classify Intent
→ Assess Urgency And Risk
→ Retrieve Approved Knowledge And Relevant Memory
→ Determine Whether AI May Respond, Draft, Route, Or Stop
→ Generate A Grounded Communication
→ Apply Recipient, Channel, Tone, Policy, And Permission Checks
→ Obtain Human Approval Where Required
→ Send Or Route Through An Approved Tool
→ Confirm Delivery Or Tool Result
→ Log The Interaction
→ Extract Decisions, Commitments, Questions, Objections, And Actions
→ Update Approved Records
→ Create Follow-Up Or Escalation
→ Feed Controlled Improvement
A communication workflow is incomplete if it only generates text.
It must also govern:
who receives the communication
why it is being sent
what information supports it
whether it may be sent automatically
what happens when delivery fails
what happens when the recipient replies
what is recorded afterward
what follow-up is required
Scope
This framework applies to:
client-facing communication automations
internal communication automations
WhatsApp assistants
AI voice receptionists
AI appointment setters
AI sales inquiry assistants
website chatbots
customer support assistants
SMS follow-up systems
email drafting systems
email reply assistants
email classification systems
email routing workflows
RAG-assisted email systems
proposal and report delivery
onboarding communication
appointment confirmations
missed-call recovery
lead follow-up
customer issue triage
communication intelligence extraction
post-call reporting
post-email action extraction
future AIBS communication products
This framework does not authorise automatic communication merely because an AI system can generate an answer.
Every operational communication system must have:
defined scope
approved knowledge
approved memory boundaries
identity controls
permission controls
tool controls
handoff rules
review rules
logging
failure handling
client approval
Core Definition
A Client Communication Automation is a workflow or AI system that receives, interprets, drafts, responds to, routes, logs, or analyses messages, calls, chats, inquiries, or customer conversations.
MWMS Definition
An MWMS Client Communication Automation is:
A governed AI-assisted communication workflow that receives or initiates messages or calls, verifies the communication context, classifies intent, retrieves approved knowledge and relevant memory, drafts or responds within scope, routes or escalates safely, logs the interaction, and creates business value through faster response, better qualification, improved support, stronger follow-up, or customer intelligence.
Communication Automation Objectives
A communication automation should support one or more defined objectives.
Possible objectives include:
reduce response time
recover missed inquiries
answer approved repetitive questions
qualify leads
book appointments
route support issues
confirm appointments
send approved reminders
draft accurate email replies
summarise long communication threads
recover historical client context
identify unanswered questions
identify commitments
create follow-up tasks
extract objections
identify customer pain signals
improve FAQs
improve service delivery
create client intelligence
Rule
A communication system must have a defined objective.
It should not be deployed merely because automated messaging appears impressive.
Communication Channels
MWMS recognises the following communication channels.
WhatsApp is useful for:
customer inquiries
sales messages
service coordination
group discussions
support follow-up
appointment reminders
community intelligence
client team communication
Benefits
familiar to many users
high open rates
conversational
strong in many markets
useful for service businesses
good for quick follow-up
Risks
account or session risk
privacy risk
wrong-chat response
group-message sensitivity
customer consent issues
unofficial API or provider risk
message-volume and spam risk
accidental response to the wrong person or group
MWMS Rule
WhatsApp automation must filter by approved contact, chat, group, client, and workflow scope.
Do not let automation respond to every incoming WhatsApp message by default.
- Voice AI
Voice AI is useful for:
AI receptionists
missed-call recovery
appointment confirmation
inbound FAQs
lead qualification
customer support triage
booking reminders
sales inquiry handling
Benefits
natural interface
fast customer experience
useful for phone-heavy businesses
high perceived value
strong AIBS commercial potential
Risks
consent and recording rules
customer frustration
incorrect spoken answers
poor escalation
sensitive topics
brand reputation
call-logging privacy
accent and language issues
hallucinated policy or pricing
false identity assumptions
incorrect calendar actions
MWMS Rule
Voice AI must have script boundaries, approved knowledge, handoff logic, tool permission, disclosure rules, and risk escalation before customer use.
- Website Chatbot
Website chatbots are useful for:
FAQ handling
lead qualification
support triage
service recommendations
booking prompts
onboarding guidance
product and service questions
Benefits
easy client adoption
always available
can connect to RAG
can collect lead details
can reduce repetitive support
Risks
stale knowledge
unsupported claims
privacy issues
no handoff path
over-answering
wrong-client knowledge
collecting sensitive data accidentally
MWMS Rule
A chatbot must know its approved knowledge source, memory boundary, tool access, and handoff triggers.
- SMS And Short Message Follow-Up
SMS or similar short-message channels may support:
appointment reminders
follow-up prompts
lead recovery
confirmation messages
urgent updates
Risks
consent rules
opt-out requirements
spam complaints
wrong recipient
over-messaging
MWMS Rule
Short-message automation must be permissioned, minimal, and tied to a clear user relationship.
- Email Communication
Email may support:
inbound reply assistance
follow-up sequences
proposal delivery
report delivery
onboarding
lead nurture
support summaries
human handoff confirmation
appointment follow-up
client update messages
thread summarisation
historical context retrieval
Risks
spam compliance
wrong recipient
wrong reply thread
sensitive attachments
unsupported claims
unreviewed AI copy
stale historical context
private information leakage
incorrect client identity
reply-all mistakes
AI tone mismatch
promises that have not been approved
automatic sending without adequate review
MWMS Rule
Email automation must match consent, purpose, recipient, thread, approved context, authority, and review requirements.
Communication Operating Model
Every communication automation should operate across fourteen layers:
Channel And Trigger Layer
Identity And Client Boundary Layer
Intent And Urgency Layer
Risk Classification Layer
Approved Knowledge Layer
Conversation And Relationship Memory Layer
Retrieval And Context Assembly Layer
Response Or Draft Generation Layer
Tone And Brand Layer
Tool And Action Permission Layer
Approval And Human Handoff Layer
Delivery And Failure Confirmation Layer
Interaction Intelligence Layer
Learning And Improvement Layer
- Channel And Trigger Layer
The system must identify:
which channel triggered the workflow
whether the communication is inbound or outbound
whether the event is new or part of an existing thread
whether the channel is approved
whether the workflow may act on that channel
Possible triggers include:
new inbound email
new WhatsApp message
new website-chat message
incoming call
missed call
scheduled follow-up
appointment event
support-ticket update
human-approved send instruction
Rule
The same response rules should not be assumed across all channels.
- Identity And Client Boundary Layer
The system should identify the participant where possible.
Identity may be established through:
verified email address
verified phone number
CRM contact ID
client account
authenticated session
conversation ID
booking record
approved channel mapping
If identity cannot be confirmed, the system should treat the identity as uncertain.
It must not expose private information based only on an unverified name, phone number, or email appearance.
Client Boundary Rule
Every communication must remain inside the correct client and account boundary.
The system must not retrieve:
another client’s knowledge
another customer’s conversation
another account’s pricing
another organisation’s files
unrelated private records
- Intent And Urgency Layer
Communication classification should identify:
Intent
What does the user want?
User Type
Lead, customer, client, employee, partner, supplier, or unknown.
Urgency
Low, normal, urgent, or emergency.
Risk
Low, medium, high, or restricted.
Required Context
FAQ, CRM, booking, order, approved knowledge, historical thread, or human review.
Response Type
AI response, AI draft, clarifying question, task, handoff, no action, or restricted response.
Follow-Up
Required or not required.
Possible intents include:
general question
pricing question
service question
support request
booking request
complaint
cancellation
refund request
sales inquiry
proposal question
report question
technical problem
personal-data request
legal issue
emergency issue
human-requested escalation
Rule
Classification should determine the next step.
It must not merely label the message.
- Risk Classification Layer
Risk classification should consider:
financial consequence
legal consequence
medical or safety consequence
privacy sensitivity
reputational consequence
client relationship impact
potential commitment
public visibility
policy interpretation
refund or cancellation impact
urgency
High-risk communications should not be automatically answered or sent without suitable authority.
Examples include:
legal threats
medical questions
safety emergencies
large refunds
contract changes
pricing commitments
formal complaints
public-relations issues
security incidents
data deletion requests
regulated advice
Rule
High-risk communication requires controlled escalation.
- Approved Knowledge Layer
Client communication systems must respond from approved knowledge.
Approved knowledge may include:
FAQ
service pages
product information
pricing rules
support policies
client SOPs
booking policy
refund policy
onboarding guide
approved offer documents
Supabase RAG sources
CRM records
current dashboard data
approved email templates
approved response examples
current calendar availability
Rule
Do not let AI invent business policy.
Knowledge Status
Approved knowledge should indicate:
source
owner
client
version
approval status
effective date
expiry or review date
sensitivity
permitted communication channels
Rule
Stale, draft, unapproved, or wrong-client knowledge must not be presented as current policy.
- Conversation And Relationship Memory Layer
Communication systems may use memory, but memory must be scoped.
Memory may include:
current conversation
current email thread
session state
previous inquiry
customer preference
CRM note
support history
lead status
client-specific rule
previous commitment
appointment history
approved relationship context
Memory must not include:
unrelated customer data
wrong-client records
sensitive data beyond need
stale facts treated as current
casual statements saved permanently without approval
private information from unrelated threads
unverified AI interpretations stored as fact
Rule
Conversation memory helps continuity.
It does not override approved knowledge or current evidence.
Memory Classification
Communication memory should distinguish:
Current Session Memory
Relevant only to the active interaction.
Thread Memory
Relevant to the current email, chat, ticket, or call chain.
Relationship Memory
Approved facts that support continuity across interactions.
Operational Memory
Current booking, order, ticket, or service state.
Historical Archive
Older communication retained for audit or authorised retrieval.
AI Interpretation
A summary, sentiment, classification, or inference that is not confirmed fact.
- Retrieval And Context Assembly Layer
Before generating a response, the system should retrieve only the context needed for the current communication.
Potential context includes:
current message
recent thread history
approved knowledge
client policy
contact record
open tasks
previous commitments
current appointment or order
relevant source documents
approved tone guidance
The context assembly process should:
identify the current question
retrieve relevant information
rank context by relevance
check freshness
remove unrelated material
preserve source references
identify missing information
identify contradictions
Rule
More retrieved material does not automatically improve the response.
The system should use the smallest sufficient context set.
- Response Or Draft Generation Layer
The system must determine whether it may:
respond automatically
prepare a draft for review
ask a clarifying question
route the communication
create a task
send a holding response
decline to answer
escalate to a human
Response generation should be grounded in:
the user’s actual message
approved knowledge
verified operational data
relevant thread context
permitted memory
channel requirements
client tone rules
Rule
The system must not answer beyond the available evidence or its approved authority.
- Tone And Brand Layer
Communication should reflect:
client voice
channel expectations
relationship stage
urgency
recipient familiarity
service standard
cultural and language context
The system should avoid:
generic AI phrasing
unnecessary verbosity
fake warmth
overconfident certainty
repetitive apologies
unapproved humour
manipulative pressure
false personal familiarity
claims that a human personally reviewed something when they did not
Rule
Tone must never override factual accuracy, safety, or authority.
- Tool And Action Permission Layer
Communication automation may use tools such as:
WhatsApp providers
voice systems
Unipile
GoHighLevel
Supabase
Airtable
Google Sheets
Gmail
Google Calendar
CRM systems
RAG tools
booking systems
email tools
SMS tools
PDF and report tools
call-recording tools
Tool actions may include:
read approved records
create a draft
send an approved response
create a task
book an appointment
update a CRM stage
attach a report
record a call outcome
schedule follow-up
Tool actions must define:
allowed action
required authority
approval requirement
data boundary
confirmation requirement
failure behaviour
logging requirement
Rule
Generating a response and executing a tool action are separate permissions.
- Approval And Human Handoff Layer
Human approval may be required when:
sending external email
replying to a complaint
making a pricing commitment
changing an appointment
providing sensitive information
sending an attachment
making a public claim
handling a refund
using uncertain context
responding to a high-value client
sending a bulk communication
entering a new communication workflow into production
Human handoff should include:
identity
channel
message or call summary
intent
urgency
risk
relevant context
actions already taken
tools used
uncertainty
recommended response
deadline
Rule
Human handoff must transfer useful context, not merely forward the original message.
- Delivery And Failure Confirmation Layer
The workflow should not assume a message, booking, or update succeeded.
Confirm where possible:
message sent
draft created
recipient accepted
email provider result
calendar booking created
CRM record updated
attachment included
tool call completed
delivery failed
bounce detected
rate limit reached
provider unavailable
Rule
The system must not tell a customer that an action succeeded until the relevant tool confirms success.
- Interaction Intelligence Layer
Every meaningful interaction may produce intelligence.
Potential intelligence includes:
question
intent
objection
complaint
pain point
requested feature
commitment
decision
appointment outcome
purchase signal
risk signal
customer preference
knowledge gap
FAQ opportunity
follow-up action
service failure
Interaction intelligence must distinguish:
customer statement
verified fact
AI summary
AI classification
AI inference
human decision
Rule
Communication logs should create useful business intelligence without turning every conversation into permanent memory.
- Learning And Improvement Layer
Communication systems should improve through controlled review.
Possible improvements include:
FAQ updates
new approved templates
better routing
improved classification
new escalation triggers
revised knowledge
shorter response patterns
improved call scripts
better email tone
new support categories
tool failure corrections
Learning should use:
approved interaction logs
human corrections
outcome data
failure records
response-review results
customer feedback
Rule
A communication system must not rewrite its own live operating rules from individual interactions.
Improvements must be reviewed, approved, versioned, and deployed through controlled change.
Voice Communication Operating Layer
Voice communication requires stricter controls because responses occur live and may trigger immediate actions.
The standard MWMS voice workflow is:
Call Received Or Triggered
→ Verify Source, Permission And Scope
→ Load Approved Context
→ Identify Caller Or Treat Identity As Uncertain
→ Disclose Automation Where Required
→ Classify Intent
→ Assess Risk
→ Confirm Important Details
→ Respond Within Scope
→ Use Approved Tools
→ Route Or Escalate
→ End Call Safely
→ Store Post-Call Intelligence
→ Create Follow-Up Or Improvement Action
Voice Communication Use Cases
Approved use cases may include:
inbound receptionist
outbound lead response
missed-call recovery
appointment setting
appointment confirmation
basic FAQ handling
sales inquiry qualification
support triage
reminder calls
follow-up calls
Voice Disclosure Standard
The system should identify itself as automated where:
required by law
required by client policy
needed to avoid misleading the caller
recording or transcription occurs
The system must not claim to be a specific human.
Caller Identity Standard
Caller identity may be treated as:
Verified
Matched through an approved authenticated or confirmed record.
Probable
Matched through available information but not fully confirmed.
Unknown
No reliable identity match.
Rule
Sensitive information must not be disclosed to probable or unknown callers without suitable verification.
Known Context And Confirmation Rule
Known context may include:
name
company
previous inquiry
booking
service requested
open support issue
The voice agent should confirm material details before using them.
It must not assume all retrieved context is current or correct.
Voice Function Permission Standard
Voice systems may use approved functions such as:
check availability
book appointment
reschedule appointment
cancel appointment
create CRM record
update CRM status
create follow-up task
send confirmation
request human transfer
end call
Each function should define:
required fields
confirmation requirement
allowed circumstances
failure response
logging
Voice Calendar Communication Standard
Before creating or changing an appointment, confirm:
person
service
date
time
timezone
location or meeting method
contact details
calendar availability
cancellation or rescheduling conditions
The system must not announce a confirmed appointment until the calendar tool reports success.
Call Control Standard
Voice systems should define:
maximum call duration
silence timeout
interruption handling
repetition limit
retry limit
no-answer handling
voicemail policy
calling hours
do-not-contact handling
call-ending function
human-request handling
emergency handling
Rule
The caller must not become trapped in an AI loop.
Recording And Transcript Governance
Before recording, transcribing, storing, or analysing a call, confirm:
legal basis
notice requirement
consent requirement
client approval
storage location
retention period
access permissions
deletion process
recording ownership
sensitive-data controls
third-party processing
transcript accuracy limits
Recordings and transcripts should be retained only for an approved purpose.
Rule
Recording and transcript storage are governed data operations.
They are not default permissions.
Post-Call Communication Record
A post-call record should include:
Call ID:
Client:
Contact:
Identity Status:
Call Direction:
Purpose:
Intent:
Risk:
Summary:
Questions Asked:
Answers Given:
Knowledge Sources Used:
Tools Called:
Tool Results:
Appointment Result:
Commitments:
Corrections:
Human Handoff:
Follow-Up Required:
Transcript Confidence:
Recording Status:
Retention Status:
Post-Call Intelligence Rule
Voice AI should produce structured post-call intelligence, not merely a recording or transcript.
Email Communication Operating Layer
Email communication requires a dedicated operating layer because email often combines:
long historical threads
multiple recipients
attachments
contractual or commercial commitments
formal records
delayed responses
private information
client knowledge
cross-team communication
The standard MWMS email workflow is:
Email Received Or Send Trigger Created
→ Verify Mailbox, Client, Sender, Recipient, And Thread
→ Confirm Whether The Message Is New, A Reply, Or A Forward
→ Classify Intent, Urgency, Risk, And Required Authority
→ Retrieve Relevant Thread Context
→ Retrieve Approved Knowledge And Relationship Memory
→ Identify Questions, Requests, Commitments, And Attachments
→ Determine Draft, Send, Route, Escalate, Or No Action
→ Generate Grounded Draft
→ Apply Recipient, Reply Mode, Tone, Privacy, Attachment, And Commitment Checks
→ Obtain Human Approval Where Required
→ Send Through Approved Mail Tool
→ Confirm Send Result
→ Log Communication
→ Extract Actions, Decisions, Commitments, And Follow-Up
→ Update Approved Records
→ Create Reminder Or Escalation
Email Use Cases
Approved use cases may include:
drafting replies
summarising long threads
identifying unanswered questions
preparing follow-up emails
proposal delivery
report delivery
onboarding messages
appointment confirmations
support summaries
handoff confirmations
client-status updates
lead nurture
sales follow-up
internal action extraction
Email Identity And Thread Rule
Before drafting or replying, identify:
mailbox
sender
recipient
CC recipients
BCC requirement if any
client
contact
thread
message being answered
relationship status
The system must not:
reply to the wrong thread
use another client’s history
assume two people with similar names are the same contact
include recipients from a previous message without checking
use reply-all without understanding the recipient list
Draft Versus Send Standard
Email workflows should distinguish:
Read And Classify
The system reads and labels the email but does not draft or send.
Draft Only
The system prepares a response for human review.
Approved Template Send
The system sends a pre-approved low-risk template under controlled conditions.
Human-Approved Send
The system sends only after a human approves the final draft.
Restricted
The system does not draft or send and routes the email to an authorised human.
Rule
Draft permission does not create send permission.
RAG Assisted Email Standard
Retrieval-assisted email drafting may use:
approved client knowledge
current service information
pricing rules
contract terms
support policies
previous approved correspondence
current CRM state
current project records
relationship memory
The system should retrieve context based on the actual email question.
It should not retrieve broad historical material merely because it is available.
Retrieved information should be:
client-specific
relevant
current
approved
source-linked
permitted for the recipient
Rule
Historical email retrieval is a context mechanism.
It is not permission to reproduce private historical information.
Email Thread Context Standard
The system should distinguish:
Current Message
The exact email requiring action.
Recent Thread Context
Messages needed to understand the current request.
Historical Relationship Context
Older approved facts relevant to the relationship.
Unrelated Archive
Historical email not required for the response.
Rule
Do not overload the model with an entire mailbox when a small thread segment and approved client memory are sufficient.
Email Question And Commitment Extraction
Before drafting, extract:
questions requiring answers
requests requiring action
promises already made
deadlines
dates
amounts
attachments referenced
people responsible
unresolved issues
risks
The draft should answer each material question or clearly state what remains unanswered.
Rule
A polished reply that misses the main question is a failed communication.
Email Source Grounding Standard
Material statements in an email should be grounded in:
approved policy
verified client record
approved pricing
current project status
confirmed calendar data
authorised human instruction
The system should not invent:
project completion
delivery dates
refund approval
pricing
discounts
contract terms
technical resolution
meeting confirmation
human approval
Email Recipient Safety Standard
Before send, confirm:
To recipients
CC recipients
BCC recipients
reply or reply-all choice
client identity
attachment permissions
confidentiality
whether internal notes have been removed
whether forwarded content is appropriate
whether a previous recipient should remain included
Rule
Recipient validation is a mandatory pre-send check.
Email Attachment Standard
Before attaching or forwarding a file, confirm:
correct file
correct version
correct client
approved recipient
sensitivity
access permission
file completeness
whether the email accurately describes the attachment
The system must not infer attachment content if it has not inspected or been given an approved summary of that file.
Email Tone And Human Quality Standard
Email drafts should:
sound natural
match the client’s voice
reflect the relationship
answer directly
use appropriate length
avoid generic AI openings
avoid repetitive summary language
avoid unnecessary headings in normal correspondence
avoid fake personal experience
avoid claiming emotions or personal review that did not occur
Rule
Human-sounding communication must remain accurate and honest.
It should not impersonate a named human’s personal actions or feelings.
Email Approval Triggers
Human review is required where the email:
contains a financial commitment
changes pricing
changes scope
changes a deadline
contains legal or compliance content
responds to a complaint
discusses termination or cancellation
contains sensitive personal data
includes confidential attachments
goes to multiple external recipients
is sent to a high-value client
contains uncertain information
creates a new client commitment
uses a new response pattern
Email Send Confirmation Standard
After sending, record:
message ID
thread ID
send time
sender mailbox
recipients
subject
approval record
template or prompt version
attachments
delivery result where available
follow-up date
Rule
The communication record must show what was actually sent, not merely what was drafted.
Email Failure Handling
Possible failures include:
authentication failure
provider outage
rate limit
invalid recipient
bounce
attachment failure
wrong mailbox
thread mismatch
draft creation failure
send permission failure
The system should:
stop unsafe retries
record the failure
avoid duplicate sends
notify the responsible owner
preserve the draft
create a follow-up task where required
Email Follow-Up State Standard
Email communication should track:
Waiting For Internal Review
Waiting For Send
Sent
Waiting For Recipient
Follow-Up Due
Recipient Responded
Escalated
Closed
No Response
Suppressed
Rule
A sent email is not automatically a completed communication outcome.
Email Communication Record
An email communication record should include:
Communication ID:
Client:
Contact:
Mailbox:
Message ID:
Thread ID:
Direction:
Sender:
Recipients:
Subject:
Intent:
Urgency:
Risk:
Questions:
Requests:
Commitments:
Deadlines:
Approved Knowledge Used:
Memory Used:
Sources Used:
Draft Or Send Mode:
Approval Status:
Sent Status:
Attachments:
Follow-Up Date:
Human Owner:
Outcome:
Retention Status:
Email Intelligence Extraction
Email interactions may produce:
new client facts
confirmed preferences
questions
objections
commitments
deadlines
decisions
action items
relationship risks
support issues
product feedback
content opportunities
FAQ opportunities
Potential memory updates should be classified before storage.
Rule
An AI summary of an email must not automatically become permanent client fact.
Chatbot Automation Standard
A chatbot should define:
Purpose:
User Type:
Scope:
Approved Knowledge:
Memory Type:
RAG Source:
Allowed Tools:
Forbidden Actions:
Handoff Trigger:
Escalation Owner:
Logging:
Fallback Response:
Chatbot Must Know
what it can answer
what it cannot answer
what source to use
when to ask a question
when to stop
when to hand off
what to log
Rule
A chatbot without memory, knowledge, and handoff rules is not a serious client system.
Approved Response Standard
Communication systems may use approved response classes.
Informational Response
Answers a low-risk question from approved knowledge.
Clarifying Response
Requests information required before action.
Acknowledgement Response
Confirms receipt without making an unsupported commitment.
Routing Response
Explains that the communication has been passed to the correct person.
Holding Response
States that review is required and gives an approved expectation.
Action Confirmation
Confirms an action only after the relevant tool reports success.
Restricted Response
Declines to answer and provides an approved escalation path.
Rule
The response type should match the system’s authority.
Human Handoff Standard
Human handoff is mandatory when:
the user requests a human
the system lacks approved knowledge
identity cannot be sufficiently verified
the communication is high risk
a complaint may affect reputation
a legal or compliance matter appears
a vulnerable or distressed person requires support
a tool action fails materially
the user disputes the AI response
the communication requires commercial authority
the system reaches its attempt limit
Handoff Context Pack
Include:
communication channel
client
contact
identity confidence
message or call summary
intent
urgency
risk
relevant history
approved knowledge retrieved
questions still unanswered
actions taken
tool results
recommended next step
deadline
Rule
The human should not need to reconstruct the entire interaction before helping.
Communication Intelligence Standard
Communication automation should create structured intelligence.
Possible fields include:
Communication ID:
Client ID:
Contact ID:
Channel:
Direction:
Intent:
Urgency:
Risk:
Summary:
Questions:
Objections:
Pain Signals:
Commitments:
Decisions:
Actions:
Owner:
Due Date:
Handoff Status:
Outcome:
Source Record:
Confidence:
Memory Candidate:
Knowledge Gap:
FAQ Candidate:
Rule
Interaction intelligence should remain linked to the original communication record.
Client Communication Memory Rule
Communication memory must distinguish:
what the customer said
what the system inferred
what a human confirmed
what policy states
what action actually occurred
Potential memory updates should pass through:
candidate extraction
classification
validation
client-boundary check
freshness rule
human approval where required
storage
Rule
Do not convert temporary conversation details into permanent memory by default.
Communication Dashboard Standard
A communication dashboard may later show:
new inquiries
unanswered communications
drafts waiting for approval
high-risk interactions
human handoffs
failed sends
failed tool actions
appointments booked
follow-ups due
no-response leads
common questions
common objections
knowledge gaps
customer sentiment signals
AI response-review score
Dashboard Rule
The dashboard must help operators act.
It should not merely count messages.
Communication Intelligence Report Integration
Communication records may feed the MWMS Client Intelligence Report Automation Framework.
Possible report insights include:
response time
inquiry volume
lead quality
appointment outcomes
support themes
frequent objections
customer pain signals
unanswered questions
failed communication events
knowledge gaps
follow-up performance
handoff rate
conversion opportunities
Rule
Client reports should explain what the communication data means and what action is recommended.
Build Path
Stage 1: Select One Channel And Use Case
Begin with one clearly bounded workflow.
Recommended starting use case:
AI Support And Sales Inquiry Router with approved responses and human handoff.
Stage 2: Define Scope And Risk
Document:
allowed questions
prohibited topics
approved users
required escalation
data boundaries
Stage 3: Prepare Approved Knowledge
Create and validate:
FAQs
service information
pricing rules
support policies
booking rules
response templates
Stage 4: Define Classification
Define:
intents
risk categories
urgency
routing
follow-up logic
Stage 5: Define Memory
Decide:
current-session memory
thread memory
relationship memory
operational memory
permanent-memory approval
Stage 6: Define Tool Permissions
Determine:
read actions
draft actions
send actions
calendar actions
CRM actions
task actions
Stage 7: Define Human Handoff
Create:
triggers
owners
context pack
response expectation
Stage 8: Test Failure Paths
Test:
wrong identity
wrong client
missing knowledge
stale knowledge
tool failure
recipient error
attachment error
calendar failure
high-risk message
human request
Stage 9: Launch With Monitoring
Start with assisted, draft-only, or reviewed mode where possible.
Stage 10: Improve From Logs
Use approved logs to improve:
FAQs
routing
templates
tone
knowledge
handoff
tool reliability
Launch Readiness Checklist
Before launching communication automation, confirm:
channel is defined
client use case is clear
approved knowledge exists
scope is defined
prohibited topics are defined
tool access is permissioned
message source is filtered
identity rules exist
client isolation exists
intent classification is tested
risk classification exists
human handoff exists
fallback response exists
logging exists
sensitive-data rules exist
consent and privacy have been considered
response templates have been tested
hallucination controls exist
dashboard or reporting path exists
error handling exists
owner is assigned
monitoring process is defined
memory boundaries exist
knowledge freshness is controlled
If voice is used, confirm:
voice disclosure is defined
caller identity rule is defined
known context is mapped
confirmation rules are defined
calendar timezone is tested
duplicate-booking control exists
maximum call duration is set
silence timeout is set
retry and no-answer rules are defined
voicemail policy is defined
calling hours are defined
do-not-contact handling is tested
human escalation is tested
emergency handling is tested
call-ending function is tested
recording and transcript rules are approved
post-call record is tested
tool-failure language is tested
corrected data writes back correctly
If email is used, confirm:
mailbox scope is defined
sender authority is defined
recipient checks exist
reply versus reply-all logic is tested
thread detection is tested
draft versus send permission is defined
RAG source is approved
historical context is limited
attachment checks exist
sensitive information checks exist
commitment detection exists
approval triggers exist
send confirmation is logged
duplicate-send prevention exists
bounce and failure handling exist
follow-up states are defined
email tone is tested for human quality
Failure Modes
Failure Mode 1: Automation Responds To Everything
The system responds to every incoming message without filtering.
Correction
Filter by approved channel, contact, group, mailbox, client, or workflow.
Failure Mode 2: No Handoff
AI continues when human support is needed.
Correction
Add handoff triggers and an escalation owner.
Failure Mode 3: AI Invents Policy
AI answers pricing, refund, or service rules from general knowledge.
Correction
Use approved knowledge only.
Failure Mode 4: Wrong Customer Context
AI uses the wrong CRM, contact, thread, or client data.
Correction
Add identity verification and client filters.
Failure Mode 5: Sensitive Data Stored Unnecessarily
Communication logs store more than needed.
Correction
Apply minimisation and retention rules.
Failure Mode 6: Voice Agent Frustrates Customer
The caller becomes trapped in an AI loop.
Correction
Add quick human transfer and call-failure handling.
Failure Mode 7: WhatsApp Group Privacy Breach
Private group content is processed or reported without permission.
Correction
Filter approved groups and define group-data rules.
Failure Mode 8: No Learning Loop
Repeated questions and failures never improve approved knowledge.
Correction
Create a controlled FAQ and improvement review.
Failure Mode 9: Silent Tool Failure
The system claims an action occurred when the tool failed.
Correction
Require tool confirmation before communicating success.
Failure Mode 10: Full Autonomy Is Promised
The client expects AI to handle every interaction.
Correction
Define scope, exception paths, and human authority.
Failure Mode 11: Wrong Email Recipient
A response is sent to the wrong contact or client.
Correction
Validate the recipient and client boundary before send.
Failure Mode 12: Incorrect Reply-All
Internal or private information is sent to unnecessary recipients.
Correction
Review To, CC, BCC, and reply mode before send.
Failure Mode 13: Historical Email Overload
The system retrieves an entire mailbox and uses irrelevant history.
Correction
Retrieve only the smallest relevant thread and approved relationship context.
Failure Mode 14: Historical Statement Treated As Current
An old email is treated as current policy or status.
Correction
Check effective dates and approved current knowledge.
Failure Mode 15: Draft Permission Becomes Send Permission
A system designed to draft begins sending automatically.
Correction
Separate draft and send tool authority.
Failure Mode 16: Attachment Leakage
A file belonging to another client or internal team is attached.
Correction
Validate file identity, version, client, sensitivity, and recipient.
Failure Mode 17: Unsupported Commitment
The email promises price, scope, completion, approval, or timing without authority.
Correction
Detect commitments and require approval.
Failure Mode 18: AI Tone Is Obvious Or Inappropriate
The message feels generic, repetitive, or unlike the client.
Correction
Apply approved voice, relationship context, and human-quality review.
Failure Mode 19: Main Question Is Missed
The system produces a polished reply that does not answer the request.
Correction
Extract and check every material question before approval.
Failure Mode 20: Duplicate Email Send
A retry causes the same email to be sent twice.
Correction
Use message IDs, idempotency, send-state checks, and controlled retries.
Failure Mode 21: Reply Sent Into Wrong Thread
A valid response is attached to the wrong conversation.
Correction
Verify the reply message and thread before send.
Failure Mode 22: Private Historical Information Is Repeated
The response reveals unrelated past communication.
Correction
Apply relevance, recipient, and privacy filters to retrieved memory.
Failure Mode 23: Recording Retained Without Purpose
Call recordings remain stored indefinitely.
Correction
Apply retention and deletion rules.
Failure Mode 24: Transcript Error Creates Action
The system acts on an incorrect transcription.
Correction
Mark transcript confidence and review high-impact actions.
Failure Mode 25: Sentiment Treated As Fact
The system labels a person as hostile, positive, or risky without sufficient evidence.
Correction
Treat sentiment as an AI interpretation.
Failure Mode 26: AI Claims Human Review
The communication says that a named human reviewed or personally decided something when this did not occur.
Correction
Use truthful disclosure and approved wording.
Failure Mode 27: Memory Update Becomes False Fact
An AI summary is stored as confirmed client information.
Correction
Separate extracted facts, inferences, and human-confirmed memory.
Governance Responsibilities
AIBS Brain
Owns:
client communication offer design
client system scope
commercial packaging
client expectation setting
approval requirements
client value definition
Customer Brain
Owns:
customer experience principles
relationship continuity
customer preferences
communication-quality insight
Sales Brain
Owns:
sales inquiry routing
lead qualification
sales follow-up
commercial handoff
approved sales responses
Automation Brain
Owns:
workflow triggers
tool orchestration
retry logic
failure handling
scheduling
delivery confirmation
Data Brain
Owns:
communication records
identity linkage
thread linkage
data quality
retention states
structured interaction intelligence
Risk And Compliance Brains
Own:
consent
privacy
recording rules
communication regulation
suppression
sensitive-data handling
client and jurisdiction risk
SIT Brain
Owns:
independent review
failure escalation
high-risk testing
communication-system evaluation
Content Brain
Supports:
tone
brand language
response quality
human-sounding communication
approved templates
Product Brain
Supports:
operator interface
client interface
review queues
handoff experience
dashboard design
HeadOffice
Owns:
cross-Brain governance
authority conflicts
high-impact exceptions
strategic review
final escalation
AI Employee Capabilities
Communication Workflow Architect
Designs communication workflows, scope, handoff, and control points.
Message Classification Agent
Classifies intent, urgency, risk, and required context.
Approved Response Agent
Creates grounded replies from approved knowledge.
Email Context Retrieval Agent
Retrieves the smallest relevant thread, knowledge, and relationship context.
Email Drafting Agent
Creates channel-appropriate drafts without send authority unless specifically granted.
Recipient And Thread Safety Agent
Checks recipient, client, mailbox, reply mode, thread, and attachment safety.
Commitment Detection Agent
Identifies promises, deadlines, pricing, scope, and approval commitments.
Handoff Coordinator Agent
Packages communication context for a human.
Voice Interaction Reviewer
Reviews call quality and escalation failures.
WhatsApp Scope Guard Agent
Checks whether messages come from approved chats or groups.
Customer Intelligence Extractor
Extracts repeated questions, objections, complaints, and improvement opportunities.
FAQ Improvement Agent
Turns repeated patterns into proposed FAQ updates.
Voice Communication Quality Agent
Reviews clarity, interruption handling, confirmation quality, call length, and customer friction.
Voice Disclosure And Consent Agent
Checks disclosure, calling permission, recording notice, consent, suppression, and retention requirements.
Voice Appointment Coordinator
Checks availability, confirms details, books appointments, and records outcomes.
Post-Call Intelligence Agent
Structures transcript, summary, intent, risk, appointment result, corrections, actions, and follow-up.
Voice Escalation Coordinator
Routes human requests, complaints, sensitive situations, emergencies, and unsupported requests.
Voice Tool Failure Reviewer
Checks whether calendar, CRM, telephony, recording, transcription, or routing actions failed and whether the caller was informed accurately.
Communication Memory Reviewer
Evaluates whether extracted information should become session, thread, relationship, operational, or no memory.
Future Expansion
This framework may later produce:
MWMS WhatsApp AI Customer Assistant Framework
MWMS Voice AI Receptionist Governance Framework
MWMS Chatbot Memory And Handoff Standard
MWMS Customer Communication Logging Standard
MWMS AI Support Router Framework
MWMS AI Appointment Confirmation Framework
MWMS Communication Intelligence Digest Framework
These should be created only when the related system moves into active build or client package design.
Strategic Summary
Client communication automation remains one of the strongest AIBS opportunities.
The central insight is:
Communication automation should not merely reply.
It should:
verify
classify
retrieve
draft
respond
route
log
hand off
confirm
extract intelligence
follow up
learn through controlled review
The strongest commercial opportunities include:
AI WhatsApp Customer Assistant
AI Voice Receptionist
AI Sales Inquiry Assistant
AI Support Router
AI Appointment Confirmation Agent
RAG Assisted Email Assistant
Communication Intelligence Digest
However, this area requires strong governance because it touches customers and clients directly.
The best first version is not full autonomy.
The recommended first version remains:
AI Support And Sales Inquiry Router with approved responses, draft-first operation, and human handoff.
This gives clients measurable value while keeping risk controlled.
Final Standard
The MWMS standard is:
Client communication automation must be scoped, permissioned, identity-aware, client-isolated, source-aware, memory-controlled, logged, handoff-ready, failure-aware, and customer-safe.
AI may assist communication, but it must not:
invent policy
ignore risk
bypass human escalation
use the wrong client context
respond outside approved scope
send without authority
expose private history
make unsupported commitments
claim tool success without confirmation
Communication automation is not merely messaging.
It is a governed customer-experience and relationship-intelligence system.
Where voice is used, MWMS must govern:
disclosure
identity
known context
confirmation
tool permissions
calendar accuracy
recording
transcript handling
call controls
human escalation
post-call intelligence
safe termination
Where email is used, MWMS must govern:
mailbox authority
recipient identity
client and thread boundaries
reply mode
retrieval scope
historical context
approved knowledge
draft versus send permission
commitments
attachments
tone
human approval
delivery confirmation
follow-up state
memory updates
That is the MWMS Client Communication Automation Framework.
MWMS System Change Log
Version: v1.2
Date: 2026-06-21
Author: HeadOffice
Change
Updated the MWMS Client Communication Automation Framework from v1.1 to v1.2 using the AI Automations by Jack material covering:
RAG-assisted email drafting
historical email retrieval
automatic email-response workflows
thread context
customer and client memory
email classification
retrieval-grounded communication
draft generation
Gmail automation
follow-up creation
communication intelligence extraction
Expanded the framework beyond its existing WhatsApp, chatbot, SMS, voice AI, and general email coverage by adding a dedicated Email Communication Operating Layer.
Added standards covering:
• mailbox, sender, recipient, client, and thread verification
• email identity and thread control
• draft versus send authority
• RAG-assisted email drafting
• minimum sufficient historical retrieval
• current message versus thread memory versus relationship memory
• question and commitment extraction
• source-grounded email statements
• recipient, CC, BCC, reply, and reply-all safety
• attachment validation
• human-quality email tone
• email approval triggers
• send confirmation
• email failure handling
• communication follow-up states
• email interaction records
• email intelligence extraction
Expanded the Communication Operating Model from its previous structure into fourteen governed layers:
• Channel And Trigger Layer
• Identity And Client Boundary Layer
• Intent And Urgency Layer
• Risk Classification Layer
• Approved Knowledge Layer
• Conversation And Relationship Memory Layer
• Retrieval And Context Assembly Layer
• Response Or Draft Generation Layer
• Tone And Brand Layer
• Tool And Action Permission Layer
• Approval And Human Handoff Layer
• Delivery And Failure Confirmation Layer
• Interaction Intelligence Layer
• Learning And Improvement Layer
Added explicit doctrine that:
• draft permission does not create send permission
• historical email retrieval does not authorise disclosure of private history
• an email should retrieve the smallest sufficient context set
• recipient validation is mandatory before send
• generated text and tool execution are separate permissions
• a sent email is not automatically a completed outcome
• AI summaries must not automatically become permanent client facts
Added email-specific launch-readiness controls covering:
• mailbox scope
• sender authority
• recipient validation
• reply-all logic
• thread detection
• draft and send permission
• RAG source approval
• historical-context limits
• attachment checks
• commitment detection
• send confirmation
• duplicate-send prevention
• bounce handling
• follow-up state
Added email-specific failure modes covering:
• wrong recipient
• incorrect reply-all
• historical context overload
• old statements treated as current
• draft authority becoming send authority
• attachment leakage
• unsupported commitments
• obvious AI tone
• missed questions
• duplicate sends
• wrong-thread replies
• private historical information leakage
• false claims of human review
• AI memory summaries becoming false facts
Added AI Employee capability candidates:
• Email Context Retrieval Agent
• Email Drafting Agent
• Recipient And Thread Safety Agent
• Commitment Detection Agent
• Communication Memory Reviewer
Change Impact Declaration
This update strengthens the existing client communication framework without changing its owner, parent page, authority level, or core client-communication purpose.
AIBS Brain remains the primary Brain.
The framework continues to govern:
• voice AI
• website chatbots
• SMS and short-message communication
• email communication
• customer support routing
• sales inquiries
• appointment communication
• post-interaction intelligence
The update does not authorise automatic access to complete client mailboxes, unrestricted historical email ingestion, uncontrolled external sending, automatic attachment delivery, or permanent storage of all communications.
Email automation should begin in:
• read and classify mode
• draft-only mode
• human-approved send mode
Automatic send should be limited to approved low-risk cases with tested controls.
Pages Created
• None
Pages Updated
• MWMS Client Communication Automation Framework updated from v1.1 to v1.2
Pages Deprecated
• None
Standalone Pages Not Created
The following standalone pages were not created because their durable intelligence is governed within this updated framework:
• MWMS RAG Assisted Email Communication Framework
• MWMS AI Email Writer Framework
• MWMS Email Thread Retrieval Framework
• MWMS Email Recipient Safety Standard
• MWMS AI Email Approval And Send Framework
• MWMS Email Communication Intelligence Framework
• MWMS Email Commitment Detection Framework
• MWMS Historical Email Context Framework
Registries Requiring Update
• MCR Page Registry
• AIBS Brain Page Registry
• MCR Copy Map where the framework version is recorded
• MWMS Course Absorption Decision Registry
Canon Version Update Required
No immediate AIBS Brain Canon version change is required unless the Canon directly records framework versions or contains communication rules that conflict with v1.2.
The new email retrieval, recipient safety, thread control, draft-versus-send, attachment, commitment, and memory-update controls should be included during the next scheduled AIBS Brain Canon alignment review.
Change Log Entry Required
Yes.
The v1.2 update must be recorded in:
• MWMS System Change Log
• MCR Page Registry change history where applicable
• AIBS Brain Page Registry change history where applicable
• MWMS Course Absorption Decision Registry
Strategic Absorption Result
The AI Automations by Jack material concerning RAG-assisted email drafting, historical email retrieval, automatic response generation, Gmail workflows, and communication intelligence has been absorbed into the existing MWMS Client Communication Automation Framework.
The absorption preserves the durable email and relationship-intelligence architecture while rejecting:
• unrestricted mailbox ingestion
• automatic sending by default
• entire-mailbox context dumping
• draft permission being treated as send authority
• historical statements being treated as current truth
• private correspondence being reproduced without need
• wrong-recipient and reply-all risk being ignored
• unsupported commercial commitments
• attachment delivery without validation
• generic AI-generated client communication
• AI summaries becoming permanent facts without review
The resulting v1.2 framework establishes that MWMS client communication automation must be:
• channel-aware
• identity-aware
• client-isolated
• thread-aware
• retrieval-grounded
• memory-controlled
• recipient-safe
• commitment-aware
• approval-gated
• tool-confirmed
• human-sounding
• handoff-ready
• outcome-tracked
• continuously improved through controlled review
END OF FULL FILE OUTPUT