# Morpheus Worker Runtime Operator Handbook
## *Redacted Public Edition*

**Version:** 0.1.0 (Public Release)
**Audience:** System Operators and AI Architects
**Author:** Ryan Cunningham

*Note: Operational commands, deployment details, network coordinates, host paths, authentication implementation, and internal source references have been intentionally removed from this public edition for security.*

# **1. What the worker runtime is**

The **Morpheus Worker Runtime** is the controlled execution layer beneath the primary orchestrating AI. The orchestrator remains the central intelligence and decides what work is needed. Domain specialist agents provide expert judgment. Workers perform narrow, repeatable jobs and return structured evidence for review.

*The simplest mental model is: The Orchestrator is the manager, specialist agents are the department leaders, and workers are temporary specialists with limited tools and a written assignment.*

The worker service runs independently from existing ingestion, content, and shipping pipelines. It does not replace or modify those systems.

| Layer | Responsibility |
| :---- | :---- |
| **Human Operator** | Sets priorities and authorizes sensitive actions |
| **Orchestrator** | Routes jobs, combines findings, and enforces boundaries |
| **Specialist Agents** | Supply domain judgment and evaluate worker evidence |
| **Worker runtime** | Executes bounded read-only jobs and records an audit trail |
| **Existing pipelines** | Continue recurring production workflows |
| **Knowledge base** | Remains the authoritative memory and document system |

# **2. Safety model**

Version 0.1 is intentionally **read-only**. It has no production credentials and no capability to publish, send email, submit forms, purchase, delete files, execute arbitrary code, run shell commands, alter CMS environments, write to cloud storage, or commit knowledge automatically.

The service runs on a private local interface, requires dedicated authentication, operates under a restricted service identity, and writes only to private application storage. Its system service uses strict OS-level sandboxing and least-privilege constraints.

| Boundary | Version 0.1 behavior |
| :---- | :---- |
| **Network** | Public HTTP and HTTPS retrieval only; private and loopback destinations are blocked inside worker jobs |
| **Credentials** | No external platform, LLM, storage, email, commerce, CMS, or social credentials |
| **Files** | Private state and pending artifacts only |
| **Actions** | Read, analyze, score, validate, and prepare pending recommendations |
| **Approvals** | Approval records can be created, approved, or denied, but approval does not grant an unavailable capability |
| **Audit** | Every job records lifecycle events, results, evidence, errors, and artifacts |

# **3. Example workers**

| Worker | Best use | Does not do |
| :---- | :---- | :---- |
| `website_qa` | Audit public pages for technical, SEO, accessibility, brand, and conversion problems | Log in, submit forms, or change the site |
| `competitive_intelligence` | Compare public competitor positioning, offers, pricing language, and conversion patterns | Scrape private data or contact competitors |
| `catalog_audit` | Validate submitted product records for missing data, duplicate SKUs, URLs, and guardrail terms | Connect to or modify commerce platforms |
| `sales_research` | Score public company pages against explicit customer-fit criteria | Collect sensitive personal data or send outreach |
| `knowledge_curator` | Validate public sources and prepare a proposed knowledge artifact | Commit to code repositories or write to cloud storage |

# **4. The worker job lifecycle**

Every job moves through a limited set of states.

| Status | Meaning | Operator action |
| :---- | :---- | :---- |
| `queued` | The request was validated and accepted | Wait or inspect the job record |
| `running` | The selected worker is executing | Wait; do not submit duplicates |
| `completed` | The worker returned a structured result | Review findings, evidence, and artifacts |
| `failed` | An unexpected execution error occurred | Inspect the error and audit events |
| `blocked` | A security rule, invalid destination, secret, or policy prevented execution | Correct the input; never bypass the control casually |
| `cancelled` | The job was stopped | Review why it was cancelled before retrying |

A completed job is **evidence for a decision**, not automatic permission to act. The orchestrator or responsible specialist agent should interpret the output.

# **5. How to write effective worker objectives**

A useful objective includes the target, the question, the expected evidence, and the boundaries.

| Weak objective | Strong objective |
| :---- | :---- |
| “Check the website” | “Audit the five supplied product pages for missing metadata, broken internal links, accessibility defects, brand wording, and weak quote paths.” |
| “Research competitors” | “Compare the three supplied public websites for minimum-order language, turnaround promises, quote calls to action, decoration methods, and trust signals.” |
| “Find leads” | “Score the supplied company pages against the three explicit account-fit criteria and cite the public evidence for every score.” |

Do not include API keys, passwords, cookies, personal records, private URLs, or production instructions in an objective or input file. The service rejects likely secrets.

# **6. Interpreting results correctly**

Worker output should be evaluated through four questions:

| Question | Why it matters |
| :---- | :---- |
| **What was directly observed?** | Distinguishes evidence from inference |
| **What could not be accessed?** | Prevents false confidence from missing pages or blocked requests |
| **How was the score calculated?** | Ensures rankings follow explicit criteria |
| **What decision belongs to the orchestrator or the human?** | Prevents an execution tool from becoming an uncontrolled decision-maker |

A strong result contains traceable URLs, response information, findings, limitations, and an audit trail. A worker should never hide uncertainty.

# **7. Extending the system safely**

A new worker should be added only when its objective is narrow, its inputs can be validated, its tools can be allowlisted, its outputs can be tested, and its failure mode is safe. New write capability requires a separate service identity, least-privilege credential, approval enforcement inside the execution path, rollback design, and a complete test suite.

The recommended expansion order is:

1. Operate read-only workers manually and collect real job history.
2. Add chat commands for job submission and review without exposing the service publicly.
3. Add approved read-only connectors for selected data sources.
4. Add scheduled jobs only for proven, low-volume tasks.
5. Consider narrowly scoped write actions only after approval enforcement is independently verified.

# **8. Architecture summary**

Human Operator  
  |  
Orchestrator control plane  
  |  
Specialist Agents  
  |  
Authenticated loopback Worker API  
  |  
Bounded runtime + registry + audit + approvals  
  |  
Read-only specialist workers  
  |  
Public evidence or operator-supplied offline records

This architecture keeps strategic intelligence, domain judgment, execution, memory, and production systems separate while allowing them to cooperate through explicit contracts.