MWMS Agent Loop Context Schema

System: MWMS
Document Type: Schema Standard
Status: Draft For MCR
Authority: HeadOffice
Applies To: All MWMS Brains, AI Employees, Agent Loops, Deep Search Workflows, Research Workflows, Affiliate Evaluation, Ads Review, Content Workflows, Experimentation Brain, HeadOffice Intelligence, Future Client Facing AI Systems
Primary Location: MCR
Future Operational Destination: mwmsbrain.site, mwmsheadofficebrain.site, AI Employee Dashboards, Future Agent Control Dashboards
Parent Page: HeadOffice
Source Of Truth: MCR
Related Frameworks: MWMS Agent Loop Control Framework, MWMS Next Action Picker Standard, MWMS AI Observability Metadata Standard, MWMS AI Employee Evaluation Scorecard Standard, MWMS Deep Search Quality And Observability Framework
Course Source: Matt Pocock AIhero Build DeepSearch In TypeScript
Absorption Status: Approved For Integration

Purpose

The purpose of this schema standard is to define the shared context container used by MWMS AI Employee agent loops.

An agent loop context is the structured working memory that allows an AI Employee to understand:

what it is trying to achieve
which Brain owns the work
what step it is on
what actions have already happened
what evidence has been collected
what sources have been inspected
what tools have failed
what limits have been reached
whether it should continue, answer, route, escalate, park, or stop

This standard ensures AI Employees do not lose the original goal, repeat work, ignore evidence, exceed limits, or make decisions without the correct operational context.

Scope

This standard applies to any MWMS workflow where an AI Employee performs multi-step reasoning, search, tool use, routing, source inspection, or decision-making.

This includes:

Deep Search workflows
Research Brain source investigation
Affiliate Brain offer evaluation
Ads Brain compliance review
Content Brain research workflows
Newsletter Intelligence processing
HeadOffice signal routing
Experimentation Brain analysis
Data Brain validation
Finance Brain cost review
Brain Room AI support
Dev Console AI support
future client-facing AIBS agents
future autonomous AI Employees
future workflows using search, scraping, databases, tools, action pickers, or escalation logic

This standard does not define exact database tables or code implementation.

It defines the conceptual schema that future implementation should follow.

Core Rule

Every agent loop must carry a shared context object that preserves the workflow goal, current state, action history, evidence state, limits, and final outcome.

The MWMS rule is:

No AI Employee loop should operate from memory alone, prompt text alone, or hidden SDK state alone.

The loop context is the system memory for the workflow.

Definition Of Agent Loop Context

Agent Loop Context is the structured state object used during an AI Employee workflow.

It contains:

the original request
the workflow goal
the current step
the allowed actions
the action history
the evidence collected
the tools used
the source history
the database records used
the current confidence state
the cost and latency state
the stop conditions
the review and escalation state
the final output state

The context object should be available to the Next Action Picker, action executors, final answer generator, observability system, evaluation system, and HeadOffice review layer.

Why MWMS Needs Agent Loop Context

Without a structured context container, AI Employees may:

lose the original user request
answer the wrong question
repeat the same search
inspect the same source twice
forget failed tools
ignore source conflicts
exceed cost limits
exceed step limits
answer before enough evidence exists
miss escalation conditions
route to the wrong Brain
create orphaned outputs
become impossible to debug
become impossible to evaluate

A strong context schema prevents agent drift.

Relationship To Agent Loop Control

The MWMS Agent Loop Control Framework defines the full controlled agent loop.

This schema defines the state object used inside that loop.

The normal relationship is:

Agent Loop Control Framework
→ defines how the loop works

Next Action Picker Standard
→ defines how the next action is selected

Agent Loop Context Schema
→ defines what information the loop carries

AI Observability Metadata Standard
→ defines what gets logged and traced

AI Employee Evaluation Scorecard Standard
→ defines how loop quality is judged

Relationship To Next Action Picker

The Next Action Picker depends on the context schema.

The picker cannot choose correctly unless it can see:

original request
workflow goal
current step
previous actions
evidence collected
failed actions
limits
allowed actions
risk state
stop conditions
review requirements

If context is weak, the picker will be weak.

A strong Next Action Picker requires a strong context object.

Context Schema Categories

MWMS Agent Loop Context is divided into twelve categories:

Identity Context
Workflow Context
Goal Context
Parameter Context
Action Context
Search And Source Context
Evidence Context
Database Context
Tool And Failure Context
Cost And Performance Context
Review And Decision Context
Final Output And Kaizen Context

Each category exists to keep the AI Employee aligned, observable, and governable.

1. Identity Context

Identity Context defines who or what owns and triggered the workflow.

Recommended fields:

Field	Description
context_id	Unique context record ID
loop_id	Related agent loop ID
trace_id	Related observability trace ID
created_at	Context creation time
updated_at	Last context update time
user_id	User ID if available
user_name	Human operator name
user_role	Role of requester or operator
request_origin	Where the request came from
brain_name	Brain responsible for the workflow
brain_site	Site where the workflow occurs
ai_employee_name	AI Employee handling the work
ai_employee_role	Role of the AI Employee
environment	Local, test, staging, production

Rule

Every context object must identify the responsible Brain or system.

If no Brain is known, the context should be marked:

brain_name: Unclassified

and routed to HeadOffice review.

2. Workflow Context

Workflow Context defines the type and state of the work being performed.

Recommended fields:

Field	Description
workflow_type	Category of workflow
workflow_name	Specific workflow name
task_id	Related task ID
thread_id	Related conversation thread
parent_record_id	Parent offer, source, experiment, newsletter, report, or campaign
run_id	Unique workflow run ID
workflow_stage	Current workflow stage
status	Pending, running, completed, failed, parked, routed, escalated
priority	Low, medium, high, urgent
urgency	Monitor, test, act now, emergency
risk_level	Low, medium, high
trigger_type	Manual, scheduled, event based, routed, automated

Workflow Type Examples

Deep Search research
source investigation
offer evaluation
newsletter extraction
newsletter routing
compliance review
campaign analysis
content research
experiment analysis
finance review
Brain Room reply
Dev Console support
HeadOffice decision support

Rule

Every context object must define the workflow type.

If the workflow type is unclear, the system should use:

workflow_type: Unclassified AI Workflow

and route to review.

3. Goal Context

Goal Context preserves the original purpose of the workflow.

Recommended fields:

Field	Description
original_request	The original user or system request
workflow_goal	The operational goal of the workflow
expected_output_type	Answer, report, decision, task, route, scorecard, source record
success_criteria	What good output looks like
required_evidence_level	None, light, medium, high
required_freshness_level	Historical, evergreen, recent, current
required_confidence_threshold	Minimum confidence needed
user_constraints	Any constraints from the user
business_constraints	Cost, compliance, timing, scope, Brain boundary
completion_definition	What must be true for the loop to finish

Rule

Every action, picker decision, and final answer must remain tied to the original request and workflow goal.

If the context loses the goal, the loop should stop or escalate.

4. Parameter Context

Parameter Context defines the limits and configuration for the loop.

Recommended fields:

Field	Description
current_step	Current loop step number
max_steps	Maximum allowed loop steps
max_searches	Maximum search actions
max_sources_to_inspect	Maximum source inspections
max_database_queries	Maximum database queries
max_retries	Maximum retries
max_cost	Maximum estimated cost
max_latency_ms	Maximum time allowed
max_tokens	Token budget
allowed_actions	List of approved actions
allowed_tools	List of approved tools
stop_conditions	List of stop rules
escalation_conditions	List of escalation rules
fallback_action	What to do if loop cannot complete
model_policy	Which model or model class can be used

Rule

Important loop behaviour must be controlled by explicit parameters, not hidden prompt assumptions.

5. Action Context

Action Context records what the loop has already done.

Recommended fields:

Field	Description
action_history	List of previous action records
previous_action_type	Most recent action type
previous_action_status	Success, failed, skipped, partial
selected_next_action	Current selected next action
selected_action_reason	Why the picker selected it
duplicate_action_detected	Yes or no
action_count_by_type	Counts by action type
action_picker_confidence	Confidence in selected action
invalid_action_attempted	Yes or no
action_evaluation_result	Result of evaluating action choice

Recommended Action History Item

{
  "step": 1,
  "action_type": "search",
  "reason": "Need current source evidence before answering",
  "target": "current Google Ads policy for health claims",
  "status": "completed",
  "tool_used": "web_search",
  "output_summary": "Found official Google policy page and two secondary sources",
  "cost_estimate": 0.02,
  "latency_ms": 1200,
  "used_in_final_output": true,
  "failure_reason": ""
}

Rule

No loop should proceed without knowing what actions have already been attempted.

6. Search And Source Context

Search And Source Context tracks external information retrieval.

Recommended fields:

Field	Description
search_history	List of search queries performed
search_count	Number of searches completed
search_provider	Tool or provider used
search_result_count	Number of results returned
selected_source_ids	Sources selected for inspection
inspected_source_ids	Sources actually inspected
inspected_source_count	Number of inspected sources
source_urls	URLs gathered
source_titles	Titles gathered
source_types	Official, expert, commercial, user generated, unknown
source_trust_ratings	Trust ratings
source_freshness_ratings	Freshness ratings
conflicting_sources_detected	Yes or no
source_inspection_failures	Failed inspections

Recommended Search History Item

{
  "query": "current Google Ads policy health claims 2026",
  "reason": "Need current official policy evidence",
  "timestamp": "",
  "result_count": 10,
  "useful_result_count": 3,
  "follow_up_needed": true
}

Rule

Important research decisions should not rely only on final answer text.

The loop context must preserve search and source history.

7. Evidence Context

Evidence Context tracks what has been learned and whether it is enough.

Recommended fields:

Field	Description
evidence_items	Evidence gathered
evidence_summary	Short summary of current evidence
evidence_sufficiency	Weak, acceptable, strong
evidence_gaps	Missing evidence
claim_support_map	Claims mapped to evidence
source_conflicts	Conflicting evidence notes
assumptions_made	Assumptions used
confidence_basis	Why confidence is high or low
freshness_status	Current, acceptable, outdated, unknown
factuality_risk	Low, medium, high
answer_ready	Yes or no

Recommended Evidence Item

{
  "evidence_id": "",
  "source_id": "",
  "claim_supported": "",
  "evidence_summary": "",
  "freshness": "current",
  "trust_rating": "high",
  "used_in_final_answer": true,
  "limitations": ""
}

Rule

The loop should not choose final answer if evidence is not sufficient for the workflow risk level.

8. Database Context

Database Context tracks internal MWMS records involved in the workflow.

Recommended fields:

Field	Description
database_provider	Supabase, WordPress, Google Sheets, other
records_read	Internal records read
records_written	Internal records created
records_updated	Internal records updated
records_failed	Failed record operations
parent_record_id	Main parent record
source_record_ids	Related source records
task_event_ids	Related task events
queue_record_id	Queue item ID
output_record_id	Final saved output
db_operation_status	Successful, partial, failed
db_error_summary	Database errors
duplicate_detected	Yes or no
permission_status	Allowed, denied, unknown

Rule

The final answer is not complete if required database writes, task updates, or record linkages fail.

Database failures must remain visible in context.

9. Tool And Failure Context

Tool And Failure Context tracks tool use, errors, retries, and blocked actions.

Recommended fields:

Field	Description
tools_used	List of tools used
tool_call_history	History of tool calls
failed_tools	Tools that failed
tool_failure_count	Number of tool failures
retry_count	Number of retries
retry_history	Retry records
rate_limit_detected	Yes or no
permission_failure_detected	Yes or no
timeout_detected	Yes or no
blocked_action_detected	Yes or no
failure_summary	Current failure state
fallback_used	Yes or no

Recommended Tool Call Item

{
  "tool_name": "scraper",
  "tool_type": "source_inspection",
  "input_summary": "Inspect official vendor page",
  "status": "failed",
  "error_summary": "Page blocked extraction",
  "retry_count": 1,
  "latency_ms": 3000,
  "result_used": false
}

Rule

Failures are part of the context, not noise.

A loop that hides failures cannot be trusted.

10. Cost And Performance Context

Cost And Performance Context tracks whether the workflow is still worth continuing.

Recommended fields:

Field	Description
started_at	Workflow start time
updated_at	Last update time
total_latency_ms	Total elapsed time
model_latency_ms	Model latency
tool_latency_ms	Tool latency
database_latency_ms	Database latency
crawler_latency_ms	Crawler latency
token_usage	Input, output, total tokens
model_cost_estimate	Estimated model cost
tool_cost_estimate	Estimated tool cost
total_cost_estimate	Estimated total cost
cost_limit_reached	Yes or no
latency_limit_reached	Yes or no
performance_warning	Warning if slow or expensive

Rule

The loop context must know when cost, time, token, or tool limits are being approached.

The AI Employee should not spend blindly.

11. Review And Decision Context

Review And Decision Context tracks human review, routing, escalation, and decision state.

Recommended fields:

Field	Description
human_review_required	Yes or no
review_reason	Why review is required
reviewed_by	Human reviewer
review_status	Pending, approved, rejected, needs revision
decision_outcome	Proceed, reject, park, route, test, monitor, escalate
routed_to_brain	Destination Brain
routed_to_employee	Destination AI Employee
escalation_required	Yes or no
escalation_reason	Reason for escalation
risk_notes	Notes about business, compliance, finance, or client risk
approval_status	Approved, blocked, pending
next_human_action	What the human should do next

Rule

The loop context must not treat decision state as separate from the workflow.

If a decision is made, the context should show why and what happens next.

12. Final Output And Kaizen Context

Final Output And Kaizen Context records the result of the loop and improvement notes.

Recommended fields:

Field	Description
final_output_created	Yes or no
final_output_type	Answer, report, route, task, escalation, failure, parked record
final_output_location	Where final output is stored
final_answer_summary	Short summary of output
final_confidence	Final confidence score
final_limitations	Limitations of output
stop_reason	Why the loop ended
completion_status	Completed, partial, failed, parked, escalated
evaluation_score	Scorecard result if available
regression_case_created	Yes or no
kaizen_note	Improvement note
improvement_category	Prompt, tool, source, workflow, evaluation, context
recommended_follow_up	Next improvement action

Rule

Every loop must end with a controlled final state.

No silent endings.

No unresolved loop state.

Recommended Full Context Object

The following is a conceptual schema for future implementation.

{
  "context_id": "",
  "loop_id": "",
  "trace_id": "",
  "created_at": "",
  "updated_at": "",
  "environment": "",
  "user_id": "",
  "user_name": "",
  "user_role": "",
  "request_origin": "",
  "brain_name": "",
  "brain_site": "",
  "ai_employee_name": "",
  "ai_employee_role": "",
  "workflow_type": "",
  "workflow_name": "",
  "task_id": "",
  "thread_id": "",
  "parent_record_id": "",
  "run_id": "",
  "workflow_stage": "",
  "status": "",
  "priority": "",
  "urgency": "",
  "risk_level": "",
  "trigger_type": "",
  "original_request": "",
  "workflow_goal": "",
  "expected_output_type": "",
  "success_criteria": [],
  "required_evidence_level": "",
  "required_freshness_level": "",
  "required_confidence_threshold": 0,
  "user_constraints": [],
  "business_constraints": [],
  "completion_definition": "",
  "current_step": 0,
  "max_steps": 0,
  "max_searches": 0,
  "max_sources_to_inspect": 0,
  "max_database_queries": 0,
  "max_retries": 0,
  "max_cost": 0,
  "max_latency_ms": 0,
  "max_tokens": 0,
  "allowed_actions": [],
  "allowed_tools": [],
  "stop_conditions": [],
  "escalation_conditions": [],
  "fallback_action": "",
  "model_policy": "",
  "action_history": [],
  "previous_action_type": "",
  "previous_action_status": "",
  "selected_next_action": "",
  "selected_action_reason": "",
  "duplicate_action_detected": false,
  "action_count_by_type": {},
  "action_picker_confidence": 0,
  "invalid_action_attempted": false,
  "action_evaluation_result": "",
  "search_history": [],
  "search_count": 0,
  "search_provider": "",
  "search_result_count": 0,
  "selected_source_ids": [],
  "inspected_source_ids": [],
  "inspected_source_count": 0,
  "source_urls": [],
  "source_titles": [],
  "source_types": [],
  "source_trust_ratings": [],
  "source_freshness_ratings": [],
  "conflicting_sources_detected": false,
  "source_inspection_failures": [],
  "evidence_items": [],
  "evidence_summary": "",
  "evidence_sufficiency": "",
  "evidence_gaps": [],
  "claim_support_map": [],
  "source_conflicts": [],
  "assumptions_made": [],
  "confidence_basis": "",
  "freshness_status": "",
  "factuality_risk": "",
  "answer_ready": false,
  "database_provider": "",
  "records_read": [],
  "records_written": [],
  "records_updated": [],
  "records_failed": [],
  "source_record_ids": [],
  "task_event_ids": [],
  "queue_record_id": "",
  "output_record_id": "",
  "db_operation_status": "",
  "db_error_summary": "",
  "duplicate_detected": false,
  "permission_status": "",
  "tools_used": [],
  "tool_call_history": [],
  "failed_tools": [],
  "tool_failure_count": 0,
  "retry_count": 0,
  "retry_history": [],
  "rate_limit_detected": false,
  "permission_failure_detected": false,
  "timeout_detected": false,
  "blocked_action_detected": false,
  "failure_summary": "",
  "fallback_used": false,
  "started_at": "",
  "total_latency_ms": 0,
  "model_latency_ms": 0,
  "tool_latency_ms": 0,
  "database_latency_ms": 0,
  "crawler_latency_ms": 0,
  "token_usage": {
    "input_tokens": 0,
    "output_tokens": 0,
    "total_tokens": 0
  },
  "model_cost_estimate": 0,
  "tool_cost_estimate": 0,
  "total_cost_estimate": 0,
  "cost_limit_reached": false,
  "latency_limit_reached": false,
  "performance_warning": "",
  "human_review_required": false,
  "review_reason": "",
  "reviewed_by": "",
  "review_status": "",
  "decision_outcome": "",
  "routed_to_brain": "",
  "routed_to_employee": "",
  "escalation_required": false,
  "escalation_reason": "",
  "risk_notes": [],
  "approval_status": "",
  "next_human_action": "",
  "final_output_created": false,
  "final_output_type": "",
  "final_output_location": "",
  "final_answer_summary": "",
  "final_confidence": 0,
  "final_limitations": [],
  "stop_reason": "",
  "completion_status": "",
  "evaluation_score": 0,
  "regression_case_created": false,
  "kaizen_note": "",
  "improvement_category": "",
  "recommended_follow_up": ""
}

This is not mandatory as exact code.

It is the conceptual schema to guide future build work.

Minimum Required Context

MWMS does not need every field from day one.

Minimum starting context should include:

Field	Requirement
context_id	Required
loop_id	Required where loop exists
trace_id	Required where observability exists
brain_name	Required
ai_employee_name	Required where applicable
workflow_type	Required
task_id or thread_id	Required where applicable
original_request	Required
workflow_goal	Required
current_step	Required
max_steps	Required
allowed_actions	Required
action_history	Required
search_history	Required for research workflows
inspected_source_ids	Required for source workflows
evidence_summary	Required for research workflows
tools_used	Required where tools are used
failure_summary	Required where failures occur
total_cost_estimate	Recommended
human_review_required	Required for decision workflows
final_output_location	Required where output is stored
stop_reason	Required
kaizen_note	Recommended

Context Quality Levels

MWMS should classify context quality by level.

Level 1: Basic Context

Includes:

original request
Brain
workflow type
task or thread ID
current step
max steps
final output

Use for:

simple internal replies
low-risk workflows
early prototypes

Level 2: Operational Context

Includes Level 1 plus:

AI Employee
allowed actions
action history
tools used
search history where relevant
status
confidence
review flag
stop reason

Use for:

Brain Room
Dev Console
internal AI workflows
newsletter intelligence

Level 3: Governed Context

Includes Level 2 plus:

source history
evidence items
database records
cost
latency
failures
escalation state
decision outcome
review status

Use for:

Deep Search
affiliate evaluation
ads compliance
HeadOffice decision support
Research Brain workflows

Level 4: Full Production Context

Includes Level 3 plus:

full source trust and freshness
claim support map
action evaluation result
regression status
detailed cost and token usage
tool latency
database operation status
Kaizen categorisation
model and parameter version references

Use for:

production AI Employees
client-facing agents
high-risk workflows
autonomous or semi-autonomous systems

Context Update Rules

The context object must be updated after each major action.

Update triggers include:

loop starts
next action selected
tool call completed
search completed
source inspected
database queried
evidence added
failure detected
retry attempted
cost updated
confidence changed
stop condition triggered
human review required
final output created
route created
escalation created
Kaizen note added

The loop should not keep working from stale context.

Context Preservation Rule

The original request and workflow goal must never be overwritten.

They may be clarified or supplemented, but the original must remain preserved.

This prevents:

goal drift
wrong answer generation
incorrect routing
accidental task replacement
loss of user intent

Recommended fields:

original_request
clarified_request
workflow_goal
current_interpretation

Context Compaction Rule

Long-running loops may need context compaction.

Compaction should preserve:

original request
workflow goal
action history summary
evidence summary
source IDs
important failures
current confidence
stop conditions
next decision state

Compaction must not delete critical evidence, source IDs, or failure history from storage.

The LLM prompt may receive compacted context, but the system record should preserve full trace where possible.

LLM Readable Context Rule

The context stored in the database may not be the best format for the model.

Before sending context to the LLM, MWMS may format it into clear sections:

Workflow Goal:
...

Current Step:
...

Action History:
...

Evidence Collected:
...

Known Gaps:
...

Limits:
...

Decision Needed:
...

The goal is to make context easy for the model to reason over.

Storage format, LLM format, and human dashboard format can be different.

Context Validation Rule

Before the Next Action Picker runs, the context should be checked for minimum required fields.

Validation should check:

original request exists
workflow goal exists
Brain exists
workflow type exists
allowed actions exist
current step exists
max steps exists
action history exists
stop conditions exist

If critical context is missing, the picker should not proceed normally.

It should choose one of:

request more information
query database
escalate
stop with missing context reason

Context And Evidence Rule

Evidence should be stored separately from final answers.

The context should know:

what evidence exists
where it came from
whether it is strong
whether it is current
whether it conflicts
whether it supports the final answer

The final answer should not be the only place evidence appears.

This protects MWMS from polished but unsupported outputs.

Context And Stop Conditions Rule

Stop conditions must be visible in context.

The context should know:

max steps
current step
searches used
source inspections used
cost used
time used
retries used
confidence threshold
escalation triggers

The Next Action Picker cannot make safe decisions if stop conditions are hidden.

Context And Human Review Rule

Human review state must be part of context.

The context should show:

whether review is required
why review is required
who reviewed it
what decision was made
what follow-up is needed

Human review must not live only in a separate comment or dashboard note.

Context And Kaizen Rule

Kaizen learning should be captured inside or linked from context.

The context should show:

what failed
what should improve
whether an eval should be added
whether a regression case should be created
whether a prompt needs improvement
whether a tool needs improvement
whether source rules need improvement
whether the Employee should be restricted or promoted

This turns loop execution into system learning.

Context Drift Protection

This schema prevents:

AI Employees losing the original request
loops working from hidden state
repeated tool calls with no memory
source evidence disappearing
database failures being ignored
cost and latency being invisible
stop conditions being forgotten
review status being detached from output
final answers being disconnected from evidence
Kaizen learning being lost
future developers inventing inconsistent context structures

If context is missing or weak, the loop should not be trusted for important decisions.

Relationship To Other MWMS Standards

This schema supports and should align with:

MWMS Agent Loop Control Framework
MWMS Next Action Picker Standard
MWMS AI Observability Metadata Standard
MWMS AI Employee Evaluation Scorecard Standard
MWMS Deep Search Quality And Observability Framework
MWMS AI Agent Operations Core
MWMS AI Tool Permission And Access Framework
MWMS AI Workflow Pipeline Standard
MWMS AI Schema And Decision Ready Output Framework
MWMS AI Output Validation Standard
MWMS Agentic Reporting Standard
MWMS Supabase Event Schema
MWMS Brain Room Architecture
HeadOffice Operational Intelligence Framework
Research Brain Source Evaluation Framework
Data Brain Measurement Integrity Framework
Experimentation Brain Canon
MWMS Kaizen Continuous Improvement Loop
MWMS System Change Log

This schema does not replace those pages.

It defines the shared state structure required for controlled AI Employee loops.

Implementation Notes For M And Future Developers

This page is a schema standard, not a demand to implement everything immediately.

Recommended build approach:

Start with minimum context fields.
Add loop ID and trace ID.
Add Brain and AI Employee ownership.
Add action history.
Add allowed actions and stop conditions.
Add search/source history for research workflows.
Add evidence summary and source IDs.
Add failure and retry history.
Add cost and latency fields.
Add review and decision fields.
Add Kaizen fields.
Later, add full production context and dashboard views.

Do not block progress waiting for perfect context.

But do not build autonomous AI Employees that lack context.

Minimum Starting Implementation For MWMS

For early MWMS implementation, start with:

{
  "context_id": "",
  "loop_id": "",
  "trace_id": "",
  "brain_name": "",
  "ai_employee_name": "",
  "workflow_type": "",
  "task_id": "",
  "thread_id": "",
  "original_request": "",
  "workflow_goal": "",
  "current_step": 0,
  "max_steps": 0,
  "allowed_actions": [],
  "action_history": [],
  "search_history": [],
  "inspected_source_ids": [],
  "evidence_summary": "",
  "tools_used": [],
  "failure_summary": "",
  "human_review_required": false,
  "final_output_location": "",
  "stop_reason": "",
  "kaizen_note": ""
}

This gives MWMS enough structure to support controlled loops without overbuilding.

Future Enhancements

Future enhancements may include:

MWMS Agent Stop Condition Standard
MWMS Agent Action Registry
MWMS Agent Loop Dashboard Specification
MWMS Deep Search Source Record Standard
MWMS Eval Dataset Registry
MWMS Agent Loop Regression Test Library
MWMS Prompt Versioning And Parameter Control Standard
MWMS AI Employee Autonomy Level Standard
MWMS AI Employee Promotion And Restriction Standard

These should only be created when implementation or course material justifies them.

Architectural Intent

The architectural intent of this schema is to make AI Employee loops stateful, controlled, and reviewable.

MWMS is not building disposable chatbot responses.

MWMS is building AI Employees that perform work inside a business operating system.

For that to work, each Employee needs structured context.

The context object is the operational memory of the workflow.

It keeps the AI Employee aligned with the original task, aware of prior actions, aware of evidence, aware of limits, aware of failures, and accountable to HeadOffice.

A strong context schema turns AI action into governed work.

Change Log

v1.0 Initial Draft

Created the MWMS Agent Loop Context Schema based on absorbed insights from Matt Pocock AIhero Build DeepSearch In TypeScript.

Integrated principles from course blocks covering:

shared workflow context
controlled agent loops
next-action picker dependency
original request preservation
action history
search and source history
evidence tracking
database context
tool failure tracking
cost and performance state
stop condition awareness
review and decision state
Kaizen learning capture
context formatting for LLM reasoning
context validation before action selection

Established this schema as the MWMS standard for shared state inside AI Employee agent loops.