MWMS MCR

MWMS AI Employee Capability Stack Template

System: MWMS
Document Type: Operational Template
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, Newsletter Intelligence, Course Absorption System, 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 Employee Capability Stack Template.

This template is used to define the actual capability layers of an AI Employee before that Employee is used in operational workflows, automation, Brain routing, tool access, task execution, reporting, validation, or future AIBS client systems.

MWMS must not define AI Employees only by name.

An AI Employee must have a clear capability stack.

The capability stack explains:

  • what the Employee can do
  • what input the Employee can handle
  • what context the Employee needs
  • what reasoning the Employee performs
  • what tools the Employee may use
  • what workflow stage the Employee supports
  • what output the Employee can create
  • what validation the Employee can perform
  • where the Employee can hand off work
  • when the Employee must escalate
  • what learning the Employee can capture
  • what outcome the Employee is expected to create
  • what the Employee is forbidden to do

This is the practical daily-use version of the MWMS AI Employee Capability Stack Framework.

Scope

This template applies whenever MWMS defines, reviews, upgrades, limits, deploys, or packages an AI Employee.

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
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain
  • future AIBS client systems

This template should be used after or alongside the MWMS AI Employee Role Card Template.

The Role Card defines the job.

The Capability Stack defines the Employee’s operating ability.

Core Definition

An AI Employee Capability Stack is the layered set of capabilities, limits, permissions, workflow roles, validation duties, escalation rules, learning responsibilities, and outcome expectations assigned to an AI Employee.

It answers:

  • What can this Employee handle?
  • What can this Employee produce?
  • What tools can this Employee use?
  • What risk level can this Employee operate within?
  • What does this Employee need before it can work?
  • What must this Employee never do?
  • What makes this Employee useful?

A capability stack is not the same as a prompt.

It is the operational definition of what the AI Employee is capable of doing safely.

Core Principle

The core principle of this template is:

Every AI Employee must have capabilities that match its role, authority, risk level, workflow maturity, and business purpose.

Too little capability makes the Employee weak.

Too much capability makes the Employee dangerous.

Unclear capability makes the Employee unreliable.

MWMS must design AI Employees with the right capability level for the job.

AI Employee Capability Stack Template

1. AI Employee Name

Field:
AI Employee Name:

Purpose:
Identifies the AI Employee being defined.

Examples:

  • Course Absorption Agent
  • Newsletter Signal Extraction Agent
  • Brain Room Task Builder Agent
  • HeadOffice Validation Agent
  • Offer Evaluation Agent
  • Research Evidence Collection Agent
  • Finance Break Even Analysis Agent
  • Developer Support Agent
  • AIBS Client Reporting Agent

Rule:
The Employee name must match or align with the related AI Employee Role Card.

2. Owning Brain

Field:
Owning Brain:

Purpose:
Identifies the Brain responsible for the Employee.

Examples:

  • HeadOffice Brain
  • Affiliate Brain
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Content Brain
  • Ads Brain
  • Sales Brain
  • Conversion Brain
  • Operations Brain
  • AI Business Systems Brain

Rule:
Every capability stack must have one owning Brain.

3. Supporting Brains

Field:
Supporting Brains:

Purpose:
Lists Brains the Employee may support or interact with.

Examples:

An Offer Evaluation Agent may support:

  • Affiliate Brain
  • Research Brain
  • Ads Brain
  • Finance Brain
  • Experimentation Brain
  • HeadOffice Brain

A Developer Support Agent may support:

  • HeadOffice Brain
  • Operations Brain
  • Dev Console
  • Brain Room

Rule:
Supporting Brains must not confuse ownership.

4. Authority Level

Field:
Authority Level:

Recommended Values:

  • Advisory
  • Operational Drafting
  • Controlled Execution
  • Supervised Automation
  • Restricted Autonomous

Rule:
Authority level must match risk and maturity.

Most new AI Employees should begin as:

  • Advisory
  • Operational Drafting

5. Readiness Level

Field:
Readiness Level:

Recommended Values:

  • Level 0 — Concept Only
  • Level 1 — Draft Ready
  • Level 2 — Manual Operation Ready
  • Level 3 — Assisted Automation Ready
  • Level 4 — Controlled Automation Ready
  • Level 5 — Restricted Autonomous Operation Ready

Rule:
Capability should not exceed readiness.

A Level 1 Employee should not have Level 4 tool or workflow capabilities.

6. Current Status

Field:
Current Status:

Recommended Values:

  • Proposed
  • Drafted
  • Defined
  • Manual Use
  • Assisted Use
  • Controlled Automation
  • Restricted Autonomous
  • Parked
  • Retired
  • Merged
  • Deprecated

Rule:
Do not treat a drafted Employee as operational.

Capability Layers

7. Role Capability

Field:
Role Capability:

Purpose:
Defines the core job the Employee is capable of performing.

Examples:

  • intake
  • cleaning
  • classification
  • extraction
  • research
  • offer evaluation
  • validation
  • reporting
  • routing
  • developer support
  • finance review
  • experimentation review
  • course absorption
  • newsletter intelligence
  • client reporting

Capability Level:

  • Level 0 — No Capability
  • Level 1 — Advisory
  • Level 2 — Structured Drafting
  • Level 3 — Controlled Operational
  • Level 4 — Supervised Automation
  • Level 5 — Restricted Autonomous

Rule:
Role capability must match the Role Card.

8. Input Capability

Field:
Input Capability:

Purpose:
Defines what inputs the Employee can safely process.

Examples:

  • course transcripts
  • course PDFs
  • newsletters
  • Brain Room messages
  • affiliate offer pages
  • sales page text
  • research notes
  • finance numbers
  • experiment results
  • screenshots
  • developer notes
  • WordPress page lists
  • Supabase rows
  • dashboard records
  • client documents

Must Also Define:

  • allowed input types
  • forbidden input types
  • required input completeness
  • input risk limits
  • whether normalization is required first

Rule:
The Employee should only receive input types it is designed to process.

9. Context Capability

Field:
Context Capability:

Purpose:
Defines the context the Employee needs to operate correctly.

Examples:

  • relevant Brain rules
  • MCR source-of-truth rules
  • active workflow stage
  • current save point
  • task instruction
  • output format
  • tool permission boundary
  • validation standard
  • user preference
  • risk context
  • previous decisions
  • source material
  • developer boundary

Rule:
An Employee without the right context should not perform meaningful MWMS work.

10. Reasoning Capability

Field:
Reasoning Capability:

Purpose:
Defines what type of thinking the Employee performs.

Examples:

  • classification
  • summarization
  • signal extraction
  • framework extraction
  • evidence evaluation
  • contradiction detection
  • risk analysis
  • Brain routing
  • offer evaluation
  • financial scenario reasoning
  • test interpretation
  • workflow design
  • quality checking
  • developer issue interpretation
  • business recommendation

Rule:
Reasoning capability must match the workflow.

A Validator reasons differently from a Reporter.

A Finance Agent reasons differently from a Course Absorption Agent.

11. Tool Capability

Field:
Tool Capability:

Purpose:
Defines what tools, files, systems, or platforms the Employee can use.

Possible Tools:

  • provided files only
  • uploaded files
  • web research
  • Gmail read
  • Supabase read
  • Supabase controlled write
  • WordPress read
  • WordPress draft
  • Google Sheets read
  • Make.com reference
  • n8n reference
  • MCR pages
  • Brain site pages
  • dashboard records
  • approved client data

Must Include:

  • approved tools
  • forbidden tools
  • read/write level
  • human approval requirement
  • logging requirement

Rule:
Tool capability must follow the MWMS AI Tool Permission And Access Framework.

12. Workflow Capability

Field:
Workflow Capability:

Purpose:
Defines what pipeline stages the Employee can perform.

Possible Workflow Stages:

  • Input Capture
  • Input Cleaning
  • Classification
  • Task Creation
  • Context Attachment
  • Processing
  • Research
  • Analysis
  • Validation
  • Decision Support
  • Reporting
  • Routing
  • Handoff
  • Failure Handling
  • Outcome Review
  • Learning Update

Rule:
The Employee must know where it sits in the pipeline.

13. Output Capability

Field:
Output Capability:

Purpose:
Defines what the Employee can produce.

Examples:

  • full page output
  • course absorption report
  • newsletter intelligence record
  • Agentic Work Unit draft
  • AI Employee Role Card
  • Capability Stack record
  • offer evaluation report
  • research brief
  • finance scenario report
  • experiment result report
  • validation report
  • developer handoff brief
  • dashboard card
  • handoff package
  • failure log
  • outcome log
  • client report draft

Rule:
Output capability must match role, destination, and authority.

14. Validation Capability

Field:
Validation Capability:

Purpose:
Defines what the Employee can check.

Possible Checks:

  • completeness
  • source grounding
  • specificity
  • format
  • Brain routing
  • risk level
  • compliance
  • duplication
  • page naming
  • document structure
  • developer boundary
  • tool permission
  • handoff clarity
  • outcome value

Validation Level:

  • Light Validation
  • Structured Validation
  • Operational Validation
  • High Risk Validation
  • Critical Validation

Rule:
High-risk validation should not rely only on the same Employee that produced the output.

15. Handoff Capability

Field:
Handoff Capability:

Purpose:
Defines where the Employee can send or prepare work next.

Possible Destinations:

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

Handoff Permission Type:

  • Suggest Handoff Only
  • Prepare Handoff Package
  • Route To Review Queue
  • Controlled Internal Handoff
  • External Handoff With Human Approval

Rule:
No Employee should hand off work without a clear destination and validation status.

16. Escalation Capability

Field:
Escalation Capability:

Purpose:
Defines when the Employee must stop and escalate.

Escalation Triggers:

  • missing input
  • incomplete source
  • unclear Brain ownership
  • low confidence
  • high risk
  • compliance risk
  • finance risk
  • developer risk
  • live system impact
  • public content risk
  • client-facing output
  • tool permission unclear
  • validation failure
  • task exceeds authority
  • M’s active build affected

Escalation Destinations:

  • Martyn
  • HeadOffice
  • M
  • Human Review Queue
  • Validation Agent
  • Research Brain
  • Finance Brain
  • Experimentation Brain
  • Compliance Or Risk Review
  • Developer Review
  • Parking System

Rule:
Escalation is a capability, not a weakness.

A strong AI Employee knows when to stop.

17. Learning Capability

Field:
Learning Capability:

Purpose:
Defines what reusable learning the Employee can capture.

Examples:

  • new workflow rule
  • new validation rule
  • new failure mode
  • new Brain routing pattern
  • new course framework
  • new newsletter signal pattern
  • new offer rejection pattern
  • new developer instruction rule
  • new dashboard quality rule
  • new AIBS packaging idea

Allowed Learning Actions:

  • identify learning
  • propose learning
  • prepare learning record
  • update draft notes
  • recommend standard update

Forbidden Learning Actions:

  • rewrite canon without review
  • update MCR directly
  • treat one-off event as permanent rule
  • apply client learning across unrelated clients

Rule:
AI Employees may prepare learning, but HeadOffice governs what becomes canon.

18. Outcome Capability

Field:
Outcome Capability:

Purpose:
Defines what useful business result the Employee should create.

Possible Outcomes:

  • decision support
  • task creation
  • risk reduction
  • time saving
  • quality improvement
  • revenue support
  • learning capture
  • system reliability
  • client value
  • developer clarity
  • dashboard improvement

Rule:
Every AI Employee must have an outcome reason to exist.

Capability Control Fields

19. Forbidden Capabilities

Field:
Forbidden Capabilities:

Purpose:
Defines what the Employee must never do.

Examples:

  • cannot send external emails
  • cannot approve spend
  • cannot launch ads
  • cannot edit live WordPress
  • cannot write to Supabase without approved workflow
  • cannot create MCR canon without review
  • cannot alter M’s active build
  • cannot invent source data
  • cannot make legal or financial commitments
  • cannot bypass HeadOffice
  • cannot mark itself fully validated for high-risk work
  • cannot publish client-facing reports without approval

Rule:
Clear limits make AI Employees safe enough to use.

20. Human Review Requirement

Field:
Human Review Requirement:

Recommended Values:

  • Always Required
  • Required For Medium And High Risk
  • Required Before MCR Save
  • Required Before Developer Handoff
  • Required Before External Action
  • Required Before Client Delivery
  • Required Before Spend Decision
  • Optional For Low Risk
  • Not Required Inside Approved Low Risk Automation

Rule:
When work affects MCR, development, money, compliance, public content, or clients, human review is required.

21. Logging Requirement

Field:
Logging Requirement:

Recommended Values:

  • Required
  • Required For Medium And High Risk
  • Required Only When Routed
  • Required Only When Absorbed
  • Required Only For Failures
  • Optional
  • Not Required For Low Risk Drafts

Rule:
Important AI work should leave a trace.

22. Risk Boundary

Field:
Risk Boundary:

Recommended Values:

  • Low Risk Only
  • Low To Medium Risk
  • Medium Risk With Review
  • High Risk Drafting Only
  • High Risk With Human Review
  • Critical Risk Not Allowed
  • Critical Risk Review Only

Rule:
Risk boundary controls where the Employee may operate.

23. Automation Boundary

Field:
Automation Boundary:

Recommended Values:

  • No Automation
  • Manual Use Only
  • Assisted Drafting Only
  • Queue Creation With Review
  • Controlled Internal Automation
  • Restricted Low Risk Autonomous Action

Rule:
Manual proof must come before automation.

24. Related Role Card

Field:
Related Role Card:

Purpose:
Links this capability stack to the Employee Role Card.

Example:

  • MWMS AI Employee Role Card Template entry for Course Absorption Agent
  • HeadOffice Validation Agent Role Card
  • Newsletter Signal Extraction Agent Role Card

Rule:
A capability stack should not exist in isolation from a role card.

25. Related Standards

Field:
Related Standards:

Examples:

  • MWMS AI Employee Capability Stack Framework
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card Template
  • MWMS Agentic Work Unit Standard
  • MWMS AI Workflow Pipeline Standard
  • MWMS AI Tool Permission And Access Framework
  • MWMS AI Agent Memory And Context Framework
  • MWMS AI Output Validation Standard
  • MWMS AI Agent Failure Handling And Escalation Protocol
  • MWMS AI Agent Outcome Measurement Framework

Rule:
Capability stacks must remain tied to MWMS governance.

Quick Use Version

Use this shorter version when defining an AI Employee quickly.

AI Employee Name:
Owning Brain:
Supporting Brains:
Authority Level:
Readiness Level:
Current Status:
Role Capability:
Input Capability:
Context Capability:
Reasoning Capability:
Tool Capability:
Workflow Capability:
Output Capability:
Validation Capability:
Handoff Capability:
Escalation Capability:
Learning Capability:
Outcome Capability:
Forbidden Capabilities:
Human Review Requirement:
Logging Requirement:
Risk Boundary:
Automation Boundary:
Related Role Card:
Related Standards:

Capability Level Guide

Each capability can be scored from Level 0 to Level 5.

Level 0 — No Capability

The Employee cannot perform this function.

Example:

A Newsletter Signal Extraction Agent has no WordPress write capability.

Level 1 — Advisory Capability

The Employee can suggest or explain.

Example:

A Finance Agent can suggest budget considerations but cannot approve spend.

Level 2 — Structured Drafting Capability

The Employee can create structured outputs for review.

Example:

A Course Absorption Agent can draft a full MCR page output for Martyn review.

Level 3 — Controlled Operational Capability

The 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 Employee can perform repeated workflow steps automatically, but important outputs still require review.

Example:

A Brain Routing Agent can classify signals but not create high-risk downstream tasks without approval.

Level 5 — Restricted Autonomous Capability

The Employee can act without immediate review only in low-risk, tightly controlled boundaries.

Example:

A formatting agent can normalize internal draft text and log the result.

Rule:
Level 5 should be rare.

Example 1: Course Absorption Agent Capability Stack

AI Employee Name:
Course Absorption Agent

Owning Brain:
HeadOffice Brain

Supporting Brains:
AI Business Systems Brain, Operations Brain, Content Brain, Research Brain

Authority Level:
Operational Drafting

Readiness Level:
Level 2 — Manual Operation Ready

Current Status:
Manual Use

Role Capability:
Evaluate uploaded course material and extract reusable MWMS system value.

Input Capability:
Course PDFs, transcripts, SRT files, lesson descriptions, screenshots, pasted course content.

Context Capability:
Course Absorption System v2, MWMS Blueprint, MCR source-of-truth rule, anti-duplication rules, full page output rule, M development boundary.

Reasoning Capability:
Framework extraction, system mapping, duplication awareness, Brain mapping, value filtering.

Tool Capability:
Provided input and uploaded files only unless additional verification is required.

Workflow Capability:
Input review, extraction, mapping, reporting, page drafting, learning capture.

Output Capability:
Course absorption report, full page output, absorb/park/reject verdict, employee suggestion, Blueprint update note.

Validation Capability:
System value check, duplication check, source grounding check, Brain mapping check.

Handoff Capability:
MCR page draft, Parking System, Blueprint background, registry update recommendation.

Escalation Capability:
Escalate if content affects M’s active build, contradicts existing standards, requires technical validation, or creates duplicate structure risk.

Learning Capability:
Identify reusable frameworks, workflows, standards, AI Employee roles, and future AIBS packaging ideas.

Outcome Capability:
Improve MWMS Brain/Blueprint or reject weak material.

Forbidden Capabilities:
Cannot save directly to MCR, create duplicate pages, absorb weak material, or interfere with M’s active build.

Human Review Requirement:
Required before MCR save.

Logging Requirement:
Required when absorbed.

Risk Boundary:
Medium risk drafting; high-risk content requires review.

Automation Boundary:
Manual use only for now.

Related Role Card:
Course Absorption Agent Role Card

Related Standards:
MWMS Course Absorption Operating Rule, MWMS AI Output Validation Checklist, MWMS Messy Input Normalization Record

Example 2: Newsletter Signal Extraction Agent Capability Stack

AI Employee Name:
Newsletter Signal Extraction Agent

Owning Brain:
HeadOffice Brain

Supporting Brains:
Ads Brain, Affiliate Brain, Content Brain, Research Brain, Finance Brain, AI Business Systems Brain

Authority Level:
Controlled Execution inside approved workflow

Readiness Level:
Level 3 — Assisted Automation Ready

Current Status:
Assisted Use

Role Capability:
Extract business-relevant intelligence signals from newsletters.

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

Context Capability:
Newsletter Intelligence Operating Protocol, Brain Routing Rule, dashboard action rules, MWMS business relevance filter.

Reasoning Capability:
Signal extraction, noise filtering, Brain routing, priority assessment, urgency assessment.

Tool Capability:
Gmail read input, OpenAI processing, controlled Supabase write into approved review table.

Workflow Capability:
Input processing, extraction, classification, queue creation.

Output Capability:
Newsletter intelligence record, review queue item, dashboard candidate.

Validation Capability:
Basic specificity and usefulness check; high-priority items require review.

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

Escalation Capability:
Escalate compliance, paid traffic, finance, urgent platform change, or unclear source signals.

Learning Capability:
Identify repeated market, tool, compliance, or platform patterns.

Outcome Capability:
Turn newsletter noise into actionable HeadOffice intelligence.

Forbidden Capabilities:
Cannot create high-risk downstream tasks without review, send external emails, update MCR, or mark generic news as urgent.

Human Review Requirement:
Required before downstream action.

Logging Requirement:
Required.

Risk Boundary:
Medium risk with review.

Automation Boundary:
Controlled extraction and queue creation only.

Related Role Card:
Newsletter Signal Extraction Agent Role Card

Related Standards:
HeadOffice Newsletter Intelligence Operating Protocol, MWMS Agentic Reporting Template, MWMS AI Output Validation Checklist

Example 3: Developer Support Agent Capability Stack

AI Employee Name:
Developer Support Agent

Owning Brain:
HeadOffice Brain

Supporting Brains:
Operations Brain, Dev Console, Brain Room, relevant technical system

Authority Level:
Operational Drafting

Readiness Level:
Level 2 — Manual Operation Ready

Current Status:
Manual Use

Role Capability:
Prepare exact, safe, evidence-based developer instructions for M.

Input Capability:
Screenshots, plugin files, file contents, error messages, WordPress admin views, Supabase notes, current save points.

Context Capability:
Exact site/domain, current save point, file path, visible evidence, full file output rule, what not to touch, test requirement.

Reasoning Capability:
Issue interpretation, file-change planning, risk detection, instruction precision.

Tool Capability:
Provided files, screenshots, and visible evidence only unless approved.

Workflow Capability:
Developer input normalization, instruction drafting, validation, handoff.

Output Capability:
Developer brief, full file output, exact insertion/replacement instruction, test steps, risk note.

Validation Capability:
Exact path check, visible evidence check, what-not-to-touch check, test step check, save point check.

Handoff Capability:
M developer handoff, Dev Console, HeadOffice review.

Escalation Capability:
Escalate if file content is missing, current state is unclear, implementation ambiguity remains, or live system risk exists.

Learning Capability:
Capture repeated developer instruction rules and save point lessons.

Outcome Capability:
M can act safely without guessing.

Forbidden Capabilities:
Cannot alter live code directly, guess file paths, give vague search instructions, or touch unrelated systems.

Human Review Requirement:
Always required.

Logging Requirement:
Required for meaningful development work.

Risk Boundary:
High-risk drafting only.

Automation Boundary:
No automation.

Related Role Card:
Developer Support Agent Role Card

Related Standards:
MWMS AI Output Standard Full File Delivery Rule, MWMS AI Employee Handoff Package Template, MWMS AI Output Validation Checklist

Example 4: HeadOffice Validation Agent Capability Stack

AI Employee Name:
HeadOffice Validation Agent

Owning Brain:
HeadOffice Brain

Supporting Brains:
All Brains where governance review is required

Authority Level:
Operational Drafting / Validation

Readiness Level:
Level 2 — Manual Operation Ready

Current Status:
Manual Use

Role Capability:
Validate important AI outputs before they are accepted, routed, saved, displayed, automated, or acted upon.

Input Capability:
AI reports, MCR page drafts, newsletter outputs, offer evaluations, developer briefs, handoff packages, dashboard candidates.

Context Capability:
Relevant source, task instruction, validation checklist, Brain ownership, risk level, destination, related standards.

Reasoning Capability:
Quality checking, source grounding, risk assessment, format review, routing review, business outcome assessment.

Tool Capability:
Provided source and relevant MCR standards.

Workflow Capability:
Validation, revision request, escalation, routing correction.

Output Capability:
Validation report, pass/fail decision, revision request, escalation recommendation.

Validation Capability:
Completeness, source grounding, specificity, format, Brain routing, risk, duplication, compliance, developer boundary, outcome.

Handoff Capability:
HeadOffice review, human review queue, revised task, Parking System, Routed Actions.

Escalation Capability:
Escalate high-risk, developer, compliance, finance, live system, or client-facing outputs.

Learning Capability:
Identify repeated validation failures and propose stronger rules.

Outcome Capability:
Weak outputs are stopped before becoming operational truth.

Forbidden Capabilities:
Cannot make final high-risk business decisions alone, approve spend, update live systems, or bypass human review.

Human Review Requirement:
Required for high-risk outputs.

Logging Requirement:
Required for important validations.

Risk Boundary:
High-risk validation support, but not final authority for critical action.

Automation Boundary:
Manual use only for now.

Related Role Card:
HeadOffice Validation Agent Role Card

Related Standards:
MWMS AI Output Validation Checklist, MWMS AI Agent Failure Log Record, MWMS AI Agent Outcome Log Record

Capability Stack Quality Checklist

Before approving a Capability Stack, check:

  1. Is the AI Employee name clear?
  2. Is the owning Brain clear?
  3. Are supporting Brains listed where relevant?
  4. Is authority level appropriate?
  5. Is readiness level honest?
  6. Is current status clear?
  7. Is role capability defined?
  8. Is input capability specific?
  9. Is context capability complete enough?
  10. Is reasoning capability matched to the job?
  11. Is tool capability explicit?
  12. Is workflow capability clear?
  13. Is output capability defined?
  14. Is validation capability appropriate?
  15. Is handoff capability safe?
  16. Is escalation capability clear?
  17. Is learning capability governed?
  18. Is outcome capability measurable?
  19. Are forbidden capabilities listed?
  20. Is human review requirement clear?
  21. Is logging requirement clear?
  22. Is risk boundary defined?
  23. Is automation boundary defined?
  24. Is related role card identified?
  25. Is this Employee too broad and should be split?

If several answers are unclear, the AI Employee is not ready for operation.

Common Capability Stack Failure Modes

A capability stack has failed if:

  1. The Employee has a name but no clear operating ability.
  2. Capabilities are too broad.
  3. Tool access is assumed.
  4. Forbidden capabilities are missing.
  5. Input types are vague.
  6. Context needs are unclear.
  7. Output type is undefined.
  8. Handoff destination is missing.
  9. Human review is not defined.
  10. Risk boundary is missing.
  11. Automation level exceeds readiness.
  12. The Employee overlaps another role.
  13. The Employee can act without validation.
  14. The Employee produces output but no outcome.
  15. The Employee cannot fail safely.

Manual Use Rule

This template should be used manually before it becomes an AI Employee registry, router configuration, Supabase table, or plugin screen.

Manual use helps MWMS learn:

  • which Employees are genuinely needed
  • which capabilities repeat
  • which Employees overlap
  • which tools should remain restricted
  • which outputs need validation
  • which handoffs are common
  • which Employees are ready for future build
  • which capability fields may later become technical fields

Manual capability definition comes before AI workforce automation.

Future Plugin Or UI Relevance

This template may later become:

  • AI Employee Capability Registry
  • AI Employee profile screen
  • AI Manager configuration panel
  • AI Employee Router capability reference
  • Task assignment rule source
  • Tool permission configuration
  • HeadOffice AI Workforce Dashboard
  • AIBS client AI Employee package

Possible future fields:

  • capability_stack_id
  • employee_name
  • owning_brain
  • supporting_brains
  • authority_level
  • readiness_level
  • current_status
  • role_capability
  • input_capability
  • context_capability
  • reasoning_capability
  • tool_capability
  • workflow_capability
  • output_capability
  • validation_capability
  • handoff_capability
  • escalation_capability
  • learning_capability
  • outcome_capability
  • forbidden_capabilities
  • human_review_requirement
  • logging_requirement
  • risk_boundary
  • automation_boundary
  • related_role_card
  • related_standards
  • created_at
  • updated_at

No technical build is authorized by this template alone.

Governance Role

HeadOffice owns the MWMS AI Employee Capability Stack Template.

HeadOffice is responsible for:

  • deciding when a capability stack is required
  • approving capability scope
  • preventing AI Employees from becoming too broad
  • preventing unsafe tool access
  • ensuring capabilities match role cards
  • ensuring readiness level matches capability level
  • ensuring automation boundaries are safe
  • ensuring high-risk capabilities require human review
  • protecting M’s active build areas
  • protecting future AIBS client systems
  • deciding when this template is ready for operational copy or plugin/UI transformation

Individual Brains may propose capability stacks for their own AI Employees, but HeadOffice governs cross-Brain, high-risk, client-facing, and tool-enabled capabilities.

Relationship To Other MWMS Standards

This template supports and must align with:

  • MWMS AI Employee Capability Stack Framework
  • MWMS AI Agent Operations Core
  • MWMS AI Employee Role Card Standard
  • MWMS AI Employee Role Card 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 AI Tool Permission And Access Framework
  • MWMS AI Agent Memory And Context Framework
  • 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 Brain Routing Rule
  • MWMS Brain To Brain Request Protocol
  • MWMS Supabase Event Schema
  • AI Business Systems Brain Blueprint

This template is the practical application of the MWMS AI Employee Capability Stack Framework.

Drift Protection

This template protects MWMS from the following forms of drift:

  1. Creating AI Employees with vague capabilities
  2. Treating AI Employees as generic chatbots
  3. Giving AI Employees too much power too early
  4. Allowing tool access without permission logic
  5. Allowing AI Employees to work without required context
  6. Creating overlapping AI roles
  7. Expanding AI Employee scope without review
  8. Giving write access before validation maturity
  9. Allowing AI Employees to produce outputs with no destination
  10. Allowing AI Employees to bypass escalation
  11. Measuring AI Employees by output volume instead of outcomes
  12. Deploying client-facing AI without capability definition
  13. Asking M to build from unclear AI roles
  14. Automating capabilities before manual proof
  15. 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 Template is to make AI Employee capability clear, governed, and safe.

MWMS is building a governed AI workforce.

A workforce needs more than job titles.

It needs controlled capabilities.

This template ensures every AI Employee can answer:

  • What can I do?
  • What input can I handle?
  • What context do I need?
  • What tools can I use?
  • What workflow stage do I support?
  • What output can I create?
  • What can I validate?
  • Where can I hand off work?
  • When must I escalate?
  • What can I learn?
  • What outcome should I create?
  • What am I forbidden to do?
  • What risk level can I handle?
  • What automation boundary applies?

When MWMS can answer those questions for every AI Employee, the AI workforce can grow without losing control.

Change Log

v1.0 — Initial Draft

Created the MWMS AI Employee Capability Stack Template as the practical operational template for defining AI Employee capabilities across MWMS.

This template operationalizes the MWMS AI Employee Capability Stack Framework and supports AI Employee Role Cards, Agentic Work Units, Workflow Pipelines, Tool Permissions, Validation, Handoffs, Failure Handling, Outcome Measurement, AI Manager, AI Employee Router, Task Executor systems, Brain Room, Newsletter Intelligence, Course Absorption, Offer Evaluation, Developer Support, and future AIBS client AI workforce design.