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, 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 Agent Orchestration Framework.
This framework explains how MWMS coordinates AI Employees, Brains, tools, workflows, task queues, validation steps, handoffs, reports, and business outcomes.
MWMS must not operate as a loose collection of disconnected AI prompts or independent AI helpers.
MWMS must operate as a coordinated AI workforce.
That requires orchestration.
Orchestration is the management layer that decides:
- what work needs to happen
- which Brain owns the work
- which AI Employee should perform the work
- what order the work should happen in
- what context is required
- what tools are permitted
- what validation is needed
- where the output goes
- what business outcome the work supports
- what should be logged for future review
This framework exists to make AI work inside MWMS coordinated, repeatable, governable, measurable, and safe.
Scope
This framework applies to all MWMS workflows where more than one step, Brain, AI Employee, tool, review stage, or handoff is involved.
This includes:
- Brain Room task conversion
- AI Manager routing
- AI Employee Router logic
- Task Executor workflows
- Newsletter Intelligence workflows
- Course Absorption workflows
- Offer Evaluation workflows
- Research Brain workflows
- Experimentation Brain workflows
- Finance Brain workflows
- Content Brain workflows
- Ads Brain workflows
- HeadOffice reporting workflows
- Brain-to-Brain requests
- Supabase task and event systems
- future client-facing AIBS workflows
This framework applies to both manual orchestration and automated orchestration.
Manual orchestration happens when Martyn, M, or HeadOffice decides the next task, next Brain, next page, next workflow, or next review step.
Automated orchestration happens when MWMS systems classify, assign, route, validate, and log AI work through technical workflows.
Core Definition
AI Agent Orchestration is the process of coordinating AI Employees, Brains, tasks, tools, validation gates, handoffs, and outcomes inside MWMS.
Orchestration is not the same as automation.
Automation executes steps.
Orchestration decides how steps should be arranged, assigned, governed, reviewed, and routed.
Inside MWMS, orchestration answers:
- What is this request?
- Which Brain owns it?
- What type of work is required?
- Which AI Employee should do it?
- What context does the AI Employee need?
- What tools can be used?
- What output is required?
- Who checks the output?
- Where does the output go next?
- What outcome does this support?
- What gets logged?
Without orchestration, AI work becomes scattered.
With orchestration, AI work becomes systemized.
Core Principle
The core principle of this framework is:
AI capability does not become MWMS business value until it is routed, sequenced, validated, handed off, and connected to an outcome.
A powerful AI model is not enough.
A useful AI Employee is not enough.
A good prompt is not enough.
MWMS value comes from how the whole system coordinates work.
The orchestration layer is what turns AI activity into business execution.
Why Orchestration Matters
MWMS is becoming a multi-Brain ecosystem.
That means work will often cross several areas.
For example:
An affiliate offer may need:
- Affiliate Brain for intake
- Research Brain for market evidence
- Ads Brain for platform fit
- Finance Brain for break-even logic
- Experimentation Brain for test design
- Risk or Compliance review for safety
- HeadOffice for final visibility and decision
A newsletter signal may need:
- HeadOffice Brain for intake
- Signal Extraction Agent for insight
- Brain Routing Agent for ownership
- Validation Agent for quality
- Queue Review for human decision
- Routed Actions for follow-up
- Learning Log for pattern tracking
A Brain Room request may need:
- Task Builder Agent
- Brain Classifier Agent
- AI Manager
- correct AI Employee
- Validation Agent
- Response Agent
- event logging
Without orchestration, these flows become confusing and fragile.
With orchestration, MWMS can scale.
Orchestration Layers
MWMS orchestration should operate across six layers.
1. Request Orchestration
Request Orchestration identifies what has entered the system.
A request may come from:
- Martyn
- M
- Brain Room
- HeadOffice
- newsletter intake
- uploaded course file
- Supabase task
- WordPress page update need
- Google Ads data
- affiliate offer
- research source
- dashboard item
- system event
- client request
The first orchestration question is:
What kind of request is this?
Request Orchestration classifies the request before any AI Employee performs deeper work.
Possible request classes include:
- question
- analysis request
- task creation request
- page creation request
- course absorption request
- newsletter signal
- offer evaluation
- research request
- validation request
- developer support request
- report generation
- workflow handoff
- system issue
- escalation
Request Orchestration protects MWMS from treating every input the same way.
2. Brain Orchestration
Brain Orchestration identifies which Brain owns the work.
This is critical because MWMS Brains have different responsibilities.
Examples:
- HeadOffice Brain owns cross-system governance, visibility, routing, and final control.
- Affiliate Brain owns affiliate opportunity intake and offer logic.
- Research Brain owns evidence gathering, source analysis, and market validation.
- Experimentation Brain owns test design, test tracking, and learning capture.
- Finance Brain owns budget logic, break-even analysis, and capital control.
- Content Brain owns content production, refresh, repurposing, and SEO/content workflows.
- Ads Brain owns campaign logic, platform strategy, traffic rules, and ad testing.
- AI Business Systems Brain owns client-facing AI workflow packaging and system design.
Brain Orchestration answers:
- Which Brain should own this?
- Which Brain only supports it?
- Does HeadOffice need visibility?
- Is this cross-Brain work?
- Does this need a Brain-to-Brain request?
- Is this outside the scope of the current Brain?
The Brain rule is:
No work should move forward until ownership is clear.
3. Employee Orchestration
Employee Orchestration assigns the correct AI Employee to the work.
This depends on:
- task type
- owning Brain
- required output
- risk level
- available input
- tool requirement
- validation requirement
Examples:
A newsletter may be assigned to:
- Newsletter Intake Agent
- Signal Extraction Agent
- Brain Routing Agent
- Validation Agent
- Dashboard Reporting Agent
An offer may be assigned to:
- Offer Intake Agent
- Vendor Intelligence Agent
- Market Demand Agent
- Compliance Review Agent
- Finance Break Even Agent
- HeadOffice Verdict Agent
A course lesson may be assigned to:
- Course Intake Agent
- Value Filter Agent
- Framework Extraction Agent
- MWMS Mapping Agent
- Duplication Check Agent
- Page Builder Agent
Employee Orchestration answers:
- Which AI Employee is best suited?
- Does the Employee have a role card?
- Is this inside the Employee’s authority?
- Does this require more than one Employee?
- Should one Employee complete the task or should it be split?
The Employee rule is:
Work must be assigned to roles, not vague AI capability.
4. Workflow Orchestration
Workflow Orchestration defines the sequence of work.
Complex AI work should not be handled as one large prompt.
It should be decomposed into stages.
The default MWMS workflow sequence is:
- Intake
- Cleaning
- Classification
- Task Creation
- Assignment
- Processing
- Validation
- Decision
- Routing
- Logging
- Reporting
- Learning
Not every task needs every step.
But high-value or high-risk work should follow a clear sequence.
Workflow Orchestration answers:
- What happens first?
- What depends on what?
- What must be completed before the next step?
- Where are the review gates?
- What happens if a step fails?
- What can be automated?
- What requires human review?
The Workflow rule is:
Complex work must be sequenced before it is executed.
5. Validation Orchestration
Validation Orchestration decides how outputs are checked.
Validation may happen:
- after each stage
- before handoff
- before dashboard display
- before MCR update
- before live system change
- before client delivery
- before external communication
- before final HeadOffice decision
Validation can be performed by:
- the same AI Employee using self-check rules
- a separate Validation Agent
- HeadOffice
- Martyn
- M
- a future reviewer
- a technical test
- a data integrity check
- a dashboard review
Validation Orchestration answers:
- What needs checking?
- Who checks it?
- What standard applies?
- Is human review required?
- What happens if validation fails?
- Is the output accepted, revised, parked, rejected, or escalated?
The Validation rule is:
AI output is not trusted simply because it was generated.
6. Outcome Orchestration
Outcome Orchestration connects AI work to business results.
MWMS must avoid producing outputs that sound useful but go nowhere.
Outcome Orchestration answers:
- What should happen because of this output?
- Is this a decision?
- Is this a task?
- Is this a dashboard item?
- Is this a report?
- Is this a learning record?
- Is this a rejected idea?
- Is this a parked opportunity?
- Is this an MCR page update?
- Is this a Brain handoff?
- Is this a client deliverable?
The Outcome rule is:
Every important AI output must support a next action, decision, report, routing event, or learning record.
Standard Orchestration Flow
The standard MWMS orchestration flow is:
- Request Received
- Request Classified
- Owning Brain Identified
- Supporting Brains Identified
- Work Unit Created
- AI Employee Assigned
- Context Pack Attached
- Tool Permission Checked
- Workflow Sequence Selected
- AI Work Performed
- Output Validated
- Decision Made
- Output Routed
- Event Logged
- Learning Captured
- HeadOffice Visibility Updated Where Required
This is the default orchestration pattern for serious AI work.
Orchestration Decision Tree
When a request enters MWMS, the orchestration layer should ask:
Step 1: Is this real work or casual support?
If casual support, answer directly.
If real work, create or follow an Agentic Work Unit.
Step 2: Is the request simple or complex?
If simple, assign to one AI Employee.
If complex, break into a workflow.
Step 3: Which Brain owns it?
Assign owning Brain.
If cross-Brain, identify supporting Brains.
Step 4: Which AI Employee should act first?
Assign the first role.
Do not assign to generic AI.
Step 5: What context is required?
Attach Brain rules, standards, source material, boundaries, and previous decisions.
Step 6: What tools are allowed?
Check tool permission before execution.
Step 7: What output is required?
Define the output before work begins.
Step 8: What validation is required?
Set validation based on risk and business impact.
Step 9: Where does the result go?
Define handoff destination.
Step 10: What outcome is expected?
Connect the output to a business result.
Orchestration Modes
MWMS should support multiple orchestration modes.
1. Manual Orchestration
Manual Orchestration is when Martyn or another human decides the flow.
Example:
Martyn uploads a course block.
The assistant evaluates it, extracts system value, creates MCR-ready page output, and Martyn decides whether to save it.
Manual Orchestration is useful during:
- early system design
- course absorption
- MCR page creation
- high-risk decisions
- structural changes
- unclear workflows
- new Brain development
Manual Orchestration should still follow MWMS standards.
2. Assisted Orchestration
Assisted Orchestration is when AI recommends the flow but a human approves it.
Example:
Brain Room receives a message.
The Task Builder Agent suggests:
- owning Brain
- task type
- assigned AI Employee
- priority
- risk level
- validation requirement
Martyn or HeadOffice approves the route.
Assisted Orchestration is useful when workflows are not fully trusted yet.
3. Controlled Automated Orchestration
Controlled Automated Orchestration is when the system automatically routes work inside approved boundaries.
Example:
A newsletter enters the system.
The workflow automatically extracts, classifies, stores, and displays the item for review.
The system does not create downstream tasks without review.
Controlled automation is useful for repeatable, medium-risk workflows.
4. Supervised Agentic Orchestration
Supervised Agentic Orchestration is when multiple AI Employees perform multiple steps, but review gates remain in place.
Example:
Offer Evaluation workflow:
- Offer Intake Agent
- Research Agent
- Compliance Agent
- Finance Agent
- Experimentation Fit Agent
- HeadOffice Verdict Agent
The system prepares a decision report, but human review is required before testing.
This is useful for high-value workflows.
5. Restricted Autonomous Orchestration
Restricted Autonomous Orchestration is when AI can complete low-risk workflows without immediate human review.
This should be limited to safe tasks such as:
- formatting
- categorizing
- duplicate detection
- low-risk tagging
- draft preparation
- internal note cleanup
- routine status updates
- non-public report formatting
This mode must never be used for high-risk work without strong controls.
Orchestration Risk Levels
The orchestration mode must match the risk level.
Low Risk
Examples:
- formatting notes
- summarizing internal content
- preparing draft outlines
- cleaning non-sensitive text
Allowed mode:
- manual
- assisted
- controlled automated
- restricted autonomous if approved
Medium Risk
Examples:
- newsletter intelligence
- course absorption drafts
- internal reports
- Brain Room task drafts
- dashboard queue items
Allowed mode:
- manual
- assisted
- controlled automated
- supervised agentic
Human review often required before final routing.
High Risk
Examples:
- offer verdicts
- finance analysis
- compliance review
- developer instructions
- MCR canonical updates
- public content
- paid traffic decisions
Allowed mode:
- manual
- assisted
- supervised agentic
Human review required.
Critical Risk
Examples:
- live system changes
- database writes
- external email sending
- client-facing final reports
- financial transactions
- legal/compliance-sensitive actions
- irreversible automation
Allowed mode:
- manual or supervised only
Human approval required before execution.
Orchestration Example: Newsletter Intelligence
A mature Newsletter Intelligence orchestration flow should be:
- Gmail receives newsletter
- Newsletter Intake Agent captures metadata and content
- Cleaning Agent removes noise
- Signal Extraction Agent identifies business-relevant signals
- Brain Routing Agent assigns primary and supporting Brains
- Action Classification Agent marks ACT NOW, TEST, MONITOR, PARK, or REJECT
- Validation Agent checks specificity and usefulness
- Output stored in Supabase
- Queue Review displays item
- HeadOffice Dashboard displays priority intelligence
- Human review routes, parks, rejects, or converts to action
- Learning Agent tracks recurring patterns
This turns newsletters into operational intelligence instead of passive reading.
Orchestration Example: Brain Room Request
A mature Brain Room orchestration flow should be:
- Brain Room message received
- Request type identified
- Owning Brain classified
- Agentic Work Unit created
- Required context attached
- AI Employee assigned
- Risk level set
- Task sent to AI Manager
- AI Employee completes task
- Output validated
- Response posted back to Brain Room
- Important result logged
- Follow-up action routed if required
This turns Brain Room into an operational command layer, not just a chat stream.
Orchestration Example: Course Absorption
A mature Course Absorption orchestration flow should be:
- Course file uploaded
- Course Intake Agent identifies lesson/module
- Value Filter Agent judges system relevance
- Framework Extraction Agent extracts reusable models
- MWMS Mapping Agent maps to Brains and Blueprint
- Duplication Check Agent checks against existing standards
- Upgrade Decision Agent decides absorb, park, ignore, or replace
- Page Builder Agent prepares MCR output if required
- Registry Agent identifies registry update needs
- Validation Agent checks fit and naming/structure
- Martyn reviews before saving
- Learning logged
This prevents weak course material from cluttering MWMS.
Orchestration Example: Offer Evaluation
A mature Offer Evaluation orchestration flow should be:
- Offer enters Affiliate Brain
- Offer Intake Agent records basic offer data
- Vendor Intelligence Agent checks credibility
- Market Demand Agent checks demand signals
- Competitor Scan Agent checks market crowding
- Funnel Analysis Agent checks sales mechanism
- Ads Brain checks traffic and platform fit
- Compliance Review Agent flags risks
- Finance Brain estimates break-even and test budget
- Experimentation Brain checks test suitability
- HeadOffice Verdict Agent prepares decision
- Martyn reviews Green, Yellow, or Red verdict
- Result routed to test planning, research, parking, or rejection
- Learning logged
This protects MWMS from wasting money on weak or risky offers.
Orchestration Example: AIBS Client System
A mature AIBS client workflow may be:
- Client business process identified
- Process mapped into repeatable work units
- AI Employee roles defined
- Tool permissions assigned
- Workflow sequence designed
- Validation gates added
- Human review rules defined
- Dashboard/reporting layer created
- Client approval points defined
- Logging and audit trail included
- System deployed in controlled mode
- Kaizen improvement loop begins
This supports the future MWMS client-facing offer:
Governed AI workflow systems, not random automations.
Orchestrator Agent Role
The Orchestrator Agent is the AI Employee responsible for recommending or managing workflow coordination.
The Orchestrator Agent may:
- classify requests
- recommend owning Brain
- identify supporting Brains
- suggest AI Employee sequence
- recommend validation gates
- identify tool permissions
- flag risk level
- determine handoff path
- prepare workflow plans
- identify missing context
The Orchestrator Agent must not:
- bypass HeadOffice governance
- approve high-risk actions alone
- execute live system changes
- assign tasks into restricted developer areas without approval
- remove human review from high-risk workflows
- invent Brain ownership where standards are unclear
The Orchestrator Agent is a coordination role, not a final authority role.
Human Orchestration Role
Human orchestration remains essential.
Martyn, HeadOffice, M, and future operators may be required for:
- strategic decisions
- system architecture changes
- MCR canon updates
- developer implementation
- paid traffic decisions
- compliance-sensitive decisions
- client-facing approvals
- high-risk automation approval
- escalation resolution
AI can support orchestration.
AI must not replace governance.
The human role is especially important while MWMS is still being built.
Orchestration Failure Modes
MWMS must watch for orchestration failure.
Common failure modes include:
- Wrong Brain ownership
- Wrong AI Employee assignment
- Missing context
- Over-automation of high-risk work
- No validation gate
- Output has no destination
- Task is too vague
- Too many agents for a simple task
- One AI Employee doing too many jobs
- Human review skipped
- Dashboard filled with low-value items
- Event logs missing
- Workflow creates duplicate records
- Agent loops endlessly without decision
- System mistakes activity for progress
These failure modes should be used when reviewing future workflows.
Orchestration Quality Checklist
Before an orchestrated AI workflow is approved, check:
- Is the request type clear?
- Is the owning Brain clear?
- Are supporting Brains identified?
- Is the task broken into sensible stages?
- Is each stage assigned to the correct AI Employee?
- Is required context attached?
- Are tool permissions defined?
- Are forbidden actions defined?
- Is the output format defined?
- Is validation required?
- Is human review required?
- Is the handoff destination clear?
- Is the business outcome clear?
- Is logging required?
- Is the workflow too complex for the value of the task?
- Is the workflow safe for the current build stage?
- Does it interfere with M’s active work?
- Does HeadOffice need visibility?
- Does the result improve MWMS?
- Can the workflow be repeated?
A workflow should not be automated until it passes this checklist.
Governance Role
HeadOffice owns the MWMS AI Agent Orchestration Framework.
HeadOffice is responsible for:
- defining orchestration standards
- approving cross-Brain orchestration patterns
- setting validation requirements
- setting human review requirements
- preventing unsafe automation
- preventing AI Employee role drift
- protecting M’s active build areas
- ensuring outputs connect to business outcomes
- maintaining visibility over critical workflows
Individual Brains may design their own orchestration flows, but those flows must align with this framework.
No Brain should create autonomous workflows that bypass HeadOffice oversight for high-risk or cross-system work.
Relationship To Other MWMS Standards
This framework supports and must align with:
- MWMS AI Agent Operations Core
- MWMS Agentic Work Unit Standard
- MWMS AI Employee Role Card Standard
- 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
- AI Business Systems Brain Blueprint
This framework explains how those standards are coordinated during real AI work.
Drift Protection
This framework protects MWMS from the following forms of drift:
- Treating AI automation as orchestration
- Allowing workflows to run without Brain ownership
- Assigning tasks to vague AI roles
- Using one prompt for complex work
- Skipping validation gates
- Routing outputs to nowhere
- Automating high-risk actions too early
- Creating AI Employees without role cards
- Allowing Brains to operate outside HeadOffice visibility
- Creating dashboards full of unvalidated noise
- Letting Brain Room become unmanaged chat
- Letting course absorption create duplicate systems
- Giving tool access without permission boundaries
- Losing business outcome visibility
- Mistaking speed for system maturity
Any workflow showing these drift signs should be paused and reviewed.
Architectural Intent
The architectural intent of the MWMS AI Agent Orchestration Framework is to turn MWMS into a managed AI operating ecosystem.
MWMS should not depend on a single AI model, tool, platform, or prompt style.
The durable value of MWMS should come from:
- how work is classified
- how Brains own work
- how AI Employees are assigned
- how workflows are sequenced
- how outputs are validated
- how handoffs are controlled
- how decisions are reported
- how learning is captured
- how HeadOffice governs the system
The long-term goal is that MWMS can coordinate many AI Employees across many Brains without losing control, context, quality, or business direction.
A mature MWMS orchestration system should be able to answer:
- What entered the system?
- What type of work is it?
- Which Brain owns it?
- Which AI Employees are involved?
- What sequence is required?
- What context is needed?
- What tools are allowed?
- What validation is required?
- Where does the output go?
- What business outcome does it support?
- What was logged?
- What did MWMS learn?
When MWMS can answer those questions consistently, it has the foundation of a real AI business operating system.
Change Log
v1.0 — Initial Draft
Created the MWMS AI Agent Orchestration Framework as the coordination layer for AI Employees, Brains, workflows, validation, handoffs, tool permissions, reporting, and business outcomes.
This framework supports the MWMS AI Agent Operations Core, MWMS Agentic Work Unit Standard, and MWMS AI Employee Role Card Standard by defining how AI work is routed, sequenced, validated, governed, and connected to measurable outcomes across MWMS.