MWMS MCR

MWMS AI Plugin Orchestration Framework

System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
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, AI Business Systems Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR

Purpose

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

This framework explains how MWMS should use tools, plugins, integrations, APIs, automations, and external capabilities inside controlled AI workflows.

MWMS must not treat plugins as magic.

A plugin is only useful when it is placed inside the correct workflow, governed by the correct permission level, used by the correct AI Employee, validated before action, and measured by outcome.

The purpose of plugin orchestration is to ensure that AI tools are used as part of a controlled system, not as random add-ons.

This framework protects MWMS from:

  • tool overload
  • unsafe automation
  • uncontrolled writes
  • AI Employees acting outside authority
  • weak outputs being pushed into systems
  • dashboard noise
  • tool access without permission boundaries
  • automation before manual proof
  • plugins replacing governance
  • M being handed vague build ideas

The goal is not to use more plugins.

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

Scope

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

This includes tools 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
  • data analysis tools
  • file analysis tools
  • dashboard tools
  • reporting tools
  • plugin-based 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
  • AI Business Systems Brain
  • future AIBS client systems

This framework does not authorize immediate development work.

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

Core Definition

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

A plugin is an external capability.

Plugin orchestration defines:

  • which tool is used
  • why the tool is needed
  • which AI Employee may use it
  • what input the tool receives
  • what action the tool performs
  • what permission level applies
  • what output the tool returns
  • how that output is validated
  • what happens next
  • what must be logged
  • when the workflow must stop
  • what human approval is required

Plugin orchestration turns tools into workflow components.

Without orchestration, tools become scattered capabilities.

With orchestration, tools become governed 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 it is connected to:

  • a clear AI Employee role
  • a defined skill
  • a workflow pipeline
  • a context pack
  • a tool permission record
  • a validation gate
  • a handoff destination
  • a failure path
  • an outcome log

In MWMS, tools must serve the workflow.

The workflow must not be rebuilt around whatever plugin is available.

Plugin Orchestration Layers

MWMS plugin orchestration has ten layers:

  1. Workflow Need
  2. Tool Selection
  3. AI Employee Assignment
  4. Skill Match
  5. Permission Boundary
  6. Input Preparation
  7. Tool Execution
  8. Output Validation
  9. Handoff And Routing
  10. Logging And Learning

1. Workflow Need

Every plugin must start with a workflow need.

Ask:

  • What problem does this tool solve?
  • What workflow stage does it support?
  • What would happen without the tool?
  • Does this tool save time, improve quality, reduce risk, or create a better outcome?
  • Is tool use justified, or can the task be handled manually?

Examples:

  • Gmail read access supports newsletter intake.
  • Supabase write access supports internal record creation.
  • WordPress read access supports page validation.
  • File analysis supports course absorption.
  • Data analysis supports finance or experiment review.
  • Google Sheets supports structured campaign or content queues.

Workflow Need Rule:

Do not add a plugin because it exists. Add a plugin because the workflow needs it.

2. Tool Selection

Once the workflow need is clear, MWMS selects the tool.

Tool selection must consider:

  • reliability
  • cost
  • risk
  • data access
  • privacy
  • integration complexity
  • output quality
  • current MWMS architecture
  • whether WordPress/Supabase already covers the need
  • whether the tool creates vendor lock-in
  • whether the tool duplicates existing capability

Tool Selection Rule:

Select the simplest tool that safely supports the workflow.

If a low-risk manual step works, do not rush to plugin automation.

3. AI Employee Assignment

A plugin must be assigned to an AI Employee role.

Examples:

  • Newsletter Signal Extraction Agent may use Gmail read access.
  • Developer Support Agent may use uploaded file review.
  • Course Absorption Agent may use transcript file review.
  • HeadOffice Validation Agent may use WordPress page list review.
  • Finance Break Even Analysis Agent may use spreadsheet or data analysis tools.
  • Documentation Pipeline Agent may use file analysis, summarization, and formatting tools.

AI Employee Assignment Rule:

Tools must belong to roles, not generic AI.

If no AI Employee owns the tool use, the plugin should not be operational.

4. Skill Match

The AI Employee must have the correct skill for the tool use.

Example:

Gmail read access is not enough.

The Newsletter Signal Extraction Agent also needs:

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

WordPress page list access is not enough.

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.

Do not give tools to AI Employees that lack the procedural skill to use them.

5. Permission Boundary

Every plugin must have a permission boundary.

Permission boundaries 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
  • human approval stage
  • validation requirement
  • logging requirement
  • stop conditions
  • escalation destination

Permission Boundary Rule:

Tool access must follow the MWMS AI Tool Permission Record Template.

No plugin should bypass tool permission governance.

6. Input Preparation

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

This may include:

  • cleaning
  • normalization
  • source completeness check
  • removing noise
  • identifying sensitive data
  • identifying source of truth
  • identifying required fields
  • classifying workflow type
  • assigning risk level

Input Preparation Rule:

Plugins should not process dirty input unless their job is specifically to clean it.

Dirty input creates dirty output, even with powerful tools.

7. Tool Execution

Tool execution is the point where the plugin performs its action.

Possible actions include:

  • read
  • extract
  • analyze
  • classify
  • summarize
  • format
  • draft
  • insert
  • update
  • label
  • route
  • calculate
  • generate
  • trigger

Tool execution must stay within:

  • assigned role
  • approved skill
  • permission boundary
  • workflow stage
  • human approval rule
  • risk level
  • logging rule

Tool Execution Rule:

Execution must be narrow, controlled, and traceable.

8. Output Validation

Plugin output must be validated before use.

Validation may check:

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

Output Validation Rule:

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

All important tool outputs remain draft or review items until validated.

9. Handoff And Routing

After validation, the 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 developer handoff
  • Parking System
  • Archive
  • Human Review Queue
  • AIBS Client Review

Handoff Rule:

Plugin output must have a destination and owner.

If the output goes nowhere, the plugin has created noise.

10. Logging And Learning

Tool use must be logged when it affects important work.

Logging may include:

  • source processed
  • tool used
  • action performed
  • output created
  • validation result
  • status change
  • handoff created
  • failure detected
  • outcome created
  • human approval recorded

Learning may include:

  • tool output quality
  • repeated failure pattern
  • better prompt or skill needed
  • permission boundary too broad
  • validation rule needed
  • automation should stay manual
  • workflow ready for expansion

Logging And Learning Rule:

Tool use should improve MWMS understanding of what works and what should not be automated.

Plugin Orchestration Patterns

MWMS should use plugin orchestration patterns instead of random tool use.

Pattern 1: Read → Extract → Validate → Route

Used for:

  • newsletters
  • research sources
  • offer pages
  • uploaded course content
  • WordPress page lists

Example:

Gmail reads newsletter → AI extracts signal → validation checks specificity → routed to queue.

Pattern 2: Clean → Summarize → Format → Validate

Used for:

  • course transcripts
  • newsletters
  • client documents
  • messy notes
  • meeting notes
  • support logs

Example:

Transcript cleaned → summary created → formatted into report → validated before MCR or dashboard use.

Pattern 3: Read → Compare → Decide → Log

Used for:

  • duplicate page checks
  • offer comparisons
  • tool comparisons
  • document version comparisons
  • experiment result review

Example:

Two page versions reviewed → differences compared → keeper chosen → cleanup outcome logged.

Pattern 4: Draft → Human Review → Controlled Write

Used for:

  • MCR pages
  • developer instructions
  • client reports
  • Supabase records
  • dashboard actions

Example:

AI drafts record → human reviews → approved controlled write occurs.

Pattern 5: Detect Failure → Contain → Escalate → Learn

Used for:

  • Make.com errors
  • bad AI outputs
  • wrong routing
  • missing fields
  • dashboard noise
  • developer ambiguity

Example:

JSON parse fails → workflow paused → HeadOffice reviews → failure logged → prompt/schema updated.

Pattern 6: Analyze → Score → Recommend → Handoff

Used for:

  • finance review
  • offer evaluation
  • experiment results
  • research review
  • dashboard prioritization

Example:

Offer analyzed → risk scored → recommendation made → Finance or Experimentation receives handoff.

Plugin Categories And MWMS Use

1. Intake Plugins

Purpose:

Capture or receive input.

Examples:

  • Gmail watch emails
  • form submission tools
  • Brain Room message intake
  • file upload systems
  • webhook intake

Risk:

Medium, because bad intake creates downstream problems.

Governance:

Must use normalization and source tracking.

2. Data Storage Plugins

Purpose:

Store structured records.

Examples:

  • Supabase
  • Google Sheets
  • WordPress custom tables
  • client database

Risk:

Medium to high, depending on write power.

Governance:

Must use schema checks, controlled writes, logging, and human review where required.

3. Document Processing Plugins

Purpose:

Clean, summarize, extract, or format documents.

Examples:

  • transcript processors
  • file analyzers
  • document summary tools
  • HTML parsers
  • PDF processors

Risk:

Medium.

Governance:

Must separate source grounding, assumptions, and missing data.

4. Analysis Plugins

Purpose:

Analyze data, numbers, results, or patterns.

Examples:

  • data analysis tools
  • spreadsheet analysis
  • finance calculations
  • experiment review
  • traffic metrics

Risk:

High if decisions affect money.

Governance:

Must include assumptions, validation, and human review.

5. Publishing Plugins

Purpose:

Create, update, or publish content.

Examples:

  • WordPress publishing
  • social posting tools
  • email send tools
  • client report delivery

Risk:

High to critical.

Governance:

Draft first. Human approval before publish or send.

6. Automation Plugins

Purpose:

Move work through workflows automatically.

Examples:

  • Make.com
  • n8n
  • Zapier
  • webhook routes
  • queue processors

Risk:

High if automation writes, routes, or triggers actions.

Governance:

Manual proof before automation. Stop conditions required.

7. Dashboard Plugins

Purpose:

Display reviewable intelligence.

Examples:

  • HeadOffice dashboards
  • routed action panels
  • queue review pages
  • status dashboards

Risk:

Medium.

Governance:

Dashboard items must be specific, current, validated, and action-ready.

8. Client System Plugins

Purpose:

Operate inside future client environments.

Examples:

  • client CRM
  • client support inbox
  • client reporting dashboard
  • client workflow software
  • client database

Risk:

High to critical.

Governance:

Client isolation, approval gates, permission records, and audit logs required.

Plugin Orchestration Record Template

Each plugin orchestration should eventually be recorded using the following structure.

Orchestration Name

Field:
Orchestration Name:

Workflow Supported

Field:
Workflow Supported:

Owning Brain

Field:
Owning Brain:

AI Employee Responsible

Field:
AI Employee Responsible:

Plugin Or Tool Used

Field:
Plugin Or Tool Used:

Tool Category

Field:
Tool Category:

Workflow Need

Field:
Workflow Need:

Skill Required

Field:
Skill Required:

Permission Record Required

Field:
Permission Record Required:

Approved Access Level

Field:
Approved Access Level:

Input Required

Field:
Input Required:

Input Preparation Required

Field:
Input Preparation Required:

Tool Action

Field:
Tool Action:

Expected Tool Output

Field:
Expected Tool Output:

Validation Required

Field:
Validation Required:

Human Review Required

Field:
Human Review Required:

Handoff Destination

Field:
Handoff Destination:

Logging Required

Field:
Logging Required:

Stop Conditions

Field:
Stop Conditions:

Failure Handling

Field:
Failure Handling:

Expected Outcome

Field:
Expected Outcome:

Orchestration Status

Field:
Orchestration Status:

Recommended values:

  • Proposed
  • Draft
  • Manual Use
  • Assisted Use
  • Controlled Automation Candidate
  • Controlled Automation
  • Parked
  • Deprecated
  • Retired

Quick Use Version

Orchestration Name:
Workflow Supported:
Owning Brain:
AI Employee Responsible:
Plugin Or Tool Used:
Tool Category:
Workflow Need:
Skill Required:
Permission Record Required:
Approved Access Level:
Input Required:
Input Preparation Required:
Tool Action:
Expected Tool Output:
Validation Required:
Human Review Required:
Handoff Destination:
Logging Required:
Stop Conditions:
Failure Handling:
Expected Outcome:
Orchestration Status:

Example 1: Newsletter Gmail To Supabase Orchestration

Orchestration Name:
Newsletter Gmail To Supabase Intelligence Orchestration

Workflow Supported:
Newsletter Intelligence Workflow

Owning Brain:
HeadOffice Brain

AI Employee Responsible:
Newsletter Signal Extraction Agent

Plugin Or Tool Used:
Gmail, OpenAI, JSON Parse, Supabase, Gmail Label Update

Tool Category:
Email, AI Processing, Data Storage, Automation Platform

Workflow Need:
Capture newsletters, extract business-relevant signals, store structured records for review.

Skill Required:
Newsletter Signal Filtering Skill

Permission Record Required:
Yes

Approved Access Level:
Gmail Read Only, Supabase Controlled Write, Gmail Label Controlled Update

Input Required:
Newsletter subject, sender, body, snippet, date, metadata.

Input Preparation Required:
Remove noise, check body completeness, identify source.

Tool Action:
Read email, extract structured JSON, parse fields, insert row, update label after successful processing.

Expected Tool Output:
Newsletter intelligence record in Supabase and processed email label.

Validation Required:
Yes — Operational Validation.

Human Review Required:
Yes before downstream action.

Handoff Destination:
Newsletter Queue Review, HeadOffice Dashboard candidate, Routed Actions after review.

Logging Required:
Yes — Make execution history and Supabase record.

Stop Conditions:
Missing body, JSON parse failure, schema mismatch, generic output, high-risk signal.

Failure Handling:
Pause, review failed module, log failure, correct prompt/schema before continuing.

Expected Outcome:
Useful external intelligence becomes reviewable without dashboard noise.

Orchestration Status:
Assisted Use

Example 2: Course Transcript To MCR Page Draft Orchestration

Orchestration Name:
Course Transcript To MCR Page Draft Orchestration

Workflow Supported:
Course Absorption Workflow

Owning Brain:
HeadOffice Brain

AI Employee Responsible:
Course Absorption Agent

Plugin Or Tool Used:
Uploaded file analysis, transcript parsing, document drafting

Tool Category:
Uploaded File, Document Processing

Workflow Need:
Turn course material into reusable MWMS frameworks, templates, or standards only when valuable.

Skill Required:
Course Absorption Value Extraction Skill

Permission Record Required:
Yes

Approved Access Level:
Provided Input Only / Draft Creation

Input Required:
Course transcript, lesson title, description, current MWMS context.

Input Preparation Required:
Normalize transcript, remove noise, identify useful content, ignore generic course fluff.

Tool Action:
Extract system value and draft page or report.

Expected Tool Output:
Absorb/park/reject verdict, course absorption report, or full MCR page output.

Validation Required:
Yes — Operational Validation.

Human Review Required:
Yes before MCR save.

Handoff Destination:
MCR, Parking System, Blueprint background, or relevant Brain.

Logging Required:
Yes if absorbed.

Stop Conditions:
Weak content, duplicate page risk, source incomplete, M build impact.

Failure Handling:
Park, reject, revise, request reupload, or log failure.

Expected Outcome:
MWMS Brain improves or weak material is rejected.

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, uploaded file review, current conversation evidence

Tool Category:
Uploaded File, Screenshot, Developer Support

Workflow Need:
Prepare exact developer instructions without making M guess.

Skill Required:
Developer Handoff Precision Skill

Permission Record Required:
Yes

Approved Access Level:
Provided Input Only / Draft Creation

Input Required:
Screenshot, file content, exact user request, current save point.

Input Preparation Required:
Confirm visible evidence, identify missing file paths, state known gaps.

Tool Action:
Draft exact developer handoff or full file output.

Expected Tool Output:
Developer handoff brief with exact site, file path, change, what not to touch, test steps, expected result.

Validation Required:
Yes — High Risk Validation.

Human Review Required:
Always.

Handoff Destination:
M, Dev Console, HeadOffice review.

Logging Required:
Yes for meaningful dev work.

Stop Conditions:
Missing file path, unclear current state, live risk, M would need to guess.

Failure Handling:
Request missing evidence, do not send to M, log failure if needed.

Expected Outcome:
M can act safely without ambiguity.

Orchestration Status:
Manual Use

Example 4: AIBS Client Document To Report Draft Orchestration

Orchestration Name:
AIBS Client Document To Report Draft Orchestration

Workflow Supported:
AIBS Client Reporting Workflow

Owning Brain:
AI Business Systems Brain

AI Employee Responsible:
AIBS Client Reporting Agent

Plugin Or Tool Used:
Client document reader, report drafting tool, approval workflow

Tool Category:
Client System, Document Processing, Reporting

Workflow Need:
Turn client data into clear business reports while preserving safety, privacy, and approval gates.

Skill Required:
AIBS Client Report Drafting Skill

Permission Record Required:
Yes

Approved Access Level:
Read Only / Draft Creation

Input Required:
Approved client document, client workflow context, report purpose.

Input Preparation Required:
Confirm client scope, remove irrelevant data, identify sensitive content.

Tool Action:
Draft client report.

Expected Tool Output:
Client report draft with findings, meaning, recommended action, risk notes, and approval requirement.

Validation Required:
Yes — High Risk Validation.

Human Review Required:
Yes before client delivery.

Handoff Destination:
Client Review Queue / HeadOffice review.

Logging Required:
Yes — client audit log.

Stop Conditions:
Sensitive data outside scope, missing approval gate, compliance risk, unsupported claims.

Failure Handling:
Pause, escalate, revise, and log.

Expected Outcome:
Client receives useful, safe, reviewed reporting.

Orchestration Status:
Future Draft Only

Plugin Orchestration Governance Rules

Rule 1: Workflow Before Plugin

The workflow defines the need.

The plugin supports the workflow.

Do not design MWMS around plugin excitement.

Rule 2: Role Before Tool

An AI Employee role must exist before tool use becomes operational.

If no role owns the tool, the tool is not ready.

Rule 3: Skill Before Action

The AI Employee must have the right skill before using the tool.

Tool access without procedural skill creates risk.

Rule 4: Permission Before Access

Tool access requires a Tool Permission Record.

No permission record means no operational tool use.

Rule 5: Clean Input Before Processing

Input must be normalized unless the plugin’s job is specifically to clean input.

Rule 6: Validation Before Routing

Tool output must be validated before it moves into dashboards, tasks, MCR, developer handoffs, or client systems.

Rule 7: Human Review Before High Risk Action

Human review is mandatory before:

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

Rule 8: Logging Before Expansion

A plugin workflow must produce logs before it expands.

If MWMS cannot see what happened, the workflow is not ready to scale.

Rule 9: Failure Handling Before Automation

No plugin workflow should be automated until failure modes and stop conditions are known.

Rule 10: Outcome Before More Tools

Do not add more tools until current tool use creates measurable outcomes.

Plugin Orchestration Readiness Checklist

Before a plugin orchestration moves forward, check:

  1. Is the workflow need clear?
  2. Is the tool necessary?
  3. Is the simplest safe tool selected?
  4. Is the owning Brain clear?
  5. Is the AI Employee responsible defined?
  6. Does the AI Employee have a role card?
  7. Does the AI Employee have a capability stack?
  8. Is the required skill defined?
  9. Is the tool permission record created?
  10. Is the approved access level clear?
  11. Is input preparation defined?
  12. Is source of truth clear?
  13. Is the tool action narrow and specific?
  14. Is expected output defined?
  15. Is validation required?
  16. Is human review required where needed?
  17. Is handoff destination clear?
  18. Is logging required?
  19. Are stop conditions listed?
  20. Is failure handling defined?
  21. Is expected outcome clear?
  22. Has manual proof happened?
  23. Does this affect M’s active build?
  24. Does this require developer brief?
  25. Is automation premature?

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

Common Plugin Orchestration Failure Modes

Plugin orchestration has failed if:

  1. A tool is added without workflow need.
  2. Tool access is granted to generic AI.
  3. No AI Employee owns the tool use.
  4. No skill defines how the tool should be used.
  5. Permission level is too broad.
  6. Input is messy and unprepared.
  7. Tool output is accepted without validation.
  8. Tool output has no destination.
  9. Human review is skipped.
  10. Logging is missing.
  11. Stop conditions are missing.
  12. A plugin creates dashboard noise.
  13. A plugin creates M developer confusion.
  14. A plugin writes to the wrong system.
  15. Automation expands before manual proof.

Manual Use Rule

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

Manual use helps MWMS learn:

  • which tools are genuinely needed
  • which workflows benefit from tools
  • where read-only is enough
  • where draft-only is enough
  • where controlled write is justified
  • where validation must be stronger
  • where tool output fails
  • where automation is premature
  • which orchestrations may later become 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 workflow rules
  • Brain Room tool-assisted task creation
  • Newsletter Intelligence automation governance
  • Course Absorption document-processing workflow
  • HeadOffice orchestration dashboard
  • AIBS client workflow orchestration panel

Possible future fields:

  • orchestration_id
  • orchestration_name
  • workflow_supported
  • owning_brain
  • responsible_ai_employee
  • plugin_or_tool_used
  • tool_category
  • workflow_need
  • skill_required
  • permission_record_required
  • approved_access_level
  • input_required
  • input_preparation_required
  • tool_action
  • expected_tool_output
  • validation_required
  • human_review_required
  • handoff_destination
  • logging_required
  • stop_conditions
  • failure_handling
  • expected_outcome
  • orchestration_status
  • created_at
  • updated_at

No technical build is authorized by this framework alone.

Governance Role

HeadOffice owns the MWMS AI Plugin Orchestration Framework.

HeadOffice is responsible for:

  • approving plugin orchestration principles
  • preventing tool sprawl
  • preventing unsafe automation
  • ensuring plugins serve workflows
  • ensuring tool use belongs to AI Employees
  • ensuring skills govern tool use
  • ensuring permission records exist
  • ensuring validation gates exist
  • ensuring human approval gates exist
  • ensuring logging and failure handling exist
  • protecting M’s active build areas
  • protecting MCR source of truth
  • protecting future AIBS client systems

Individual Brains may propose plugin orchestrations, but HeadOffice governs cross-Brain, high-risk, write-enabled, external-action, client-facing, and automation-related orchestration.

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 Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS AI Employee Capability Stack Framework
  • MWMS AI Employee Capability Stack Template
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Tool Permission Record Template
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Agent Context Pack Template
  • MWMS Agentic Work Unit Standard
  • MWMS Agentic Work Unit Template
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Workflow Pipeline Checklist
  • MWMS AI Output Validation Standard
  • MWMS AI Output Validation Checklist
  • MWMS Messy Input Normalization Framework
  • MWMS Messy Input Normalization Record
  • MWMS Agentic Reporting Standard
  • MWMS Agentic Reporting Template
  • MWMS AI Employee Handoff Protocol
  • MWMS AI Employee Handoff Package Template
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Failure Log Record
  • MWMS AI Agent Outcome Measurement Framework
  • MWMS AI Agent Outcome Log Record
  • MWMS AI Agent Deployment Readiness Checklist
  • MWMS AI Agent Deployment Readiness Review Template
  • MWMS AI Workforce Governance Model
  • MWMS Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

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

Drift Protection

This framework protects MWMS from the following forms of drift:

  1. Treating plugins as strategy
  2. Adding tools without workflow need
  3. Letting tool access replace skill
  4. Allowing generic AI to use powerful tools
  5. Giving write access too early
  6. Accepting plugin output without validation
  7. Automating unproven workflows
  8. Creating dashboard noise from tool output
  9. Triggering external action without review
  10. Expanding Make.com or n8n workflows without stop conditions
  11. Sending M broad tool ideas instead of exact briefs
  12. Mixing client systems without isolation
  13. Letting plugin excitement override MCR governance
  14. Measuring tool count instead of business outcome
  15. Creating tool chains that MWMS cannot audit

Any plugin workflow without orchestration should remain manual, draft, or parked.

Architectural Intent

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

MWMS will eventually rely on many tools.

But the strength of MWMS will not come from tool access alone.

It will come from how those tools are orchestrated inside governed workflows.

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

  • Why is this tool needed?
  • Which workflow does it support?
  • Which AI Employee owns it?
  • Which skill governs its use?
  • What permission level applies?
  • What input does it receive?
  • What action does it perform?
  • What output does it create?
  • How is that output validated?
  • Where does the result go?
  • What is logged?
  • When does the workflow stop?
  • What outcome does the tool support?

When MWMS can answer those questions, plugins become controlled capability instead of operational risk.

Change Log

v1.0 — Initial Draft

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

This framework establishes plugin orchestration layers, orchestration patterns, plugin categories, plugin orchestration records, governance rules, readiness checks, failure modes, future plugin/UI relevance, governance role, drift protection, and architectural intent.

It establishes that plugins add capability, but orchestration makes that capability safe and useful.