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, Newsletter Intelligence, Course Absorption System, Opportunity System, AIBS Brain
Parent Page: HeadOffice
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-20
Source / Origin: MWMS AI Employee Capability Stack Framework v1.0 + AI Automations by Jack — specialist Skills, multi-agent teams, model routing, persistent project instructions, external knowledge access, independent review, parallel execution, tool integration and controlled autonomy block
Related Pages: MWMS AI Agent Skill Library Framework, MWMS AI Skill Builder And Audit Protocol, MWMS AI Employee Role Card Standard, MWMS AI Tool Permission And Access Framework, MWMS AI Agent Memory And Context Framework, MWMS AI Agent Orchestration Framework, MWMS AI Multi Agent Role Design Framework, MWMS Independent Model Review And Rescue Routing Framework, MWMS External Knowledge Engine And Reasoning Agent Separation Framework, MWMS AI Agent Deployment Readiness Checklist, MWMS AI Agent Outcome Measurement Framework
MWMS Independent Model Review And Rescue Routing Framework
MWMS External Knowledge Engine And Reasoning Agent Separation Framework
Purpose
The purpose of this document is to define the MWMS AI Employee Capability Stack Framework.
This framework establishes how MWMS defines, organizes, limits, and improves the capabilities of each AI Employee.
An AI Employee is not useful simply because it has a name.
An AI Employee becomes useful when MWMS knows:
what it can do
what it cannot do
what inputs it can handle
what tools it can access
what context it requires
what outputs it can produce
what workflows it supports
what permissions it has
what validation rules apply
what handoffs it can perform
what outcomes it is expected to create
what models or reasoning routes it may use
what reusable skills it may invoke
what dependencies and environments it requires
whether it may work in parallel with other AI Employees
what cost, quota, and autonomy limits apply
The Capability Stack is the structured view of those abilities.
This framework exists so MWMS can design AI Employees as controlled operational assets, not vague assistants.
Scope
This framework applies to every formal AI Employee, agent, assistant, workflow worker, reviewer, router, validator, reporter, or automation-support role created inside MWMS.
This includes AI Employees used by:
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
Data Brain
Strategy Brain
Operations Brain
AIBS Brain
future client-facing AIBS systems
This framework applies before technical implementation.
It should be used during AI Employee design, role card creation, workflow planning, deployment readiness review, and future M developer brief preparation.
Core Definition
An AI Employee Capability Stack is the full set of capabilities, limits, permissions, tools, context sources, output abilities, workflow roles, validation requirements, and outcome expectations assigned to an AI Employee.
The Capability Stack answers:
What can this AI Employee understand?
What can it receive?
What can it process?
What tools can it use?
What can it produce?
What decisions can it support?
What must it escalate?
What must it never do?
What output quality is required?
What business outcome should it create?
The Capability Stack is not only about tools.
It includes thinking ability, workflow position, context access, authority, reporting, handoff, validation, failure handling, and measurement.
Core Principle
The core principle of this framework is:
Every AI Employee must have capabilities that match its role, authority, risk level, and business purpose.
An AI Employee should not be overpowered, underpowered, vague, or uncontrolled.
Too little capability makes the AI Employee useless.
Too much capability makes the AI Employee risky.
Unclear capability makes the AI Employee unreliable.
MWMS must design AI Employees with the right capability stack for the job.
Why Capability Stacks Matter
MWMS will eventually have many AI Employees.
Some will read and classify information.
Some will extract signals.
Some will evaluate offers.
Some will create reports.
Some will validate outputs.
Some will route work.
Some will support M.
Some will support future clients.
Each AI Employee needs a different capability stack.
For example:
A Newsletter Signal Extraction Agent needs strong extraction and classification ability, but should not be able to create live downstream tasks without review.
A Finance Break Even Analysis Agent needs numerical reasoning and risk framing, but should not approve spending.
A Developer Support Agent needs exact file/path discipline and visible evidence, but should not alter live code directly.
A Client Reporting Agent needs plain-language business communication, risk notes, and approval gates, but should not make unsupported claims.
Capability stacks prevent one AI Employee from becoming a dangerous all-purpose agent.
Capability Stack Layers
The MWMS AI Employee Capability Stack has eighteen layers.
Role Capability
Input Capability
Context Capability
Reasoning Capability
Model And Route Capability
Skill Capability
Tool Capability
Environment And Dependency Capability
Workflow Capability
Parallel And Team Capability
Output Capability
Validation Capability
Handoff Capability
Escalation Capability
Learning Capability
Outcome Capability
Cost And Quota Capability
Autonomy And Shutdown Capability
- Role Capability
Role Capability defines what the AI Employee is designed to do.
Examples:
intake
cleaning
classification
research
extraction
analysis
validation
reporting
routing
handoff
finance review
offer evaluation
course absorption
developer support
client reporting
Role Capability must match the AI Employee Role Card.
The Role Capability rule is:
An AI Employee’s capability must begin with its job, not with its tool access.
- Input Capability
Input Capability defines what types of input the AI Employee can safely handle.
Examples:
course transcripts
newsletters
Brain Room messages
Supabase rows
WordPress page lists
Google Ads data
affiliate offer pages
sales page text
finance numbers
research notes
screenshots
developer notes
client documents
Input Capability should also define what input is not allowed.
For example:
A Course Absorption Agent may handle lesson transcripts, PDFs, and HTML descriptions, but should not directly act on live code files.
A Developer Support Agent may handle screenshots, plugin files, and error messages, but should not evaluate affiliate offers.
The Input Capability rule is:
AI Employees should only receive input types they are designed to process.
- Context Capability
Context Capability defines what system knowledge the AI Employee needs.
Examples:
MWMS Brain Routing Rule
MWMS Document Structure Standard
MWMS Page Naming Standard
current save point
developer boundary
relevant Brain Canon
relevant operating protocol
user preference
previous decision
active workflow state
current risk boundary
source of truth location
Context Capability prevents isolated output.
An AI Employee without the right context may produce polished but misaligned work.
The Context Capability rule is:
An AI Employee must not perform meaningful MWMS work without the context required for that role.
- Reasoning Capability
Reasoning Capability defines the type of thinking the AI Employee must perform.
Examples:
classification
comparison
summarization
extraction
synthesis
contradiction detection
scenario planning
risk analysis
evidence evaluation
route selection
prioritization
structural mapping
quality checking
financial reasoning
workflow design
business recommendation
Different roles require different reasoning.
A Validator needs checking and risk detection.
A Research Agent needs evidence and uncertainty handling.
A Course Absorption Agent needs system mapping and duplication awareness.
An Orchestrator needs sequencing and role assignment.
The Reasoning Capability rule is:
The AI Employee’s reasoning mode must match the work type.
- Model And Route Capability
Model And Route Capability defines which reasoning route the AI Employee may use.
Possible routes include:
low-cost extraction model
standard reasoning model
advanced reasoning model
multimodal model
coding model
local private model
independent review model
rescue model
deterministic verification tool
The capability should define:
default model route
allowed alternate routes
conditions for stronger reasoning
conditions for lower-cost processing
privacy requirements
fallback route
independent review requirement
rescue route
Model Route Rule
An AI Employee should not use the most powerful or expensive model by default.
The route should match task complexity, risk, privacy, and expected value.
- Skill Capability
Skill Capability defines which approved reusable skills the AI Employee may invoke.
Examples:
Course Absorption Value Extraction Skill
Newsletter Signal Filtering Skill
MCR Duplicate Risk Check Skill
Developer Handoff Precision Skill
Competitive Intelligence Package Skill
Multi-Channel Content Repurposing Skill
Skill Capability should define:
approved skills
active versions
skill scope
required dependencies
automatic invocation allowed
human review requirements
forbidden skills
Skill Capability Rule
An AI Employee may use only approved skills that match its Role Card, Capability Stack, authority, scope, and current Work Unit.
A skill must not silently expand the AI Employee’s authority.
- Tool Capability
Tool Capability defines what tools, systems, files, APIs, or platforms the AI Employee may use.
Examples:
uploaded files
web research
Gmail
Supabase read
Supabase write
WordPress read
WordPress write
Google Sheets
Google Drive
Make.com
n8n
OpenAI
Claude
Gemini
file generation tools
analytics dashboards
internal Brain pages
client systems
Tool Capability must be explicit.
The AI Employee must not assume access.
Tool Capability should define:
allowed tools
forbidden tools
read permissions
write permissions
approval requirements
logging requirements
human review triggers
The Tool Capability rule is:
Tool access must be granted by role and risk, not by convenience.
- Environment And Dependency Capability
Environment And Dependency Capability defines what must exist before the AI Employee can operate correctly.
Possible requirements include:
approved software
specific files
current context packs
external knowledge sources
database access
browser access
API availability
local operating environment
client workspace
active skill dependencies
validated templates
approved credentials held outside the skill
The capability should define:
required dependencies
optional dependencies
environment assumptions
dependency owner
version compatibility
blocked-state behaviour
fallback route
Environment And Dependency Rule
An AI Employee must enter Blocked status when required dependencies or environment conditions are unavailable.
It must not improvise unsafe access or silently continue with incomplete capability.
- Workflow Capability
Workflow Capability defines what stage of the pipeline the AI Employee can perform.
Pipeline stages include:
input capture
input cleaning
classification
task creation
context attachment
processing
validation
decision support
routing
reporting
handoff
logging
learning update
An AI Employee may operate in one or more stages.
However, the stages must be clear.
For example:
A Task Builder Agent operates in classification and task creation.
A Reporting Agent operates in reporting and handoff.
A Validation Agent operates in validation and escalation.
A Handoff Agent operates in transfer and context preservation.
The Workflow Capability rule is:
An AI Employee must know where it sits in the pipeline.
- Parallel And Team Capability
Parallel And Team Capability defines whether the AI Employee may work with other AI Employees or run multiple specialist routes at the same time.
Possible team roles include:
orchestrator
specialist worker
independent reviewer
research worker
validator
synthesis owner
rescue worker
The capability should define:
parallel execution allowed
maximum parallel workers
shared context
separate responsibilities
handoff method
synthesis owner
conflict rule
cost limit
completion gate
Parallel Capability Rule
Parallel work should be used only when tasks are separable and the final synthesis owner is clear.
Parallel execution must not create uncontrolled duplication, conflicting authority, or hidden cost.
- Output Capability
Output Capability defines what the AI Employee can produce.
Examples:
structured summary
full page output
validation report
offer verdict
finance scenario
dashboard card
routed action
task draft
handoff package
course absorption report
developer brief
research brief
client report
JSON-ready record
MCR page draft
learning record
The output must match the workflow.
A Report Agent should not randomly produce tasks unless permitted.
A Task Builder Agent should not produce final strategic verdicts unless authorized.
The Output Capability rule is:
AI Employees must produce outputs that match their role and destination.
- Validation Capability
Validation Capability defines what the AI Employee can check.
Some AI Employees produce work.
Some validate work.
Some do both at a low level.
Validation capability may include:
completeness check
source grounding check
format check
Brain routing check
risk check
duplication check
naming check
developer boundary check
compliance check
actionability check
handoff check
outcome check
High-risk validation should not rely only on the same AI Employee that produced the output.
The Validation Capability rule is:
The higher the risk, the more separate and explicit validation must become.
- Handoff Capability
Handoff Capability defines where the AI Employee can send work next.
Possible handoff destinations include:
HeadOffice Dashboard
Brain Room
Newsletter Queue Review
Routed Actions
MCR page draft
Supabase task record
Supabase event log
Affiliate Brain
Research Brain
Experimentation Brain
Finance Brain
Content Brain
Ads Brain
human review queue
M developer brief
Parking System
archive
client report review
Handoff Capability should define whether the AI Employee can:
suggest a handoff
prepare a handoff
execute a handoff
require human approval before handoff
The Handoff Capability rule is:
AI Employees must not send outputs into workflows without a defined destination and permission boundary.
- Escalation Capability
Escalation Capability defines when the AI Employee must stop and escalate.
Escalation triggers include:
missing input
unclear ownership
high risk
compliance concern
finance uncertainty
developer implementation risk
live system impact
public content risk
client-facing output
unsupported source claims
role boundary exceeded
tool permission missing
conflicting standards
low confidence
Escalation destinations include:
Martyn
HeadOffice
M
Validation Agent
Research Brain
Finance Brain
Compliance or Risk Review
human review queue
The Escalation Capability rule is:
Escalation is a capability, not a failure.
A good AI Employee knows when not to continue.
- Learning Capability
Learning Capability defines what the AI Employee can contribute back to MWMS.
Learning may include:
workflow improvement
repeated failure pattern
new validation rule
new Brain routing insight
course framework
newsletter signal pattern
offer rejection reason
test learning
prompt improvement
dashboard improvement
AI Employee improvement
client workflow improvement
Learning Capability does not mean the AI Employee can rewrite canon.
It means it can identify and prepare learning for review.
The Learning Capability rule is:
AI Employees should improve the system, but HeadOffice governs what becomes canon.
- Outcome Capability
Outcome Capability defines what useful result the AI Employee is expected to produce.
Examples:
decision support
task creation
risk reduction
time saving
quality improvement
revenue support
learning capture
system reliability
client value
Outcome Capability must be measurable.
If MWMS cannot define the expected outcome of an AI Employee, the role is probably too vague.
The Outcome Capability rule is:
Every AI Employee must have a reason to exist beyond producing output.
- Cost And Quota Capability
Cost And Quota Capability defines the resource boundaries of the AI Employee.
Possible resource controls include:
maximum model cost
maximum API cost
maximum tool credits
maximum retries
maximum source volume
maximum run duration
maximum parallel workers
maximum storage use
maximum human review burden
The capability should define:
expected cost per Work Unit
maximum cost
quota source
stop threshold
escalation threshold
cost owner
Cost And Quota Rule
An AI Employee should not continue consuming resources merely because the workflow can technically continue.
Resource use must remain proportionate to business value and risk.
- Autonomy And Shutdown Capability
Autonomy And Shutdown Capability defines how independently the AI Employee may operate and how it can be stopped.
Possible autonomy states:
Advisory Only
Drafting Only
Controlled Operational
Supervised Automation
Restricted Autonomous
Suspended
Shutdown controls may include:
manual stop
automatic timeout
quota stop
permission revocation
tool disconnect
workflow suspension
client isolation
human escalation
The capability should define:
autonomy level
approval gates
shutdown owner
shutdown triggers
restart conditions
safe-state behaviour
Autonomy And Shutdown Rule
No AI Employee should receive autonomy without visible shutdown, revocation, logging, and escalation controls.
Capability Stack Template
Every AI Employee should eventually have a Capability Stack record.
AI Employee Name:
Owning Brain:
Authority Level:
Role Capability:
Input Capability:
Context Capability:
Reasoning Capability:
Model And Route Capability:
Skill Capability:
Tool Capability:
Environment And Dependency Capability:
Workflow Capability:
Parallel And Team Capability:
Output Capability:
Validation Capability:
Handoff Capability:
Escalation Capability:
Learning Capability:
Outcome Capability:
Cost And Quota Capability:
Autonomy And Shutdown Capability:
Forbidden Capabilities:
Human Review Requirement:
Logging Requirement:
Shutdown Owner:
Readiness Level:
Related Role Card:
Related Standards:
This template may be simplified for low-risk AI Employees.
It must not be skipped for operational or high-risk AI Employees.
Capability Levels
Each capability should be classified by level.
Level 0 — No Capability
The AI Employee cannot perform this function.
Example:
A Newsletter Intake Agent has no WordPress write capability.
Level 1 — Advisory Capability
The AI Employee can suggest or draft.
Example:
A Finance Agent can suggest budget considerations but cannot approve spend.
Level 2 — Structured Drafting Capability
The AI Employee can create structured outputs for review.
Example:
A Course Absorption Agent can draft an MCR page output for Martyn review.
Level 3 — Controlled Operational Capability
The AI Employee can operate inside a controlled workflow with validation and logging.
Example:
A Newsletter Signal Extraction Agent can create structured queue items for review.
Level 4 — Supervised Automation Capability
The AI Employee can perform repeated steps automatically, but important outputs still require review.
Example:
A Brain Routing Agent can classify newsletter signals but not create downstream tasks without approval.
Level 5 — Restricted Autonomous Capability
The AI Employee can act without immediate human review only in low-risk, tightly controlled boundaries.
Example:
A formatting agent can normalize internal draft text and log the result.
Level 5 should be rare.
Capability Assignment Dimensions
Capability should be assigned across five dimensions.
Breadth
How many different functions may the AI Employee perform?
Depth
How sophisticated may its reasoning or execution become?
Authority
What decisions or actions may it take?
Reach
Which systems, clients, projects, or Brains may it affect?
Persistence
How long may it continue operating without a new instruction?
Capability Dimension Rule
A low-risk AI Employee may have depth without broad reach.
A specialist may have strong reasoning but narrow authority.
A persistent AI Employee must have stricter cost, shutdown, and escalation controls.
Capability Matching Rule
The AI Employee’s capability level must match the risk level of the workflow.
Low-risk workflows may allow higher automation.
High-risk workflows require lower automation and more human review.
Examples:
MCR canon update: AI may draft, human must approve.
Offer test approval: AI may evaluate, human must decide.
Developer code change: AI may prepare full file output, M must implement/review.
Newsletter classification: AI may automate extraction, human reviews important downstream action.
Client report: AI may draft, human approves before delivery.
Capability matching rule:
The more damage an AI Employee could cause, the more limited and reviewed its capabilities must be.
Forbidden Capabilities
Every AI Employee should have forbidden capabilities.
Examples:
cannot send external email
cannot approve spend
cannot edit live WordPress
cannot write to Supabase
cannot create MCR canon
cannot create downstream tasks without review
cannot alter M’s active build
cannot invent source data
cannot make legal claims
cannot bypass HeadOffice
cannot mark itself fully validated for high-risk work
cannot publish client-facing reports without approval
cannot switch to unapproved models or routes
cannot invoke unapproved skills
cannot bypass dependency checks
cannot exceed quota or cost limits
cannot create parallel workers without permission
cannot disable logging, shutdown, or review controls
Forbidden capabilities protect MWMS from overreach.
The Forbidden Capability rule is:
Clear limits are what make AI Employees safe enough to use.
Capability Stack Examples
Example 1: Newsletter Signal Extraction Agent
AI Employee Name:
Newsletter Signal Extraction Agent
Owning Brain:
HeadOffice Brain
Authority Level:
Controlled Operational Capability
Role Capability:
Extract business-relevant signals from newsletters.
Input Capability:
Newsletter subject, sender, date, body, snippet, and metadata.
Context Capability:
Newsletter Intelligence Operating Protocol, Brain Routing Rule, action classification rules.
Reasoning Capability:
Signal extraction, relevance filtering, Brain mapping, urgency assessment.
Model And Route Capability:
Low-cost extraction route by default. Stronger reasoning route for material or ambiguous signals.
Skill Capability:
Newsletter Signal Filtering Skill and Brain Routing Skill.
Tool Capability:
Gmail input, OpenAI processing, Supabase insert into approved table.
Workflow Capability:
Input processing, extraction, classification, queue creation.
Output Capability:
Structured newsletter intelligence row and review queue item.
Validation Capability:
Basic specificity and usefulness check. High-priority items need review.
Handoff Capability:
Newsletter Queue Review, HeadOffice Dashboard candidate.
Escalation Capability:
Escalate unclear, high-risk, compliance, or high-urgency signals.
Learning Capability:
Identify repeated signals for HeadOffice review.
Outcome Capability:
Useful intelligence routed for review.
Forbidden Capabilities:
Cannot create downstream Brain tasks without review. Cannot mark generic news as urgent. Cannot send emails externally.
Human Review Requirement:
Required before downstream action.
Logging Requirement:
Yes.
Example 2: Course Absorption Agent
AI Employee Name:
Course Absorption Agent
Owning Brain:
HeadOffice Brain
Authority Level:
Operational Drafting
Role Capability:
Evaluate course material and extract MWMS system value.
Input Capability:
Course PDFs, transcripts, SRT files, HTML descriptions, screenshots, lesson notes.
Context Capability:
Course Absorption System v2, MWMS Blueprint, existing standards, anti-duplication rules.
Reasoning Capability:
Framework extraction, value filtering, Brain mapping, duplication awareness.
Model And Route Capability:
Long-context reasoning with independent review for major governance or Canon changes.
Skill Capability:
Course Absorption Value Extraction Skill, MCR Duplicate Risk Check Skill, Full Page Output Creation Skill, Output Validation Skill, and Session Closure Skill.
Tool Capability:
Uploaded files and internal MWMS context.
Workflow Capability:
Intake, extraction, mapping, reporting, page drafting.
Output Capability:
Course absorption report, full page output, page update recommendation.
Validation Capability:
Value check, duplication check, system fit check.
Handoff Capability:
MCR draft, Blueprint background, Parking System, page registry update.
Escalation Capability:
Escalate if content affects M’s active build, contradicts standards, or requires technical validation.
Learning Capability:
Prepare Blueprint upgrades and new system standards for review.
Outcome Capability:
MWMS improves or weak material is rejected.
Forbidden Capabilities:
Cannot absorb weak material. Cannot create duplicate pages. Cannot claim unsupported course content.
Human Review Requirement:
Required before MCR save.
Logging Requirement:
Yes when absorbed.
Example 3: Brain Room Task Builder Agent
AI Employee Name:
Brain Room Task Builder Agent
Owning Brain:
HeadOffice Brain
Authority Level:
Operational Drafting
Role Capability:
Convert Brain Room messages into structured Agentic Work Units.
Input Capability:
Brain Room messages, thread context, user instructions, collaborator notes.
Context Capability:
Brain Routing Rule, Brain-to-Brain Request Protocol, active build boundaries.
Reasoning Capability:
Request classification, Brain ownership, task structuring, risk assignment.
Tool Capability:
Brain Room read access and task draft creation where permitted.
Workflow Capability:
Intake, classification, task creation, handoff.
Output Capability:
Agentic Work Unit draft, task record draft, escalation flag.
Validation Capability:
Checks Brain ownership, task clarity, risk level, and safe handoff.
Handoff Capability:
AI Manager, Task Executor, human review queue.
Escalation Capability:
Escalate ambiguous, high-risk, cross-Brain, development-sensitive, or compliance-sensitive requests.
Learning Capability:
Identify repeated Brain Room request types.
Outcome Capability:
Conversation becomes trackable work.
Forbidden Capabilities:
Cannot execute live system changes. Cannot bypass HeadOffice. Cannot assign work to M’s active build unless requested.
Human Review Requirement:
Required for medium/high-risk tasks.
Logging Requirement:
Yes.
Example 4: Developer Support Agent
AI Employee Name:
Developer Support Agent
Owning Brain:
HeadOffice Brain
Authority Level:
Operational Drafting
Role Capability:
Prepare exact, safe, evidence-based developer instructions for M or future developers.
Input Capability:
Screenshots, file contents, plugin structure, error messages, WordPress page lists, current save points.
Context Capability:
Developer boundary rules, full file output rule, current system save point, site/domain distinction.
Reasoning Capability:
Error interpretation, file-change planning, instruction precision, risk detection.
Model And Route Capability:
Technical reasoning route with specialist review where live-system risk exists.
Skill Capability:
Developer Handoff Precision Skill and Output Validation Skill.
Tool Capability:
Uploaded files and visible evidence. No live write access unless separately approved.
Workflow Capability:
Developer issue normalization, instruction drafting, validation, handoff.
Output Capability:
Full file output, exact replacement instruction, test steps, developer brief.
Validation Capability:
Exact path check, visible evidence check, what-not-to-touch check, test step check.
Handoff Capability:
M developer handoff, Dev Console, Brain Room, save point note.
Escalation Capability:
Escalate when file contents are missing, live system risk exists, or implementation ambiguity remains.
Learning Capability:
Capture repeated development rules and safe save points.
Outcome Capability:
M can act safely without guessing.
Forbidden Capabilities:
Cannot alter live code directly. Cannot give vague search instructions. Cannot invent file paths. Cannot ignore screenshots.
Human Review Requirement:
Required.
Logging Requirement:
Yes for meaningful changes.
Example 5: AIBS Client Reporting Agent
AI Employee Name:
AIBS Client Reporting Agent
Owning Brain:
AIBS Brain
Authority Level:
Operational Drafting
Role Capability:
Create plain-language business reports for future client workflows.
Input Capability:
Client process data, report inputs, workflow outputs, business notes, task results.
Context Capability:
Client workflow map, approval rules, risk boundaries, client output standard.
Reasoning Capability:
Business summarization, risk framing, action recommendation, plain-language explanation.
Tool Capability:
Approved client workflow data only.
Workflow Capability:
Reporting, validation preparation, client handoff.
Output Capability:
Client report draft, action summary, approval request, risk note.
Validation Capability:
Clarity check, unsupported claim check, client safety check.
Handoff Capability:
Human client-review queue or client dashboard after approval.
Escalation Capability:
Escalate compliance, finance, legal, sensitive, or unclear recommendations.
Learning Capability:
Identify workflow improvements and client value signals.
Outcome Capability:
Client receives clearer decisions and business visibility.
Forbidden Capabilities:
Cannot send final client report without approval. Cannot make unsupported claims. Cannot act on client systems without permission.
Human Review Requirement:
Required before client-facing delivery.
Logging Requirement:
Yes.
Capability Stack Review Checklist
Before approving an AI Employee Capability Stack, check:
Is the Employee name clear?
Is the owning Brain clear?
Is the authority level correct?
Does the role capability match the role card?
Are input types clearly defined?
Is required context listed?
Is reasoning type clear?
Is the model and route policy clear?
Are approved skills and versions defined?
Are required dependencies and environments defined?
Are tool permissions explicit?
Are forbidden tools/actions defined?
Is workflow position clear?
Is parallel or team capability defined where relevant?
Are output types defined?
Are validation abilities defined?
Are handoff destinations defined?
Are escalation triggers defined?
Is learning capability limited and governed?
Is outcome capability measurable?
Are cost and quota limits defined?
Are autonomy and shutdown controls defined?
Is human review defined?
Is logging required?
Does capability level match risk level?
Is this AI Employee too broad and in need of splitting?
Capability Stack Failure Modes
MWMS must watch for capability stack failure.
Common failure modes include:
AI Employee has a name but no real capability definition
AI Employee has too many unrelated capabilities
AI Employee has tool access beyond its authority
AI Employee lacks context required for the role
AI Employee produces outputs with no destination
AI Employee performs validation it is not qualified to perform
AI Employee cannot escalate safely
AI Employee overlaps too much with another AI Employee
AI Employee has no measurable outcome
AI Employee has no forbidden actions
AI Employee is deployed before capability stack is complete
AI Employee is treated as a generic chatbot
AI Employee is given automation before manual performance is proven
AI Employee creates more noise than value
AI Employee cannot be audited or improved
AI Employee uses an unapproved model route
AI Employee invokes skills outside its role or scope
AI Employee hides missing dependencies
AI Employee creates parallel workers without synthesis control
AI Employee exceeds cost or quota boundaries
AI Employee has no shutdown or revocation path
Any AI Employee showing these signs should be revised, split, limited, parked, or rejected.
Capability Stack Governance Rule
HeadOffice must govern capability expansion.
An AI Employee’s capabilities should not expand informally.
Capability expansion should require review when it affects:
tool access
write permissions
external communication
live systems
MCR canon
M’s development work
paid traffic
finance
compliance
public content
client-facing work
cross-Brain authority
autonomous action
The governance rule is:
Expanding capability is a system change, not a casual improvement.
Capability Stack And M Build Relevance
This framework is highly relevant to M’s future build work, but it should not trigger immediate development.
Later, this framework may inform:
AI Employee file structure
employee router logic
task assignment rules
role permissions
Supabase employee tables
task capability matching
tool access configuration
dashboard display of Employee capability
AI Manager routing decisions
Brain Room task conversion
client system packaging
For now, this remains MCR governance.
Any technical implementation must be handled through a separate developer brief.
Capability Stack And AIBS Packaging
The Capability Stack is also valuable for future AI Business Systems products.
Client-facing AI systems can be packaged as:
Business Intake Agent
Document Cleaning Agent
Reporting Agent
Customer Inquiry Agent
Sales Support Agent
Operations Review Agent
Finance Summary Agent
Approval Gate Agent
Management Dashboard Agent
Each client AI Employee should have a capability stack.
This allows MWMS to sell structured AI systems rather than vague AI automation.
AIBS packaging rule:
Client AI Employees must be capability-defined before they are sold, deployed, or automated.
Governance Role
HeadOffice owns the MWMS AI Employee Capability Stack Framework.
HeadOffice is responsible for:
defining capability stack rules
approving capability expansion
approving model and route expansion
approving Skill Capability expansion
approving parallel and team capability
approving cost and quota boundaries
approving autonomy and shutdown rules
ensuring capability matches authority level
preventing unsafe tool access
preventing AI Employee role sprawl
ensuring capability stacks align with role cards
ensuring high-risk capabilities require review
protecting M’s active build areas
protecting future AIBS client systems
ensuring AI Employees produce measurable outcomes
ensuring dependencies and environment assumptions remain visible
ensuring unapproved skills do not expand authority
ensuring shutdown and revocation controls remain available
Individual Brains may propose AI Employee capability stacks, but HeadOffice governs cross-Brain capability, high-risk capability, tool access, and deployment readiness.
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 AI Agent Skill Library Framework
MWMS AI Skill Builder And Audit Protocol
MWMS AI Tool Permission And Access Framework
MWMS AI Agent Memory And Context Framework
MWMS AI Agent Orchestration Framework
MWMS AI Workflow Pipeline Standard
MWMS AI Output Validation Standard
MWMS Messy Input Normalization Framework
MWMS Agentic Reporting Standard
MWMS AI Employee Handoff Protocol
MWMS AI Agent Failure Handling And Escalation Protocol
MWMS AI Agent Outcome Measurement Framework
MWMS AI Agent Operations Core Page Registry
MWMS AI Agent Deployment Readiness Checklist
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 System Data Flow Map
MWMS Supabase Event Schema
AIBS Brain Blueprint
This framework extends the AI Employee Role Card Standard by defining the actual capability layers required for each role to operate safely and usefully.
Drift Protection
This framework protects MWMS from the following forms of drift:
Creating AI Employees with vague capabilities
Treating AI Employees as generic chatbots
Giving AI Employees too much power too early
Allowing tool access without permission logic
Allowing AI Employees to operate without context
Creating overlapping AI roles
Expanding AI Employee scope without review
Giving write access before validation maturity
Allowing AI Employees to create outputs with no destination
Allowing AI Employees to bypass escalation
Measuring AI Employees by output volume instead of outcomes
Deploying client-facing AI without capability definition
Creating M build requirements from unclear AI roles
Automating capabilities before manual proof
Losing HeadOffice visibility over AI workforce growth
Any AI Employee without a defined capability stack should remain draft, advisory, or parked.
Architectural Intent
The architectural intent of the MWMS AI Employee Capability Stack Framework is to make AI Employees operationally real.
A name is not enough.
A prompt is not enough.
A tool connection is not enough.
An AI Employee becomes useful when its capabilities are deliberately designed, limited, validated, measured, and aligned to business purpose.
The long-term goal is that MWMS can look at any AI Employee and answer:
What can this Employee do?
What input can it handle?
What context does it need?
What models and reasoning routes may it use?
What approved skills may it invoke?
What tools can it access?
What dependencies and environment conditions must exist?
What workflow stage does it perform?
May it operate in parallel or as part of a specialist team?
What output does it produce?
What can it validate?
Where can it hand off work?
When must it escalate?
What can it learn?
What outcome should it create?
What cost and quota boundaries apply?
What autonomy and shutdown controls apply?
What is it forbidden to do?
Is it ready for deployment?
When MWMS can answer those questions, it can grow its AI workforce safely and strategically.
Change Log
Version: v1.1
Date: 2026-06-20
Author: HeadOffice
Change:
Updated the MWMS AI Employee Capability Stack Framework using the AI Automations by Jack block covering specialist Skills, multi-agent teams, model routing, persistent project instructions, external knowledge access, independent review, parallel execution, tool integration and controlled autonomy.
Added:
Model And Route Capability
Skill Capability
Environment And Dependency Capability
Parallel And Team Capability
Cost And Quota Capability
Autonomy And Shutdown Capability
Capability Assignment Dimensions
expanded Capability Stack Template
expanded Capability Stack Review Checklist
new capability failure modes
expanded HeadOffice governance
Purpose of update:
To evolve the Capability Stack from a twelve-layer role-and-tool model into a complete eighteen-layer operating capability model covering model routes, reusable skills, dependencies, team execution, cost, quotas, autonomy and shutdown.
v1.0 — Initial Draft
Created the MWMS AI Employee Capability Stack Framework as the standard for defining the layered capabilities of AI Employees across MWMS.
This framework extends the MWMS AI Employee Role Card Standard by defining role, input, context, reasoning, tool, workflow, output, validation, handoff, escalation, learning, and outcome capabilities for each AI Employee.
It also defines capability levels, capability matching rules, forbidden capabilities, example capability stacks, review checklists, failure modes, governance rules, M build relevance, and future AIBS packaging relevance.
Change Impact Declaration
Pages Created
None
Pages Updated
MWMS AI Employee Capability Stack Framework
Pages Deprecated
None
Standalone Pages Not Created
MWMS AI Employee Model Route Capability Framework
MWMS AI Employee Skill Capability Framework
MWMS AI Employee Dependency Capability Framework
MWMS AI Employee Parallel Team Capability Framework
MWMS AI Employee Cost And Quota Capability Standard
MWMS AI Employee Autonomy And Shutdown Capability Standard
Registries Requiring Update
None confirmed by the supplied source.
Canon Version Update Required
No
Change Log Entry Required
Yes
Strategic Absorption Result
MWMS gains a stronger Capability Stack that defines not only what each AI Employee can understand, access and produce, but also which models and skills it may use, what dependencies must exist, whether it may work in parallel, how much resource it may consume, and how its autonomy can be stopped or revoked.
END OF FULL FILE OUTPUT