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, 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 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
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
- AI Business Systems 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 twelve layers.
- Role Capability
- Input Capability
- Context Capability
- Reasoning Capability
- Tool Capability
- Workflow Capability
- Output Capability
- Validation Capability
- Handoff Capability
- Escalation Capability
- Learning Capability
- Outcome Capability
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.
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:
Tool Capability:
Workflow Capability:
Output Capability:
Validation Capability:
Handoff Capability:
Escalation Capability:
Learning Capability:
Outcome Capability:
Forbidden Capabilities:
Human Review Requirement:
Logging Requirement:
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 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
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.
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.
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.
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:
AI Business Systems 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?
- Are tool permissions explicit?
- Are forbidden tools/actions defined?
- Is workflow position clear?
- 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?
- 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
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
- 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
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 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
- AI Business Systems 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 tools can it access?
- What workflow stage does it perform?
- 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 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
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.