MWMS AI Plugin Orchestration Framework

System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.1
Primary Location: MCR
Future Operational Destination: HeadOffice Brain, MWMS Brain, Brain Room, AI Manager, AI Employee Router, Task Executor Systems, Course Absorption System, Newsletter Intelligence, Opportunity System, Automation Brain, 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-18
Source / Origin: MWMS AI Plugin Orchestration Framework v1.0 + AI Automations by Jack — Multi-Agent Tool Use, Model Routing, Persistent Agents, Independent Review, Rescue Routing, External Knowledge And Session Continuity Block
MWMS Classification: AI Tool Orchestration Framework / Plugin Governance Framework / Controlled Tool-Chain Standard / AI Workflow Integration Framework
Primary Brain: HeadOffice Brain
Supporting Brains: MWMS Brain, Automation Brain, Operations Brain, Data Brain, Risk Brain, Compliance Brain, SIT Brain, AIBS Brain
Related Pages: MWMS AI Agent Operations Core, MWMS AI Agent Skill Library Framework, MWMS AI Multi Agent Role Design Framework, MWMS AI Exchange Zone And Dependency Control Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Workflow Pipeline Standard, MWMS Agentic Work Unit Standard, MWMS AI Output Validation Standard, MWMS AI Agent Failure Handling And Escalation Protocol, MWMS AI Ambiguity And Partial Failure Containment Framework, MWMS AI Agent Outcome Measurement Framework, MWMS AI Agent Memory And Context Framework, MWMS AI Employee Handoff Protocol, MWMS Brain Routing Rule, MWMS Brain To Brain Request Protocol
Source Evidence: The existing framework defines how MWMS governs plugins, tools, APIs, integrations and automation inside controlled AI workflows. The absorbed material strengthens the framework with explicit model routes, tool-result verification, multi-agent tool separation, independent review, deterministic rescue, persistent-agent controls, external knowledge retrieval boundaries, cost visibility and session continuity.

Purpose

The purpose of this document is to define the MWMS AI Plugin Orchestration Framework.

This framework explains how MWMS should use:

tools
plugins
connectors
APIs
integrations
automation platforms
model capabilities
external knowledge systems
persistent-agent services

inside controlled AI workflows.

MWMS must not treat plugins as magic.

A plugin is only useful when it is:

placed inside the correct workflow
assigned to the correct AI Employee
governed by the correct skill
limited by the correct permission
supplied with valid input
validated after execution
routed to the correct destination
measured by outcome

The purpose of plugin orchestration is to ensure tools are used as controlled workflow components rather than random add-ons.

This framework protects MWMS from:

tool overload
duplicated capability
unsafe automation
uncontrolled writes
hidden external action
excessive permissions
weak outputs entering operational systems
dashboard noise
AI Employees acting outside authority
false claims of tool execution
persistent agents continuing after failure
automation before manual proof
plugins replacing governance
broad and vague developer requests being handed to M

The goal is not to use more plugins.

The goal is to use the right tools, in the right sequence, under the right controls, for the right business outcome.

Scope

This framework applies to all plugin, connector, API, integration, model-tool and automation use across MWMS.

This includes tools and systems such as:

Gmail
Supabase
WordPress
MCR
Brain sites
Make.com
n8n
Google Sheets
Google Drive
Google Calendar
Google Ads
BeMob
OpenAI tools
Claude tools
Gemini tools
local model tools
data-analysis tools
file-analysis tools
dashboard tools
reporting tools
web research tools
external knowledge systems
document processors
client systems
future AIBS client workflow tools

This framework applies to:

HeadOffice Brain
Brain Room
AI Manager
AI Employee Router
Task Executor systems
Dev Console
Newsletter Intelligence
Course Absorption
Opportunity System
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
Operations Brain
Automation Brain
Risk Brain
Compliance Brain
SIT Brain
AIBS Brain
future AIBS client systems

This framework applies to:

manual tool-assisted workflows
draft-only workflows
supervised workflows
controlled-write workflows
scheduled workflows
persistent-agent workflows
future client-facing workflows

This framework does not authorise immediate development.

It defines how plugin and tool use must be governed before implementation or automation.

Core Definition

AI Plugin Orchestration is the controlled arrangement of tools, models, plugins and integrations inside an AI workflow.

Plugin orchestration defines:

which tool is used
why the tool is required
which workflow stage it supports
which AI Employee may use it
which skill governs use
what input the tool receives
what action is permitted
what permission level applies
what output is expected
how execution is verified
how output is validated
which reviewer is required
where the output goes
what must be logged
when execution must stop
what failure threshold applies
what Rescue Route applies
what human approval is required
what outcome should result

Plugin orchestration turns tools into governed workflow components.

Without orchestration, tools become scattered capabilities.

With orchestration, tools become controlled operating assets.

Core Principle

The core principle of this framework is:

Plugins add capability. Orchestration makes capability safe and useful.

A plugin by itself does not create business value.

A plugin creates value only when connected to:

a clear Work Unit
an Owning Brain
a defined AI Employee role
a governed skill
a workflow stage
a Context Pack
a Tool Permission Record
a validation gate
a handoff destination
a failure path
a Rescue Route
an outcome record
a closure state

In MWMS, tools must serve the workflow.

The workflow must not be rebuilt around whatever plugin happens to be available.

Tool, Skill And Authority Separation

MWMS must separate three concepts.

Tool

The capability available to the AI Employee.

Examples:

read email
inspect file
query database
create draft
calculate
retrieve source
update record

Skill

The procedure explaining how the capability should be used.

Examples:

Newsletter Signal Filtering Skill
MCR Duplicate Risk Check Skill
Developer Handoff Precision Skill
Offer Evidence Separation Skill

Authority

The level of action the AI Employee is allowed to take.

Examples:

observe
recommend
draft
validate
approve within delegated scope
execute approved action
commit validated knowledge

Rule

Having a tool does not imply having the skill or authority to use it operationally.

Plugin Orchestration Layers

MWMS plugin orchestration has fifteen layers:

Workflow Need
Tool Selection
AI Employee Assignment
Skill Match
Model Or Capability Route
Permission Boundary
Input Preparation
Tool Execution
Execution Verification
Output Validation
Independent Review
Handoff And Routing
Failure And Rescue
Logging And Cost Visibility
Outcome And Learning
Workflow Need

Every plugin must begin with a real workflow need.

Ask:

What problem does this tool solve?
What workflow stage does it support?
What happens without the tool?
Does it save time?
Does it improve quality?
Does it reduce risk?
Does it create a better outcome?
Can the work remain manual?

Examples:

Gmail read supports newsletter intake.
Supabase controlled write supports approved record creation.
WordPress read supports page validation.
File analysis supports course absorption.
Spreadsheet analysis supports finance review.
External knowledge retrieval supports source-grounded research.

Workflow Need Rule

Do not add a plugin because it exists.

Add it because the workflow needs it.

Tool Selection

Tool selection must consider:

reliability
cost
risk
data access
privacy
security
integration complexity
output quality
logging capability
current MWMS architecture
vendor lock-in
existing capability
shutdown control

Tool Selection Rule

Select the simplest tool that safely supports the workflow.

Do not automate a safe manual step merely because automation is possible.

AI Employee Assignment

A plugin must be assigned to a defined AI Employee role.

Examples:

Newsletter Signal Extraction Agent may use Gmail read.
Course Absorption Agent may use uploaded-file review.
HeadOffice Validation Agent may use WordPress page-list evidence.
Finance Analysis Agent may use spreadsheet analysis.
Persistent Monitoring Agent may inspect approved recurring sources.

AI Employee Assignment Rule

Tools belong to defined roles, not generic AI.

If no AI Employee owns the tool use, the orchestration is not operationally ready.

Skill Match

The AI Employee must have the correct procedural skill.

Gmail access alone is insufficient.

The Newsletter Signal Extraction Agent also needs:

Newsletter Signal Filtering Skill
Messy Input Normalization Skill
Brain Routing Skill
Dashboard Readiness Skill

WordPress read access alone is insufficient.

The Validation Agent also needs:

MCR Duplicate Risk Check Skill
Page Parent Validation Skill
MCR Structure Check Skill

Skill Match Rule

A tool gives access.

A skill defines correct use.

Model Or Capability Route

The orchestration must identify the model or capability required.

Possible requirements include:

low-cost extraction
advanced reasoning
long-context analysis
multimodal review
coding capability
private local processing
independent model review
deterministic schema validation
Rescue Agent route

Model selection should consider:

complexity
risk
privacy
cost
speed
context length
modality
independence requirement

Model Route Rule

Use the weakest capable route for safe bulk work and stronger routes where reasoning, risk or independence requires them.

Permission Boundary

Every plugin must have a permission boundary.

Permission states may include:

No Access
Provided Input Only
Read Only
Draft Only
Controlled Write
Supervised External Action
Restricted Low-Risk Autonomous Action

Permission must define:

approved actions
forbidden actions
approved targets
human approval stage
validation requirement
logging requirement
credential boundary
stop conditions
escalation destination
revocation path

Permission Boundary Rule

No plugin may bypass the MWMS AI Tool Permission And Access Framework.

Input Preparation

Before a plugin receives input, the input must be prepared.

Preparation may include:

cleaning
normalization
source-completeness checking
noise removal
sensitive-data identification
Source Of Truth identification
required-field checking
workflow classification
risk classification
client-boundary filtering

Input Preparation Rule

Dirty, ambiguous or unauthorised input must not silently enter operational tool chains.

Tool Execution

Tool execution is where the approved action occurs.

Possible actions include:

read
retrieve
extract
analyse
classify
summarise
format
draft
calculate
insert
update
label
route
trigger

Execution must remain within:

assigned role
approved skill
permission boundary
workflow stage
authorised target
approval rule
risk level
logging rule

Tool Execution Rule

Execution must be narrow, controlled and traceable.

Execution Verification

A tool response is not automatically proof that the intended action occurred.

Execution verification should confirm:

tool invoked
approved action requested
correct target used
permission valid
response received
error state checked
resulting system state confirmed
intended business effect assessed

Examples:

Generated SQL is not a database update.
A draft is not a sent email.
A page output is not a published WordPress page.
An API success response does not prove the target state is correct.
A tool call is not proof of business outcome.

Execution Verification Rule

No material tool action should be marked completed without evidence from the affected system.

Output Validation

Tool output must be validated before operational use.

Validation may check:

completeness
source grounding
source authority
correct fields
schema match
Brain routing
priority
urgency
duplicate risk
risk level
permission compliance
human-review requirement
dashboard readiness
developer safety
client safety

Output Validation Rule

Plugin output is not trusted merely because a tool produced it.

Independent Review

Independent review may be required where plugin output affects:

MCR
money
paid traffic
compliance
credentials
live systems
destructive actions
public content
client delivery
major architecture

Independent review may use:

a different AI Employee
another Brain
a different model family
deterministic checks
a human reviewer

Independent Review Rule

The producing agent must not be the only final reviewer for high-risk plugin actions.

Handoff And Routing

After validation, tool output must be routed.

Possible destinations:

HeadOffice review
Newsletter Queue Review
Routed Actions
Brain Room
AI Manager
Task Executor
MCR page draft
Research Brain
Finance Brain
Experimentation Brain
Ads Brain
Content Brain
M
Parking System
Archive
Human Review Queue
AIBS Client Review

Handoff Rule

Plugin output must have a destination, owner and next action.

Otherwise the tool has created noise.

Failure And Rescue

Every orchestration must define:

expected failure modes
retry limit
containment action
failure owner
escalation path
Rescue Route
restart condition

The standard Rescue Threshold is:

Two materially identical failures without verified progress.

At the threshold:

stop the original route
freeze the Work Unit
preserve source, output and logs
create a Rescue Packet
assign a materially different route
define a new verification gate

Failure And Rescue Rule

Repeated failure must trigger a changed route, not endless repetition.

Logging And Cost Visibility

Important tool use should record:

Work Unit ID
AI Employee
model route
tool used
action attempted
permission level
target
input source
result
validation status
failure count
cost where available
handoff
outcome
approval
closure

Cost may include:

model usage
API charges
automation-platform usage
tool subscription
human review
retry and rework
developer time

Logging And Cost Rule

MWMS should know what the orchestration did, what it cost and whether the result justified continued use.

Outcome And Learning

An orchestration should define its intended outcome.

Possible outcomes:

useful signal extracted
task created
source verified
risk reduced
time saved
report improved
record created safely
client action clarified
repeated manual work reduced

Learning may include:

tool quality
failure pattern
prompt improvement
skill improvement
permission reduction
validation improvement
automation readiness
retirement decision

Outcome Rule

Tool activity is not success.

The orchestration succeeds only when it produces a verified and proportionate business outcome.

Plugin Orchestration Patterns

Pattern 1 — Read → Extract → Validate → Route

Used for:

newsletters
research sources
offer pages
course files
page lists

Pattern 2 — Clean → Summarize → Format → Validate

Used for:

transcripts
client documents
meeting notes
support logs

Pattern 3 — Read → Compare → Decide → Log

Used for:

duplicate-page checks
offer comparisons
version comparisons
experiment reviews

Pattern 4 — Draft → Independent Review → Human Approval → Controlled Write

Used for:

MCR
developer instructions
client reports
database records
dashboard actions

Pattern 5 — Detect Failure → Contain → Rescue → Revalidate → Learn

Used for:

parser failure
wrong routing
missing fields
repeated model failure
tool mismatch
persistent-agent degradation

Pattern 6 — Analyze → Score → Recommend → Handoff

Used for:

finance
offer evaluation
experiment results
dashboard prioritisation

Pattern 7 — Retrieve → Preserve Provenance → Reason → Review

Used for:

external knowledge systems
policy research
client evidence
market intelligence

Pattern 8 — Monitor → Qualify → Alert → Human Decision

Used for:

persistent agents
market monitoring
system-health monitoring
future client monitoring

Pattern 9 — Plan → Build → Review → Validate → Commit

Used for:

multi-agent content
documentation
structured client deliverables
MCR outputs

Plugin Categories And MWMS Use

Intake Tools

Purpose:

Capture or receive input.

Examples:

Gmail
forms
file uploads
Brain Room intake
webhooks

Risk:

Medium.

Required controls:

normalization
source tracking
completeness checks
duplicate checks

Storage Tools

Purpose:

Store structured data.

Examples:

Supabase
Google Sheets
WordPress
client databases

Risk:

Medium to high.

Required controls:

schema validation
controlled writes
logging
approval where required
rollback

Document Processing Tools

Purpose:

Extract, clean, summarize or format documents.

Examples:

PDF processors
transcript tools
file analysis
HTML parsers

Risk:

Medium.

Required controls:

source grounding
missing-data disclosure
output validation
provenance preservation

Analysis Tools

Purpose:

Analyse data, numbers and patterns.

Examples:

spreadsheet tools
finance calculators
traffic analysis
experiment analysis

Risk:

High where money is affected.

Required controls:

explicit assumptions
source verification
validation
human review

Publishing And Communication Tools

Purpose:

Publish, send or externally communicate.

Examples:

WordPress publishing
email send
social publishing
client delivery

Risk:

High to critical.

Required controls:

draft-first operation
approval
final validation
execution verification
audit trail

Automation Tools

Purpose:

Move work automatically.

Examples:

Make.com
n8n
queue processors
webhook routes

Risk:

High where routing or writing occurs.

Required controls:

manual proof
stop conditions
failure threshold
shutdown control
logs
rescue

Dashboard Tools

Purpose:

Display reviewable intelligence.

Examples:

HeadOffice dashboards
queue screens
routed-action panels
status views

Risk:

Medium.

Required controls:

validation
owner
current status
action readiness
noise suppression

External Knowledge Tools

Purpose:

Retrieve evidence from approved knowledge sources.

Examples:

search
vector retrieval
Notebook-style knowledge systems
client knowledge stores
approved data sources

Risk:

Medium to high.

Required controls:

provenance
source authority
freshness
client filtering
conflict detection
reasoning separation

Persistent-Agent Tools

Purpose:

Support scheduled or background AI Employees.

Examples:

scheduled monitoring
recurring reports
background exception detection
remote-agent channels

Risk:

High where continuous access or external action exists.

Required controls:

owner
schedule
cost limit
failure count
alert threshold
shutdown control
stale-context detection

Client System Tools

Purpose:

Operate within future AIBS client environments.

Examples:

client CRM
support inbox
reporting system
client database
workflow platform

Risk:

High to critical.

Required controls:

client isolation
least privilege
approval gates
audit logs
data-retention rules
revocation
no cross-client context

Plugin Orchestration Record Template

Orchestration ID:

Orchestration Name:

Work Unit ID:

Workflow Supported:

Workflow Stage:

Owning Brain:

Supporting Brains:

AI Employee Responsible:

AI Employee Authority Level:

Plugin Or Tool Used:

Tool Category:

Workflow Need:

Skill Required:

Required Model Or Capability:

Permission Record Required:

Approved Access Level:

Approved Target:

Forbidden Actions:

Input Required:

Input Source:

Source Authority:

Input Preparation Required:

Tool Action:

Expected Tool Output:

Expected System State:

Execution Verification Required:

Validation Required:

Validation Owner:

Independent Review Required:

Human Review Required:

Handoff Destination:

Owner Of Next Action:

Logging Required:

Cost Tracking Required:

Stop Conditions:

Failure Triggers:

Retry Limit:

Rescue Route:

Restart Condition:

Expected Outcome:

Outcome Evidence:

Knowledge Commitment Required:

Closure Requirement:

Orchestration Status:

Last Tested:

Last Reviewed:

Quick Use Version

Orchestration ID:

Orchestration Name:

Workflow Supported:

Owning Brain:

AI Employee Responsible:

Plugin Or Tool:

Workflow Need:

Skill Required:

Model Or Capability:

Approved Access Level:

Input Required:

Tool Action:

Expected Output:

Execution Verification:

Validation:

Independent Review:

Human Review:

Handoff Destination:

Logging:

Stop Conditions:

Failure Threshold:

Rescue Route:

Expected Outcome:

Outcome Evidence:

Orchestration Status:

Example 1 — Newsletter Gmail To Structured Intelligence Orchestration

Orchestration Name:

Newsletter Gmail To Structured Intelligence Orchestration

Workflow Supported:

Newsletter Intelligence Workflow

Owning Brain:

HeadOffice Brain

AI Employee Responsible:

Newsletter Signal Extraction Agent

Plugin Or Tool Used:

Gmail, AI extraction tool, structured parser and approved storage tool

Workflow Need:

Capture newsletters, extract business-relevant signals and create reviewable records.

Skill Required:

Newsletter Signal Filtering Skill

Approved Access Level:

Gmail Read Only
controlled internal record creation
controlled Gmail label update after verified success

Input Required:

sender
subject
body
snippet
date
metadata

Input Preparation:

remove noise
check body completeness
preserve source
classify newsletter type

Tool Action:

Read, extract, structure and prepare a record.

Expected Tool Output:

Newsletter Intelligence Record.

Execution Verification:

Confirm the record exists and source metadata was preserved before labelling the email processed.

Validation Required:

Operational Validation.

Human Review Required:

Before material downstream action.

Handoff Destination:

Newsletter Queue Review.

Stop Conditions:

incomplete body
parser failure
schema mismatch
generic output
high-risk unverified signal

Rescue Route:

Alternate extraction route or human review after two materially identical failures.

Expected Outcome:

Useful external intelligence becomes reviewable without dashboard noise.

Orchestration Status:

Assisted Use

Example 2 — Course Transcript To MCR Draft Orchestration

Orchestration Name:

Course Transcript To MCR Draft Orchestration

Workflow Supported:

Course Absorption Workflow

Owning Brain:

HeadOffice Brain

AI Employee Responsible:

Course Absorption Agent

Plugin Or Tool Used:

Uploaded-file analysis and document drafting

Approved Access Level:

Provided Input Only / Draft Creation

Input Required:

complete course source
lesson or block identity
current absorption save point
relevant MCR evidence

Input Preparation:

normalize source
preserve provenance
remove noise
identify missing material

Tool Action:

Extract reusable system value and compare it against current MCR.

Expected Tool Output:

Absorb
Update Existing Page
Create New Page
Park
Ignore
Reject

or approved full page output.

Validation Required:

Operational Validation.

Human Review Required:

Before MCR save.

Stop Conditions:

incomplete source
MCR comparison unavailable
duplicate risk unresolved
weak value
wrong Brain mapping
M’s work affected

Expected Outcome:

MWMS improves without unnecessary page creation.

Orchestration Status:

Manual Use

Example 3 — Developer Evidence To M Handoff Orchestration

Orchestration Name:

Developer Evidence To M Handoff Orchestration

Workflow Supported:

Developer Support Workflow

Owning Brain:

HeadOffice Brain

AI Employee Responsible:

Developer Support Agent

Plugin Or Tool Used:

Screenshot review, file review and current-system evidence

Approved Access Level:

Provided Input Only / Draft Creation

Input Required:

exact request
current screenshot
current file where relevant
current save point
developer boundary

Tool Action:

Prepare an exact Developer Handoff Package.

Expected Tool Output:

exact site
exact location
exact change
what not to touch
test steps
expected result
rollback where relevant

Validation Required:

High-Risk Validation.

Independent Review Required:

Where live-system risk exists.

Human Review Required:

Always.

Stop Conditions:

file missing
current state unclear
M would need to guess
unrelated systems may be affected

Expected Outcome:

M can act safely without reconstructing the problem.

Orchestration Status:

Manual Use

Example 4 — External Knowledge To Reasoning Orchestration

Orchestration Name:

External Knowledge Retrieval To Reasoning Orchestration

Workflow Supported:

Research And Evidence Workflow

Owning Brain:

Research Brain

AI Employee Responsible:

External Knowledge Retriever Agent

Plugin Or Tool Used:

Approved search, retrieval or knowledge system

Approved Access Level:

Read Only

Input Required:

research question
source-authority requirement
freshness requirement
project or client boundary

Tool Action:

Retrieve relevant evidence and preserve provenance.

Expected Tool Output:

Evidence Packet containing:

source identity
authority
freshness
relevant evidence
conflicts
gaps

Validation Required:

Source and provenance validation.

Handoff Destination:

Analyst or specialist reasoning agent.

Stop Conditions:

weak source authority
missing provenance
stale evidence
client-boundary uncertainty
conflicting evidence unresolved

Expected Outcome:

Reasoning receives traceable evidence without confusing retrieval with decision authority.

Orchestration Status:

Manual Use / Assisted Use

Example 5 — Persistent Monitoring Orchestration

Orchestration Name:

Persistent Monitoring And Qualified Alert Orchestration

Workflow Supported:

Recurring Monitoring Workflow

Owning Brain:

HeadOffice Brain or relevant specialist Brain

AI Employee Responsible:

Persistent Monitoring Agent

Plugin Or Tool Used:

Approved scheduled agent and source connector

Approved Access Level:

Read Only / Qualified Alert Creation

Input Required:

approved source
monitoring rule
schedule
current baseline
alert threshold
owner
cost limit

Tool Action:

Monitor approved source and create an alert only when the threshold is met.

Expected Tool Output:

qualified alert
no-change record
failure record

Validation Required:

Alert validation.

Human Review Required:

Before material action.

Stop Conditions:

stale source
repeated false alerts
failure threshold reached
cost limit exceeded
owner unavailable
permissions unclear

Rescue Route:

Pause and route to human owner or alternate monitoring path.

Expected Outcome:

Meaningful changes surface without continuous noise.

Orchestration Status:

Controlled Automation Candidate

Plugin Orchestration Governance Rules

Rule 1 — Workflow Before Plugin

The workflow defines the need.

The plugin supports the workflow.

Rule 2 — Role Before Tool

A defined AI Employee must own operational tool use.

Rule 3 — Skill Before Action

The role must possess the procedure needed to use the tool correctly.

Rule 4 — Permission Before Access

No permission record means no operational tool use.

Rule 5 — Clean Input Before Processing

Unprepared input must not enter downstream tool chains.

Rule 6 — Least Privilege

Use the lowest access level required.

Rule 7 — Validation Before Routing

Tool output must be validated before entering dashboards, MCR, developer tasks, live systems or client workflows.

Rule 8 — Independent Review For High-Risk Actions

The producing route cannot be the only final reviewer.

Rule 9 — Human Review Before High-Risk Action

Human review remains mandatory before:

external action
client delivery
paid traffic
MCR Canon change
live-system change
developer implementation
finance decision
compliance-sensitive output
destructive action

Rule 10 — Verify Execution

A tool response must be checked against the affected system state.

Rule 11 — Logging Before Expansion

An orchestration must be observable before it scales.

Rule 12 — Failure Handling Before Automation

Known failure modes, stop conditions and Rescue Routes must exist.

Rule 13 — Cost Visibility Before Persistent Use

Scheduled or high-volume orchestration must expose total cost.

Rule 14 — Outcome Before More Tools

Do not expand the tool chain until current use creates measurable value.

Rule 15 — Shutdown Before Persistence

Persistent agents must remain stoppable.

Rule 16 — Client Isolation

Client tools, credentials, data and context must remain separated.

Rule 17 — Knowledge Commitment Requires Approval

Tool output must not become durable organisational truth without validation and correct authority.

Plugin Orchestration Readiness Checklist

Before orchestration moves forward, check:

Is the workflow need clear?
Is the tool necessary?
Is the simplest safe tool selected?
Is the Owning Brain clear?
Is the responsible AI Employee defined?
Is the Work Unit defined?
Is the required skill defined?
Is the model or capability route appropriate?
Is the permission record available?
Is the access level narrow enough?
Is the target clear?
Are forbidden actions clear?
Is input preparation defined?
Is the source authoritative enough?
Is the action narrow and specific?
Is expected output defined?
Is expected system state defined?
Is execution verification defined?
Is validation required?
Is independent review required?
Is human review required?
Is the handoff destination clear?
Is the next owner clear?
Is logging defined?
Is cost tracking required?
Are stop conditions listed?
Is failure handling defined?
Is the retry limit defined?
Is the Rescue Route defined?
Is the restart condition defined?
Is the expected outcome clear?
Is outcome evidence defined?
Is knowledge commitment governed?
Is closure defined?
Has manual proof occurred?
Does this affect M’s active work?
Is a developer brief required?
Is automation premature?

If several answers remain unclear, the orchestration is not ready.

Common Plugin Orchestration Failure Modes

Plugin orchestration has failed when:

a tool is added without workflow need
generic AI receives broad tool access
no AI Employee owns the action
no skill governs use
permissions are excessive
input is unprepared
source authority is ignored
model route is unsuitable
tool output is accepted without validation
tool response is mistaken for outcome
output has no destination
human review is skipped
independent review is fake
logging is missing
cost is invisible
stop conditions are absent
failure counts reset without progress
Rescue Route repeats the failed method
persistent agent continues after degradation
dashboard noise increases
M receives broad tool ideas instead of exact work
a tool writes to the wrong system
client data crosses boundaries
automation expands before manual proof
unvalidated output becomes durable knowledge

Manual Use Rule

This framework should be used manually before plugin orchestration becomes technical infrastructure.

Manual use helps MWMS determine:

which tools are genuinely needed
which workflows benefit from tools
where read-only access is enough
where draft-only access is enough
where controlled write is justified
where validation must be stronger
where independent review adds value
where tool output fails
where Rescue Routes are needed
where automation is premature
which orchestrations should remain manual
which orchestrations may later become exact developer briefs

Manual orchestration proof comes before build.

Future Plugin Or UI Relevance

This framework may later support:

AI Plugin Orchestration Registry
AI Manager tool-chain configuration
AI Employee Router tool selection
Task Executor tool rules
Brain Room tool-assisted Work Units
Newsletter Intelligence governance
Course Absorption document processing
HeadOffice orchestration dashboard
independent-review queues
Rescue Agent routing
persistent-agent control
AIBS client orchestration panels

Possible future fields:

orchestration_id

orchestration_name

work_unit_id

workflow_supported

workflow_stage

owning_brain

supporting_brains

responsible_ai_employee

ai_employee_authority_level

plugin_or_tool_used

tool_category

workflow_need

skill_required

required_model_capability

permission_record_required

approved_access_level

approved_target

forbidden_actions

input_required

input_source

source_authority

input_preparation_required

tool_action

expected_tool_output

expected_system_state

execution_verification_required

validation_required

validation_owner

independent_review_required

human_review_required

handoff_destination

owner_next_action

logging_required

cost_tracking_required

stop_conditions

failure_triggers

retry_limit

rescue_route

restart_condition

expected_outcome

outcome_evidence

knowledge_commitment_required

closure_requirement

orchestration_status

last_tested

last_reviewed

created_at

updated_at

No technical build is authorised by this framework alone.

Governance Role

HeadOffice owns the MWMS AI Plugin Orchestration Framework.

HeadOffice is responsible for:

approving orchestration principles
preventing tool sprawl
preventing unsafe automation
ensuring plugins serve workflows
ensuring tool use belongs to defined roles
ensuring skills govern tool use
ensuring permission records exist
ensuring validation gates exist
governing independent review
preserving human approval
requiring execution verification
requiring logging and cost visibility
governing failure thresholds and Rescue Routes
protecting M’s active build
protecting MCR
protecting persistent-agent workflows
protecting future AIBS client systems

Individual Brains may propose plugin orchestrations.

HeadOffice governs:

cross-Brain orchestration
high-risk tool use
write-enabled workflows
external-action workflows
persistent agents
client-facing workflows
automation-related orchestration

Relationship To SIT Brain

SIT Brain may:

verify orchestration-record completeness
verify tool-permission alignment
detect excessive permissions
verify model-route suitability
verify execution evidence
detect false completion
enforce validation gates
verify reviewer independence
verify failure thresholds
trigger Rescue Routing
pause unsafe persistent agents
block unapproved knowledge commitment

Relationship To Data Brain

Data Brain supports:

Orchestration IDs
Work Unit linkage
tool records
model-route records
permission records
execution logs
cost records
validation results
failure counts
Rescue Packets
handoff records
outcome evidence
status history
closure records

Relationship To Other MWMS Standards

This framework supports and must align with:

MWMS AI Agent Operations Core
MWMS AI Agent Skill Library Framework
MWMS AI Multi Agent Role Design Framework
MWMS AI Exchange Zone And Dependency Control Framework
MWMS AI Employee Role Card Standard
MWMS AI Employee Capability Stack Framework
MWMS AI Tool Permission And Access Framework
MWMS AI Agent Memory And Context Framework
MWMS Agentic Work Unit Standard
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 Agent Failure Handling And Escalation Protocol
MWMS AI Agent Outcome Measurement Framework
MWMS AI Ambiguity And Partial Failure Containment Framework
MWMS AI Agent Deployment Readiness Checklist
MWMS AI Workforce Governance Model
MWMS Brain Routing Rule
MWMS Brain To Brain Request Protocol
MWMS Supabase Event Schema
AIBS Brain Blueprint

This framework adds the controlled tool-chain layer to the MWMS AI Agent Operations Core.

Drift Protection

This framework protects MWMS from:

treating plugins as strategy
adding tools without workflow need
letting access replace skill
allowing generic AI to use powerful tools
granting write access too early
accepting plugin output without validation
assuming tool execution without evidence
automating unproven workflows
creating dashboard noise
triggering external action without review
operating persistent agents without shutdown
expanding automation without stop conditions
hiding tool and model costs
sending M vague tool ideas
mixing client systems or data
allowing plugin excitement to override MCR governance
measuring tool count instead of business outcomes
creating tool chains that MWMS cannot audit

Plugin Orchestration Drift Signals

MWMS should watch for:

no Orchestration ID
no Work Unit ID
workflow need unclear
role ownership unclear
skill missing
model route unexplained
permission record missing
target unclear
forbidden actions absent
input source unclear
source authority missing
expected system state undefined
execution unverified
validation missing
independent review missing
handoff destination missing
owner missing
logs unavailable
cost invisible
stop conditions absent
failure threshold absent
Rescue Route absent
expected outcome vague
knowledge commitment uncontrolled
closure missing

Rule

Plugin orchestration drift must be corrected before greater access or automation is granted.

Minimum Compliance Standard

A material Plugin Orchestration Record is compliant only when it defines:

Orchestration ID
Work Unit ID
workflow
workflow stage
Owning Brain
AI Employee
AI Employee authority
tool
tool category
workflow need
skill
model or capability
permission record
access level
target
forbidden actions
input
source
source authority
preparation
action
expected output
expected system state
execution verification
validation
validation owner
independent review
human review
handoff
next owner
logging
cost tracking
stop conditions
failure triggers
retry limit
Rescue Route
restart condition
expected outcome
outcome evidence
knowledge commitment
closure
current status

Architectural Intent

The architectural intent of the MWMS AI Plugin Orchestration Framework is to make tool use structured, safe and outcome-driven.

MWMS may eventually use many tools.

The strength of MWMS will not come from tool access alone.

It will come from the way those tools are governed inside controlled workflows.

The long-term goal is that every material plugin use can answer:

Why is this tool needed?
Which workflow does it support?
Which AI Employee owns it?
Which skill governs it?
Which model route is required?
What authority does the AI Employee hold?
What permission applies?
What input does the tool receive?
What source authority applies?
What action does the tool perform?
What system state should change?
How is execution verified?
How is output validated?
Is independent review required?
Where does the result go?
Who owns the next action?
What is logged?
What does the tool cost?
When does the workflow stop?
What triggers rescue?
What outcome does the orchestration create?
What knowledge may be committed?
How does the Work Unit close?

When MWMS can answer those questions, plugins become controlled capabilities rather than operational risk.

Strategic Summary

The v1.1 update expands the MWMS AI Plugin Orchestration Framework from a basic controlled-tool framework into a complete orchestration-governance layer.

The updated framework now governs:

model and capability routes
role, skill and authority separation
execution verification
independent review
deterministic failure thresholds
Rescue Routes
persistent-agent tools
external knowledge tools
cost visibility
client isolation
knowledge commitment
formal closure

The key shift is:

A tool action is not successful because the tool ran.

It is successful only when the correct role used the correct tool, under the correct permission, produced a validated result and created a verified business outcome.

Final Rule

Plugins add capability.

Orchestration makes capability safe and useful.

No workflow need, no justified tool.

No role owner, no operational tool use.

No skill, no reliable procedure.

No permission, no access.

No execution evidence, no action claim.

No validation, no operational trust.

No independent review, no high-risk approval.

No failure threshold, no controlled recovery.

No verified outcome, no business value.

Change Log

Version: v1.1
Date: 2026-06-18
Author: HeadOffice

Change:

Updated the MWMS AI Plugin Orchestration Framework using the AI Automations by Jack block covering multi-agent tool use, model routing, persistent agents, independent review, Rescue Routing, external knowledge systems, execution verification and session continuity.

Added:

Tool, Skill And Authority Separation
Model Or Capability Route
Execution Verification
Independent Review
Failure And Rescue
Logging And Cost Visibility
Outcome And Learning
Retrieval orchestration pattern
persistent-monitoring pattern
Plan, Build, Review, Validate and Commit pattern
External Knowledge Tools
Persistent-Agent Tools
expanded Plugin Orchestration Record Template
Relationship To SIT Brain
Relationship To Data Brain
Plugin Orchestration Drift Signals
Minimum Compliance Standard
Strategic Summary
Final Rule

Expanded:

Purpose
Scope
Core Definition
orchestration layers
tool categories
examples
governance rules
readiness checklist
failure modes
future fields
governance role
drift protection
architectural intent

Corrected canonical references from AI Business Systems Brain to AIBS Brain.

Purpose of update:

To evolve the MWMS AI Plugin Orchestration Framework from a general plugin-governance model into the complete controlled tool-chain layer for model routing, permissions, execution verification, independent review, persistent agents, Rescue Routing, cost visibility, outcomes and safe future AIBS tool use.

Version: v1.0
Date: Initial Draft
Author: HeadOffice

Change:

Created the MWMS AI Plugin Orchestration Framework to define how MWMS governs tools, plugins, APIs, integrations and automation inside controlled AI workflows.

Change Impact Declaration

This v1.1 update expands the AI Plugin Orchestration Framework from a ten-layer tool-governance model into a broader orchestration framework covering model routes, tool-result verification, independent review, persistent agents, failure rescue, external knowledge, cost visibility and outcome verification.

Pages Created

None

Pages Updated

MWMS AI Plugin Orchestration Framework

Pages Deprecated

None

Standalone Pages Not Created

MWMS Tool Execution Verification Standard

MWMS Persistent Agent Tool Orchestration Standard

MWMS External Knowledge Tool Orchestration Standard

MWMS Plugin Cost Visibility Standard

MWMS Plugin Rescue Routing Protocol

Registries Requiring Update

None confirmed by the supplied source.

Canon Version Update Required

Change Log Entry Required

Yes

Strategic Absorption Result

MWMS gains a stronger plugin-orchestration framework that ensures tools, plugins, models, connectors and automations operate only inside defined roles, skills, permissions, validation gates, failure controls and outcome requirements.

END OF FULL FILE OUTPUT