MWMS AI Agent Failure Handling And Escalation Protocol

System: MWMS
Document Type: Protocol
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.1
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Newsletter Intelligence, Course Absorption System, Opportunity System, AIBS Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-17

Purpose

The purpose of this document is to define the MWMS AI Agent Failure Handling And Escalation Protocol.

This protocol establishes how MWMS identifies, classifies, contains, records, escalates, rescues and learns from failures inside:

AI Employee workflows
Brain workflows
task pipelines
model-routing systems
validation systems
tool-use workflows
handoffs
reporting systems
background agents
remote command channels
automated workflows
future client-facing AIBS systems

MWMS is being designed as a governed AI workforce system.

A governed workforce must not assume every AI output, workflow, route, tool call, model choice or task will succeed.

AI systems can fail in many ways.

They may:

misunderstand the task
receive poor input
route to the wrong Brain
assign the wrong AI Employee
use an unsuitable model
produce vague output
invent unsupported details
skip validation
exceed authority
duplicate existing work
expose credentials
create unsafe recommendations
repeat the same failed action
loop without progress
fail to hand off correctly
lose source provenance
misreport what was actually done
continue operating after risk exceeds authority

This protocol exists so MWMS can treat failure as part of the operating system rather than as a surprise.

The goal is not to eliminate every failure.

The goal is to:

detect failure early
stop repeated failure loops
contain possible damage
preserve evidence
route work to the correct rescue path
escalate to the correct authority
validate the correction
convert failure into system learning

Core Principle

The core principle of this protocol is:

AI failure must be detected, contained, escalated, logged, rescued and converted into system learning.

Failure is not only a problem.

Failure is a signal.

A failure shows where one or more of the following may need improvement:

role card
model selection
workflow sequence
prompt
validation rule
handoff
input process
routing rule
tool permission
review route
source retrieval
authority boundary
automation design
monitoring
escalation policy

MWMS must not hide failures.

MWMS must not allow the same reasoning path to repeat indefinitely without progress.

MWMS must use failure evidence to make the system stronger.

Scope

This protocol applies to all MWMS workflows where AI performs, supports, validates, routes, reports, retrieves, writes, automates or executes work.

This includes:

HeadOffice Brain
Brain Room
AI Manager
AI Employee Router
Task Executor systems
Dev Console
Newsletter Intelligence
Course Absorption
Offer Evaluation
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Strategy Brain
Data Brain
Operations Brain
AIBS Brain
SIT Brain
Supabase task and event systems
MCR page creation workflows
developer support workflows
persistent background agents
scheduled routines
remote command channels
MCP-connected tools
external knowledge systems
future client-facing AIBS workflows

This protocol applies to:

manual workflows
assisted workflows
controlled automated workflows
supervised agentic workflows
restricted autonomous workflows

Core Definition

An AI Agent Failure is any event where an AI Employee, model, workflow, Brain, task pipeline, tool call, validation step, report, handoff, retrieval system or automation does not produce a safe, useful, accurate, complete, properly routed or operationally valid result.

A failure may be obvious.

Examples:

output is wrong
task crashes
automation errors
data is missing
validation fails
deployment fails
a tool call is rejected

A failure may also be subtle.

Examples:

output sounds good but is generic
report has no business action
insight goes to the wrong Brain
AI invents a page that does not exist
task is marked complete but nothing useful happened
dashboard item creates noise
handoff loses important context
AI oversteps its authority
weak course material enters the Blueprint
M receives vague instructions
model claims it checked a system it could not access
the same failed action is repeated with different wording
a reviewer agrees without conducting an independent assessment

Both obvious and subtle failures matter.

MWMS must detect and handle both.

Failure Is Not Progress

MWMS must not mistake activity for progress.

The following do not count as verified progress:

repeating the same command
rewriting the same recommendation
starting a new chat with the same failed assumptions
changing wording without changing the result
increasing response length
expressing greater confidence
trying a nearly identical edit
asking the same model to self-review
stating that the issue is understood
continuing to act after the same validation gate fails

Verified progress requires objective evidence that the task has moved closer to completion.

Examples include:

a failing test now passes
a prior error is resolved
a required output is now complete
a missing source is retrieved
a validation gate passes
a factual conflict is resolved
an authorised reviewer confirms correction
a different recovery path produces measurable improvement

Why Failure Handling Matters

As MWMS grows, AI will perform more work.

More AI work means more possible failure points.

Without failure handling, MWMS risks:

trusting bad outputs
routing work incorrectly
duplicating pages
wasting Martyn’s time
wasting M’s time
wasting advertising budget
missing compliance risks
exposing credentials
sending weak work to dashboards
breaking live systems
confusing clients
losing important context
repeating the same mistakes
scaling unreliable workflows
allowing agents to loop
allowing low-quality model routing
hiding unresolved uncertainty
treating retrieval as truth
allowing autonomous workflows to continue after failure

With failure handling, MWMS gains:

safer automation
better validation
clear escalation
controlled rescue routing
better role boundaries
stronger workflows
more reliable dashboards
cleaner developer instructions
improved AI Employee design
better Kaizen learning
higher trust in the system

Failure handling is therefore a core operating layer.

Failure Categories

MWMS recognises the following major categories of AI failure.

Input Failure

Input Failure occurs when an AI Employee receives poor, incomplete, noisy, corrupted, unclear or insufficient input.

Examples:

uploaded file is incomplete
transcript is badly formatted
newsletter body is truncated
screenshot does not show enough context
sales page data is missing
course lesson lacks the core content
user instruction is ambiguous
Supabase row lacks required fields
copied text contains junk or broken formatting
media source has no usable transcript
retrieval returns only partial context

Common causes:

messy input was not normalised
ingestion failed
source quality was not checked
required fields were not enforced
source identity was lost

Required response:

pause processing
identify missing or weak input
request more input where needed
normalise again
mark assumptions clearly
preserve source identity
do not generate final output from weak input

Escalation trigger:

Input weakness affects:

MCR source of truth
developer instructions
finance
compliance
offer testing
client output
system architecture
high-risk decisions

Classification Failure

Classification Failure occurs when the system misunderstands what type of work is being requested.

Examples:

course absorption is treated as a general summary
developer support is treated as strategy advice
newsletter signal is treated as generic news
offer evaluation is treated as copywriting
Brain Room chat is not converted into a task
finance issue is routed to Affiliate Brain only
compliance risk is missed
a rescue request is treated as a normal retry
a review request is treated as production work

Common causes:

weak request classification
missing routing rules
vague task definition
incorrect assumptions

Required response:

correct the classification
identify the correct workflow type
reassign owning Brain
revise the Agentic Work Unit
log recurring classification error
review whether downstream work must be discarded

Escalation trigger:

Wrong classification could affect:

business decisions
live systems
paid traffic
compliance
M’s work
MCR structure
client work
autonomous execution

Brain Routing Failure

Brain Routing Failure occurs when work is assigned to the wrong Brain or supporting Brains are missed.

Examples:

offer is evaluated without Finance Brain
ad compliance issue is routed only to Content Brain
research evidence is not sent to Research Brain
HeadOffice visibility is skipped on cross-Brain work
Content Brain receives an item that belongs to Ads Brain
Experimentation Brain is skipped before testing
Data Brain is skipped when source integrity is involved
SIT Brain is skipped when enforcement is required

Common causes:

unclear Brain ownership
weak routing logic
ownership conflict
Brain naming drift

Required response:

pause or reroute the task
identify correct owning Brain
identify supporting Brains
update handoff
correct routing record
verify whether previous outputs remain valid

Escalation trigger:

Any routing failure involving:

cross-Brain work
finance
compliance
paid traffic
MCR
live systems
client systems
system governance

Role Boundary Failure

Role Boundary Failure occurs when an AI Employee performs work outside its role card or authority.

Examples:

Validation Agent makes a final business decision
Reporting Agent creates tasks without approval
Course Absorption Agent creates pages from weak material
Offer Evaluation Agent approves ad spend
Research Agent treats assumptions as facts
Brain Room Task Builder executes instead of structuring
Orchestrator Agent overrides HeadOffice
AI Employee approves its own high-risk output

Common causes:

unclear role card
ignored authority level
broad prompts
excessive tool access
model overreach

Required response:

stop the output from becoming final
review the role card
revise the task boundary
reroute to the correct AI Employee or human
add forbidden actions if needed
inspect tool permissions
log repeated role drift

Escalation trigger:

Any role boundary failure involving:

live systems
money
compliance
public content
developer work
MCR source of truth
client-facing work
permissions
irreversible action

Model Routing Failure

Model Routing Failure occurs when the wrong model, reasoning route or specialist capability is assigned.

Examples:

a weak model is assigned high-risk reasoning
a text-only model is assigned image analysis
the same model is used as sole creator and reviewer
a failed model is repeatedly retried
a low-cost model is used where capability is insufficient
a premium model is used for unnecessary bulk work
privacy-sensitive work is sent to an unsuitable hosted service
a reviewer lacks the domain capability required

Common causes:

convenience-based routing
cost-only routing
missing capability classification
no independent-review rule
no fallback route
no failure counter

Required response:

stop the route if material risk exists
select a suitable model or specialist
preserve prior output and failure history
apply independent review where required
update model-routing rules
record fallback or reduced review strength

Escalation trigger:

Model-routing failure affects:

governance
compliance
finance
security
architecture
live systems
client output
repeated task failure

Tool Permission Failure

Tool Permission Failure occurs when an AI Employee uses, assumes or recommends tool access beyond its permitted boundary.

Examples:

AI claims it checked Supabase when it did not
AI implies a WordPress page was updated when it only drafted text
AI recommends database writes without approval
AI sends external communication outside permission
AI uses current web assumptions without verification
AI suggests changing live plugin files without confirmed context
AI exposes raw credentials
portable skill contains active cookies or secrets
remote command channel allows unrestricted execution

Common causes:

unclear tool permission
excessive access
weak credential custody
AI overclaiming access
missing approval gates
poor endpoint governance

Required response:

stop the unauthorised action
correct the claim
mark what was actually done
require human or tool verification
revoke or reduce permissions if needed
protect exposed credentials
update tool-permission boundaries
log the failure

Escalation trigger:

Any Tool Permission Failure involving:

live systems
data changes
external communication
client systems
financial action
M’s development work
authentication
secrets
remote execution

Output Quality Failure

Output Quality Failure occurs when the AI output is incomplete, vague, generic, inaccurate, poorly structured or not useful.

Examples:

report is long but does not say what to do
summary misses the key system value
page draft does not follow MWMS structure
output lacks Brain mapping
output has no verdict
output has no next action
developer instruction is vague
course absorption output summarises instead of extracting frameworks
full page output omits required metadata
output invents a parent page

Common causes:

weak task instruction
missing output standard
insufficient validation
source material not reviewed
format drift
model overconfidence

Required response:

revise output
apply output validation checklist
request clearer structure
assign Validation Agent or human review
improve task instruction or role card
inspect whether prior output caused downstream errors

Escalation trigger:

Output concerns:

MCR
developer implementation
offer decisions
finance
compliance
paid traffic
client-facing work
system governance

Source Grounding Failure

Source Grounding Failure occurs when the AI output is not properly supported by source material or current system evidence.

Examples:

AI invents facts not in the file
AI references a page not confirmed to exist
AI exaggerates course content
AI treats vendor claims as verified evidence
AI uses old memory as current truth
AI assumes data not present in screenshots
AI claims a file was read when it was not
AI gives legal, financial or platform advice without verification
AI treats semantic retrieval as authority
AI ignores current Canon in favour of weaker material

Common causes:

poor validation
missing source citation
failure to inspect uploaded content
over-reliance on memory
weak retrieval
source-authority confusion
stale information

Required response:

stop unsupported output from progressing
separate evidence from assumptions
inspect the actual source
correct unsupported claims
verify the page, file, record or system
mark uncertainty clearly
apply current authority hierarchy
log serious grounding failures

Escalation trigger:

Any source-grounding failure involving:

high-risk work
client-facing work
live systems
MCR
user trust
finance
compliance
current facts
governance

Validation Failure

Validation Failure occurs when output fails a validation check or required validation is skipped.

Examples:

high-risk output has no human review
dashboard item is shown without usefulness check
offer verdict lacks finance review
MCR page is created without duplication check
developer instruction lacks exact file path
newsletter item is routed without priority validation
reviewer only repeats the original conclusion
same model self-approves mandatory review
a failed gate is bypassed

Common causes:

workflow lacks validation gate
validation rule ignored
reviewer lacks independence
pressure for speed
authority confusion

Required response:

stop workflow progression
apply required validation
assign an independent reviewer where required
revise or reject output
log validation failure
update pipeline if failure is repeated

Escalation trigger:

Any skipped or invalid validation for high-risk or critical-risk workflows.

Handoff Failure

Handoff Failure occurs when work moves to another Brain, Employee, human, queue, system or project without enough context.

Examples:

M receives incomplete instructions
Research Brain receives offer task without source
dashboard item has no next action
Brain Room request is answered but not logged
course absorption output has no page placement
finance review receives no assumptions
task moves to completed without clear outcome
rescue model receives no failure history
next session lacks a save point

Common causes:

missing handoff package
incomplete session closure
no destination
source material omitted
status not recorded

Required response:

rebuild handoff
include source, status, risk, next action and owner
preserve failure history
confirm receiver
log handoff issue where important
prevent downstream execution until context is complete

Escalation trigger:

Developer, finance, compliance, MCR, client or cross-Brain handoff failures.

Outcome Failure

Outcome Failure occurs when AI work produces output but no meaningful business result.

Examples:

report has no decision
summary has no next step
dashboard item creates no action
course absorption produces notes but no Blueprint upgrade
offer evaluation does not route to reject, park, research or test
task completes but does not move the system forward
workflow creates activity but no measurable outcome
model consensus produces no final authority decision

Common causes:

weak reporting
missing outcome definition
poor workflow design
no handoff destination
no decision state

Required response:

define the required outcome
revise report or task
route to decision state
park or reject if no outcome exists
simplify the workflow if complexity adds no value

Escalation trigger:

Repeated Outcome Failure in the same workflow.

Automation Failure

Automation Failure occurs when an automated workflow breaks, misfires, loops, sends bad data, duplicates records or runs before the process is stable.

Examples:

Make.com scenario fails
Supabase insert is incomplete
Gmail labels do not update
queue record misses fields
automated task is created incorrectly
dashboard displays duplicates
workflow runs on bad input
AI loops without final decision
persistent agent continues after repeated failure
webhook triggers the wrong workflow
scheduled routine produces uncontrolled output

Common causes:

automation added before manual workflow stabilised
weak error handling
poor data mapping
missing validation
missing stop condition
no failure counter
no monitoring

Required response:

pause automation if needed
identify failing module or stage
confirm last good state
preserve original input
test with small controlled input
restore safe state
update logging
avoid broad changes until the failure is isolated
verify stop and rollback controls

Escalation trigger:

Automation affects:

live data
dashboards
user-facing systems
M’s active build
client systems
money
external communication
repeated autonomous failure

Governance Failure

Governance Failure occurs when AI work bypasses HeadOffice, MCR, Brain ownership, review rules, developer boundaries or system standards.

Examples:

new standard created without placement clarity
Brain creates workflow outside HeadOffice visibility
M’s build area is touched by unrelated work
page naming rules are ignored
MCR source of truth is bypassed
course content is absorbed without value testing
client workflow is proposed without approval gates
invented parent page is used
Canon is changed without authority
AI agreement is treated as final authority

Common causes:

rushing
unclear authority
missing governance check
failure to inspect source-of-truth records
role drift

Required response:

pause workflow
identify violated standard
correct structure
escalate to HeadOffice
update drift protection if needed
review affected downstream outputs

Escalation trigger:

All Governance Failures must be visible to HeadOffice.

Repeated Failure Loop

Repeated Failure Loop occurs when the same agent, model or workflow repeats materially similar failed actions without verified progress.

Examples:

same test failure twice
same command error twice
same rejected output issue twice
same unsuccessful edit twice
same validation gate failure twice
same recommendation repeated without resolving the problem
user correction ignored repeatedly
agent cycles between the same actions

Common causes:

no failure counter
no rescue route
self-review dependency
preserved bad assumptions
weak monitoring
agent persistence without control

Required response:

stop materially identical retries
freeze the current task state
preserve full failure history
trigger rescue routing
assign a different model, specialist or deterministic validator
require a materially different recovery plan
define the next verification gate

Escalation trigger:

The second materially identical failure is the standard rescue threshold unless a stricter workflow rule applies.

Knowledge Commitment Failure

Knowledge Commitment Failure occurs when completed work, decisions, corrections or save points are not preserved correctly.

Examples:

session ends without a save point
draft is described as published
user correction is not retained
completed course block is not logged
decision is lost in chat history
unverified material is committed as truth
duplicate memory is created
deprecated material is stored as active
next action is vague

Common causes:

no closure protocol
no durable destination
weak verification
reliance on temporary chat context
no duplicate check

Required response:

reconstruct the session state
distinguish completed from attempted work
identify durable outcomes
commit to the correct destination
verify the save
label unverified material
define exact next action

Escalation trigger:

Commitment failure affects:

Canon
MCR
project continuity
high-risk decisions
client work
developer handoff
repeated user corrections

Failure Severity Levels

MWMS classifies failures by severity.

Level 1 — Minor Failure

Low impact.

Examples:

small formatting issue
minor wording problem
incomplete non-critical section
low-risk output needs polish

Required response:

revise
validate locally
no escalation unless repeated

Level 2 — Moderate Failure

Workflow usefulness is affected, but no major risk exists.

Examples:

report too generic
missing Brain mapping
weak handoff
low-risk classification error
course output needs stronger extraction
low-risk model-routing inefficiency

Required response:

revise
apply validation
log if repeated
update instruction if recurring

Level 3 — Serious Failure

Could affect system quality, decisions, MCR, development or business direction.

Examples:

wrong Brain routing
unsupported claim in important output
weak developer instruction
duplicate MCR page risk
skipped validation
bad dashboard item
offer verdict missing risk review
repeated failure loop
false claim of system access
incorrect page ownership or parent

Required response:

stop progression
escalate to HeadOffice or human review
preserve evidence
revise before use
log failure
assess affected downstream outputs

Level 4 — Critical Failure

Could affect live systems, money, compliance, public content, client trust or irreversible data.

Examples:

unsafe live-system change
wrong database write
external email sent incorrectly
paid traffic decision based on bad data
compliance-sensitive mistake
client-facing report error
critical automation misfire
exposed credentials
unrestricted remote execution
destructive action without approval

Required response:

stop workflow immediately
contain damage
revoke access where needed
escalate to HeadOffice and relevant human
preserve evidence
correct or roll back where possible
log failure
create Kaizen improvement
review workflow before restart

Standard Failure Handling Flow

When failure is detected, MWMS must follow this flow:

Detect the failure.
Freeze the current output or task state.
Classify the failure category.
Assign severity level.
Pause the workflow where required.
Contain possible damage.
Preserve source material, logs and attempt history.
Identify likely cause.
Determine whether revision, rerouting, rescue, parking, rejection or escalation is required.
Assign an owner.
Correct the output, route or workflow.
Validate the correction.
Obtain independent review where required.
Resume only after the failed gate passes.
Log the failure.
Capture the lesson.
Update the relevant role card, prompt, pipeline, checklist, permission rule or standard.

Failure handling must be structured.

Do not just try again blindly.

Failure Counter Rules

Each repeatable task or workflow must maintain a failure count where practical.

The failure count increases when:

the same test fails for materially the same reason
the same command returns the same unresolved error
the same output is rejected for the same issue
the same validation gate fails
the same edit produces no measurable improvement
the agent returns to a rejected approach without new evidence
the same user correction is ignored again

The failure count does not reset merely because:

wording changes
the task is moved into a new chat
the model expresses more confidence
the command is slightly reformatted
the agent claims it understands
another explanation is supplied
the same model performs a self-review

The failure count resets only after:

verified progress
a materially changed task
a confirmed environmental change
successful completion of the failed gate
authorised human reset with recorded reasoning

Deterministic Rescue Threshold

The standard MWMS rescue threshold is:

Two materially identical failures without verified progress.

At the threshold:

the originating route must stop
failure history must be preserved
the task must be transferred to a different reasoning route
a materially different recovery method must be used
the next verification gate must be defined

A stricter task-specific threshold may apply.

Rescue Routing Protocol

The rescue packet must contain:

original task
expected outcome
owning Brain
current state
exact failure
failure count
chronological attempt history
commands, tools or methods used
outputs produced
validation results
assumptions made
source material
user instructions
applicable Canon
affected files, pages or records
current risk
point where progress stopped

The rescue route may use:

a different model family
a specialist AI Employee
a domain reviewer
deterministic testing
independent evidence review
human escalation
reduced-scope recovery

The rescue model or reviewer must not simply be told to try again.

It must be instructed to:

diagnose independently
identify inherited assumptions
challenge the prior approach
propose a materially different path
identify missing evidence or tools
state whether the task should continue
define the next verification gate

Rescue Escalation Levels

Level 1 — Alternative Reasoning Pass

Use a different reasoning role, context or method.

Level 2 — Different Model Rescue

Transfer to a different model family or reasoning architecture.

Level 3 — Specialist Rescue

Route to a domain-specific AI Employee, Brain or reviewer.

Level 4 — Deterministic Validation

Use tests, schemas, calculations, rule engines or direct source verification.

Level 5 — Human Escalation

Escalate to Martyn, HeadOffice, M or another authorised human.

Higher-risk tasks may begin at a higher rescue level.

Failure Decision States

After review, a failure must receive one of the following decisions.

Revise

The output has value but needs correction.

Use when:

incomplete
vague
wrong format
missing section
needs better Brain mapping

Reroute

The work belongs somewhere else.

Use when:

wrong Brain
wrong AI Employee
wrong model
wrong workflow
wrong destination

Revalidate

The output may be usable but must pass stronger validation.

Use when:

risk is higher than expected
source grounding is weak
human approval is required
decision impact is significant
reviewer independence is insufficient

Rescue

The current reasoning route is no longer permitted to continue alone.

Use when:

repeated failure threshold reached
agent loop detected
current route lacks required capability
materially different reasoning is needed

Park

The work may be useful later but should not move now.

Use when:

timing is wrong
system is not ready
M’s build area would be affected
more evidence is needed
current priority is elsewhere

Reject

The output should not be used.

Use when:

weak value
unsupported
duplicate
unsafe
wrong direction
not MWMS relevant
correction cost exceeds value

Escalate

The issue requires HeadOffice, Martyn, M, a specialist Brain or human review.

Use when:

high-risk
compliance-sensitive
live-system related
developer-sensitive
financial
client-facing
ownership unclear
authority unresolved
reviewers disagree materially

Escalation Rules

Escalation is required when failure affects:

MCR source of truth
HeadOffice governance
M’s active build areas
developer implementation
live systems
Supabase writes
WordPress updates
external emails
paid traffic decisions
finance decisions
compliance-sensitive material
public-facing content
client-facing outputs
cross-Brain ownership
repeated workflow failures
unclear authority
tool permission boundaries
credentials
remote execution
persistent autonomous agents
unresolved reviewer disagreement

Escalation protects the system from compounding errors.

Escalation Destinations

Escalate To Martyn

Use when:

strategic decision required
MCR page should be approved
course absorption value is uncertain
offer test decision needed
budget or risk decision needed
business direction affected
human judgement required
final authority remains with Martyn

Escalate To HeadOffice

Use when:

cross-Brain governance issue
routing conflict
dashboard quality issue
system standard issue
workflow design issue
repeated AI failure
AI Employee role boundary issue
model-routing policy issue
rescue policy issue
authority conflict
system-wide drift

Escalate To M

Use when:

technical implementation issue
code, plugin, API, Supabase, WordPress or live-system behaviour affected
testing required
file-level review needed
developer save point impacted
rollback or deployment assessment required

Escalate To SIT Brain

Use when:

integrity gate failed
mandatory review was skipped
role drift occurred
failure threshold was bypassed
unsafe execution must be blocked
Canon or authority may have been violated
repeated failure is not being escalated

Escalate To Validation Agent

Use when:

output quality is uncertain
source grounding needs checking
Brain routing needs review
risk level needs assessment
output may be usable after validation

Escalate To Research Brain

Use when:

more evidence required
source claims are uncertain
market data is missing
vendor claims need verification
current information is required
retrieved evidence conflicts

Escalate To Finance Brain

Use when:

budget impact exists
break-even logic needed
financial risk exists
scaling decision is involved
investment decision is involved

Escalate To Compliance Brain Or Risk Review

Use when:

advertising policy risk exists
legal or privacy issue exists
health or finance claims are involved
client-facing risk exists
platform policy uncertainty exists
regulated communications are involved

Independent Review Rules

Independent review is required where failure affects:

governance
Canon
finance
compliance
system integrity
security
live deployment
external communication
destructive action
disputed evidence
repeated model failure

The model that produced the failed output must not be the sole final reviewer.

Independent review may require:

a different model family
a specialist AI Employee
a separate Brain
deterministic testing
blind evidence review
human review

Self-review may support correction.

It does not satisfy mandatory independent-review requirements.

Disagreement Resolution

Where reviewers disagree, MWMS must determine whether the disagreement concerns:

facts
source authority
interpretation
risk tolerance
task definition
authority
missing evidence
execution preference

Resolution order:

Check current Canon.
Check source evidence.
Run deterministic validation.
Request specialist review.
reduce the disagreement to the smallest unresolved question.
Escalate to the authorised human where required.

Majority vote must not override:

Canon
objective evidence
authority
compliance
safety requirements

Failure Log Record

Important failures must be logged.

A Failure Log Record should include:

Failure ID:

Failure Title:

Date:

Source:

Workflow:

Task ID:

Owning Brain:

Supporting Brains:

AI Employee:

Model Route:

Tool Used:

Failure Category:

Severity Level:

Failure Count:

What Went Wrong:

Cause:

Evidence Preserved:

Immediate Action Taken:

Containment Status:

Rescue Route:

Escalation Destination:

Final Decision:

Correction Applied:

Validation Status:

Independent Review Status:

Human Approval Status:

Affected Outputs Or Systems:

Learning Captured:

Related Standard Updated:

Status:

Failure logging allows MWMS to improve instead of repeating errors.

Failure Learning Loop

Every meaningful failure should feed the MWMS Kaizen loop.

The failure learning loop is:

Reflect

Reduce

Refine

Record

Reflect

Ask:

What failed?
Why did it fail?
Was the problem input, classification, routing, role boundary, model selection, prompt, validation, handoff, tool permission, retrieval, authority or automation?
Was the failure detectable earlier?
Was the workflow too complex?
Was the system allowed to continue too long?

Reduce

Ask:

How can MWMS reduce the chance of repeat failure?
Can the workflow be simplified?
Can a prompt be tightened?
Can a required field be added?
Can a validation gate be added?
Can a role boundary be clarified?
Can the failure threshold be lowered?
Can a deterministic test replace subjective review?
Can tool permissions be reduced?

Refine

Update the relevant:

AI Employee role card
Agentic Work Unit template
workflow pipeline
validation checklist
model-routing rule
failure counter
rescue route
handoff template
reporting standard
normalisation process
developer instruction rule
dashboard filter
tool permission
knowledge commitment rule

Record

Log the learning.

Possible destinations:

Kaizen Log
System Change Log
Brain-specific Canon
Course Absorption Decision Registry
Newsletter Intelligence Signal Log
Experimentation learning records
Research Brain records
SIT log
developer save point notes
AI Employee performance record

Application To Course Absorption

Course absorption failure occurs when MWMS absorbs weak, duplicated, generic or tool-specific material that does not improve the system.

Failure examples:

summarising course instead of extracting system value
creating too many pages
duplicating existing standards
absorbing tool hype
missing a valuable framework
failing to map to the correct Brain
failing to verify existing pages
inventing a parent page
failing to identify what should be ignored
marking a block complete before decisions are finished

Required response:

stop page creation
re-check current MCR inventory
revise extraction
apply Course Absorption System v2
check duplication
park weak material
absorb only clear system upgrades
correct ownership and parent structure
log the exact save point

Course failure rule:

Course material must not enter MWMS source of truth unless it improves MWMS and has been correctly routed.

Application To Newsletter Intelligence

Newsletter failure occurs when low-value or generic information becomes dashboard noise.

Failure examples:

vague insights
wrong Brain routing
false urgency
generic AI news
missing recommended action
weak priority logic
duplicate signals
useful trend not captured

Required response:

tighten extraction prompt
improve validation
adjust action classification
route weak items to parking
log recurring pattern failures
prevent weak items from reaching the command layer

Newsletter failure rule:

Newsletter intelligence must be specific enough to act on or it should not reach the command layer.

Application To Brain Room

Brain Room failure occurs when useful conversation is not converted into structured work.

Failure examples:

important instruction not logged
task not created
wrong Brain assigned
AI replies casually when task structure is needed
developer boundary missed
no follow-up destination
repeated context lost
failure history omitted from rescue

Required response:

create or repair the Agentic Work Unit
assign owning Brain
define next action
log important context
preserve corrections
escalate if development-sensitive

Brain Room failure rule:

Brain Room must not lose operational value inside chat flow.

Application To M Developer Support

Developer failure is high risk.

Failure examples:

vague file instructions
wrong site referenced
exact insertion point missing
screenshot ignored
save point not respected
unrelated systems touched
partial file output given when full file required
testing steps missing
AI claims a system change occurred without verification

Required response:

stop implementation handoff
rebuild developer instruction
anchor to visible evidence
include exact file, path or screen
include what not to touch
include testing steps
preserve save point
require confirmation of actual execution

Developer failure rule:

If M has to guess, the AI output has failed.

Application To Offer Evaluation

Offer evaluation failure can waste money.

Failure examples:

vendor hype trusted
compliance risk missed
traffic fit ignored
finance review skipped
YES verdict given too easily
weak market evidence
test budget not considered
experimentation handoff omitted
unsupported claims treated as fact

Required response:

reroute to Research, Finance, Ads, Compliance or Experimentation Brain
revise verdict
require evidence
preserve uncertainty
escalate to HeadOffice before testing

Offer failure rule:

No offer should move toward spend without evidence, risk review and financial logic.

Application To AIBS Client Systems

Client-facing AI failure can damage trust.

Failure examples:

confusing report
unsupported recommendation
unsafe automation
missing approval gate
poor input cleanup
client data misread
unclear next action
automation acts before approval
cross-client data leakage
tool access exceeds scope
agent continues after failure

Required response:

stop client-facing action
validate source and output
require human approval
simplify report
contain any exposure
log failure
update client workflow controls
verify permissions before restart

AIBS failure rule:

Client-facing AI workflows must fail safely, clearly and with human review where needed.

Application To Persistent And Background Agents

Persistent-agent failure occurs when an agent continues running without adequate control.

Failure examples:

repeated scheduled failure
endless polling
duplicate work
silent tool errors
unbounded cost
no alert after failure
no shutdown method
unattended high-risk action
background process acts on stale instructions

Required response:

pause or terminate the agent
preserve logs
identify last good state
review trigger and permissions
enforce failure threshold
correct monitoring
require approval before restart

Persistent-agent failure rule:

No background agent may continue indefinitely after repeated failure or unresolved risk.

Failure Prevention Checklist

Before a workflow runs, check:

Is the input clean enough?
Is the task classified correctly?
Is the owning Brain clear?
Is the AI Employee role defined?
Is the task inside the role boundary?
Is the model route appropriate?
Are tool permissions clear?
Are credentials protected?
Are forbidden actions clear?
Is the output format defined?
Is source grounding required?
Is validation required?
Is independent review required?
Is human review required?
Is the handoff destination clear?
Is the business outcome clear?
Is logging required?
Is knowledge commitment required?
Are known failure modes documented?
Is a failure counter required?
Is the rescue route defined?
Is this safe for the current build stage?
Does this affect M’s active work?
Does HeadOffice need visibility?
Is automation premature?
Is escalation path clear?
Can the workflow be stopped safely?
Can changes be rolled back?

Human Review Rule

Human review is mandatory when failure affects:

MCR source of truth
live systems
developer implementation
Supabase writes
WordPress changes
external emails
paid traffic decisions
financial decisions
compliance-sensitive outputs
public-facing content
client-facing output
high-risk automation
cross-Brain governance
M’s active build areas
credentials
destructive actions
unresolved model disagreement
authority

Human review may be optional for low-risk internal drafting failures.

Automation Failure Rule

Automation must fail safely.

Automated workflows should be designed so that failure does not automatically cause damage.

Automation should:

stop on missing required fields
mark failed validation clearly
avoid creating downstream tasks from weak output
preserve original input
log error state
notify or surface review need
avoid repeated looping
avoid overwriting good data with bad data
enforce retry limits
support rollback where possible
preserve last good state
provide shutdown controls
restrict tool scope
avoid silent fallback to unsafe methods

Automation rule:

Automated AI workflows must pause safely when confidence, validation, input quality, authority or permissions are insufficient.

Credential And Security Failure Rule

Where a failure may expose credentials, secrets or protected data, MWMS must:

stop the affected workflow
prevent further access
revoke or rotate credentials where appropriate
preserve evidence securely
identify exposed systems
inspect logs
restrict restart
escalate to HeadOffice and relevant technical authority
record the incident
update access controls

Credentials must not be embedded in portable skills, prompts or reusable knowledge records.

Source And Retrieval Failure Rule

Where retrieval or source access fails:

the AI must not guess
the unavailable source must be identified
confidence must be reduced
an approved fallback may be attempted
execution must be restricted where evidence is insufficient
the failure must be logged where material

Retrieval failure does not create permission to fabricate.

Governance Role

HeadOffice owns the MWMS AI Agent Failure Handling And Escalation Protocol.

HeadOffice is responsible for:

defining failure categories
setting severity levels
approving escalation paths
approving rescue policy
ensuring failures are logged
ensuring repeated failures create system improvements
protecting MCR from weak or failed outputs
protecting M’s active build areas
protecting dashboards from unreliable intelligence
protecting future client systems from unsafe automation
ensuring failure becomes learning
governing model-routing failure
governing persistent-agent failure
resolving authority conflicts

Individual Brains may define additional failure-handling rules for their own workflows, but those rules must align with this protocol.

Relationship To SIT Brain

SIT Brain may:

detect failure patterns
enforce validation gates
block execution
verify failure counters
trigger rescue routing
detect missing independent review
detect false completion claims
inspect failure logs
detect authority drift
detect tool-permission violations
require escalation
verify correction before restart

Relationship To Other MWMS Standards

This protocol supports and must align with:

MWMS AI Agent Operations Core
MWMS Agentic Work Unit Standard
MWMS AI Employee Role Card Standard
MWMS AI Agent Orchestration Framework
MWMS Independent Model Review And Rescue Routing Framework
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS Agentic Reporting Standard
MWMS AI Employee Handoff Protocol
MWMS AI Tool Permission And Access Framework
MWMS AI Observability Metadata Standard
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
MWMS AI Work Session Closure And Knowledge Commitment Protocol
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS AI Output Standard Full File Delivery Rule
MWMS Brain Header Schema Standard
MWMS Page Naming Standard
MWMS Document Structure Standard
MWMS Architecture Registry
MWMS Brain Interaction Map
MWMS System Data Flow Map
MWMS Supabase Event Schema
HeadOffice Newsletter Intelligence Operating Protocol
HeadOffice Newsletter Intelligence Output Validation Protocol
MWMS Course Absorption Operating Rule
MWMS Opportunity System Operating Protocol
AIBS Brain Blueprint

This protocol defines how MWMS handles failure across the systems, roles, workflows, models, reports, validation gates, tools and handoffs defined by those standards.

Drift Protection

This protocol protects MWMS from:

ignoring AI failures because outputs sound confident
repeating the same workflow mistakes
treating failed outputs as final
allowing weak course material into MCR
allowing vague developer instructions to reach M
allowing dashboard noise to accumulate
allowing wrong Brain routing to continue
skipping validation after failure
automating workflows that fail unsafely
hiding errors instead of logging them
over-trusting AI Employees outside their role boundaries
allowing model-routing failures to continue
letting tool-permission failures become live-system risks
treating activity as progress when outcomes fail
failing to escalate high-risk issues
allowing the same model to retry indefinitely
using self-review as independent review
exposing credentials through skill files
allowing persistent agents to run without shutdown controls
missing Kaizen improvements from repeated failures
losing save points after interrupted work
committing unverified failure conclusions as truth

Any workflow that repeatedly fails without producing system improvement must be reviewed, simplified, rescued or paused.

Prohibited Patterns

MWMS prohibits:

blind retry loops
unlimited repeated attempts
hiding prior failures from a rescue model
resetting failure counts without verified progress
self-approval of mandatory review
claiming tool access that did not occur
claiming publication or system change without verification
allowing failure logs to be deleted to make performance look better
bypassing human review for critical failures
allowing a weak fallback model to silently replace a required specialist
treating model consensus as authority
continuing automation after a critical gate fails
exposing secrets inside prompts or skills
treating retrieval failure as permission to guess
marking partial work as completed
handing off failure without the attempt history
restarting persistent agents without reviewing the failure cause
changing unrelated systems during recovery

Minimum Compliance Standard

A failed workflow is compliant only when:

the failure is detected
the task state is preserved
the category is assigned
severity is assigned
damage is contained
repeated failure count is checked
rescue is triggered at the required threshold
escalation follows authority
evidence is preserved
correction is validated
independent review is used where required
affected outputs are assessed
the failure is logged where material
a learning action is identified
restart occurs only after the failed gate passes

Architectural Intent

The architectural intent of the MWMS AI Agent Failure Handling And Escalation Protocol is to make MWMS resilient.

A serious AI business operating system must expect failure and handle it well.

The long-term goal is not a system that never fails.

The goal is a system where failures are:

detected early
contained safely
escalated correctly
rescued intelligently
logged clearly
corrected properly
independently reviewed where required
converted into learning
used to strengthen future workflows

MWMS should be able to answer the following questions for every meaningful failure:

What failed?
Where did it fail?
Which Brain owned it?
Which AI Employee was involved?
Which model and tools were involved?
What caused it?
How many times did it fail?
How severe was it?
Was the damage contained?
Was the original route stopped?
Who reviewed it?
Was rescue routing required?
What decision was made?
What was corrected?
What was validated?
What was logged?
What did MWMS learn?
What standard, workflow, role card, permission or validation rule should improve?

When MWMS can answer those questions consistently, failure stops being chaos.

Failure becomes intelligence.

Final Rule

When an AI workflow fails once, MWMS must diagnose it.

When the same route fails twice without verified progress, MWMS must stop the loop and trigger rescue routing.

When failure creates material risk, execution must pause.

When authority, evidence or safety remains unresolved, a human or authorised governance role must decide whether work may continue.

Source Absorption Basis

This v1.1 update absorbs the strongest failure-management material from the AI Automations by Jack course block covering:

deterministic failure counters
two-failure rescue thresholds
independent model review
no-self-review rules
specialist rescue routing
risk-path escalation
persistent-agent monitoring
remote-agent controls
credential custody
external knowledge failure handling
session closure and save-point recovery

Tool-specific promotional claims and transient product combinations were not absorbed as permanent MWMS operating rules.

Change Log

Version: v1.1
Date: 2026-06-17
Author: HeadOffice
Change: Expanded the MWMS AI Agent Failure Handling And Escalation Protocol to include model-routing failures, repeated-failure counters, deterministic two-failure rescue routing, independent review, persistent-agent failure controls, credential and security failures, retrieval failures, knowledge-commitment failures and stronger restart requirements.
Change Impact Declaration: Upgrades MWMS failure handling from general detection and escalation into a complete resilience system covering repeated failure loops, rescue routing, reviewer independence, tool access, persistent agents, source grounding and verified restart.

Pages Created

None

Pages Updated

MWMS AI Agent Failure Handling And Escalation Protocol

Pages Deprecated

None

Standalone Pages Not Created

MWMS Claude Failure Protocol
MWMS Two Failure Rule
MWMS Rescue Model Protocol
MWMS Persistent Agent Failure Standard
MWMS Model Retry Framework
MWMS Cowork Failure Protocol

Registries Requiring Update

HeadOffice Page Registry
MWMS Canon Index
MWMS Course Absorption Decision Registry

Canon Version Update Required

No immediate Canon version change required.

Change Log Entry Required

Strategic Absorption Result

MWMS gains a stronger resilience protocol that stops repetitive AI failure, preserves evidence, routes stalled work to a different reasoning path, protects high-risk systems and converts every meaningful failure into a governed improvement opportunity.

END OF FULL FILE OUTPUT