ccpe-system/ccpe-protocol/ccpe-operating-modes.md

CCPE Operating Modes

1. Purpose

This document defines the operating modes of the CCPE System.

Operating mode answers the question:

How is this artifact meant to be used in real work?

Classification tells us what the artifact is. Operating mode tells us how it behaves in practice.

Operating mode must be determined from the user's real or planned usage scenario, not from the artifact's perceived importance.

For project-facing work, the usage scenario should normally come from the consuming project repository, not from CCPE's internal speculation. CCPE supplies assets after a real requirement exists.

The same artifact type can operate in different modes.

Example:

A Red-Team Agent may be:
- Expert Mode when used alone in chat.
- Workshop Mode when used as one member of a review committee.
- Hybrid Mode when its reports are collected automatically and synthesized by another agent.

2. Primary Operating Modes

CCPE System uses four primary operating modes:

Expert Mode
Workshop Mode
Automation Mode
Hybrid Mode

These modes are not maturity levels.

They are different usage patterns.

2.1 Runtime Maturity Modes

In addition to operating mode, substantial workflows should declare a runtime maturity mode:

Lite
Standard
Full

Default to Lite. Escalate only when evidence requires it.

Lite

Use when the task is one-off, low-risk, single-model or single-artifact, and does not require formal multi-agent evidence.

Typical outputs:

target output
brief input record
human confirmation
optional sample check

Standard

Use when the work will likely recur, has a downstream consumer, needs a context pack or structured artifacts, and may involve a small number of real participant invocations.

Typical outputs:

source or context pack
confirmed structure
decision record
targeted audit
minimal invocation record

Full

Use only when there are multiple roles, multiple sources, high risk, accountability needs, long cycles, external delivery, or downstream dependency on process authenticity.

Typical outputs:

full runtime
invocation records
authority map
state machine
coverage audit
distortion-risk log
recovery protocol
downstream handoff

3. Expert Mode

3.1 Definition

Expert Mode is used when a single AI artifact acts as a specialized thinking partner, reviewer, analyst, or advisor.

The user directly interacts with the artifact.

The user remains responsible for judgment, selection, and next steps.

3.2 Typical Artifact Types

Expert Mode commonly uses:

CCPE-Lite
CCPE-Agent
Model-backed Agent
Single Skill invoked inside an Agent

3.3 Typical Use Cases

Examples:

Zhangliao Red-Team Critic
Cognitive Imaging Specialist
Socratic Questioner
Strategic Architect
Article Reviewer
Concept Boundary Analyst

3.4 Characteristics

Expert Mode usually has:

Single primary role
Direct user interaction
No complex orchestration
No required automation
No persistent workflow state
High interpretive depth
High human judgment

For Web / GPT / Gemini / Claude style use, Expert Mode should normally preserve a strong CCPE-Lite prompt kernel. A Lite artifact in this mode is a complete deployment form, not a simplified Agent Spec.

If the user wants the same expert to be invoked inside Codex automatically, add or generate a Skill only for the callable method or invocation wrapper. Do not automatically convert the whole expert into a Runtime.

3.5 Human Role

The human:

• Provides input
• Interprets output
• Challenges the agent
• Decides next steps
• May correct the model or reasoning
• Controls iteration

3.6 When to Use

Use Expert Mode when:

• You need depth rather than automation
• The task is ambiguous
• The user wants critique, insight, questioning, or modeling
• The artifact is mostly language-based
• The artifact should remain portable

3.7 When Not to Use

Do not rely only on Expert Mode when:

• Multiple agents must coordinate
• Outputs need routing or synthesis
• Files or tools must be operated repeatedly
• State must persist
• Work must resume across sessions
• There are approval gates
• Runtime safety is required

4. Workshop Mode

4.1 Definition

Workshop Mode is used when multiple predefined agents collaborate under human direction.

The agents are not dynamically invented for each task.

They are pre-composed roles in a cognitive work system.

The human may manually pass content among agents or may use light automation to route outputs.

Workshop Mode can be manual. A committee does not require automation at the beginning.

4.2 Typical Artifact Types

Workshop Mode commonly uses:

CCPE-Runtime
CCPE-Agent
CCPE-Lite
CCPE-Skill
Model Card
Model Index

Stable committee members may remain as Lite prompts until their collaboration contracts become stable enough to justify Agent Specs.

4.3 Typical Use Cases

Examples:

Modeling Committee
Review Committee
Writing Committee
Research Council
Conceptual Architecture Workshop
Multi-agent critique workflow

4.4 Characteristics

Workshop Mode usually has:

Predefined roles
Predefined responsibilities
Semi-structured stages
Human-led progression
Explicit decision gates
Multiple perspectives
State or artifact handoff
Intermediate outputs
Final synthesis

When a lead or director role coordinates several mature experts, that lead may be modeled first as an Interactive Runtime Lite or Agent-Lite before a full Runtime is created.

4.5 Human Role

The human:

• Sets the agenda
• Provides source materials
• Decides which agent to invoke
• Answers key questions
• Selects useful critiques
• Resolves conflicts
• Approves stage transitions
• Owns final judgment

4.6 Agent Role

Agents:

• Perform specialized analysis
• Ask structured questions
• Produce reports
• Identify risks
• Generate alternatives
• Synthesize partial findings
• Archive decisions
• Prepare next-step materials

4.7 When to Use

Use Workshop Mode when:

• Work is deep and multi-perspectival
• Several cognitive roles are useful
• Human judgment is central
• The process has recurring stages
• Outputs benefit from structured handoff
• The same committee will be reused

4.8 When Not to Use

Do not use Workshop Mode when:

• A single expert prompt is enough
• The task is purely repetitive
• There is no need for multiple perspectives
• The cost of coordination exceeds the value
• The workflow can be safely automated

5. Automation Mode

5.1 Definition

Automation Mode is used when AI executes stable, repeatable, low-ambiguity work with clear success criteria.

The work may involve tools, files, code, APIs, or batch processing.

5.2 Typical Artifact Types

Automation Mode commonly uses:

CCPE-Skill
CCPE-Runtime
Tool Skill
Workflow Skill
Evaluation Skill

5.3 Typical Use Cases

Examples:

Format conversion
Voice-to-text preprocessing
Report collection
File organization
Batch model card generation draft
Index update draft
Template generation
Low-risk code modification
Data extraction

5.4 Characteristics

Automation Mode usually has:

Stable steps
Clear input/output
Low ambiguity
Explicit tool permissions
Validation criteria
Failure handling
Recovery or rollback
Reduced human involvement

5.5 Human Role

The human:

• Defines goal and constraints
• Approves risky operations
• Reviews final output
• Intervenes on failure
• Owns irreversible decisions

5.6 When to Use

Use Automation Mode when:

• The task is repetitive
• The process is well-defined
• Outputs are verifiable
• Risk is low or bounded
• Automation saves meaningful time
• Failure can be detected and corrected

5.7 When Not to Use

Do not use Automation Mode when:

• The task requires original conceptual judgment
• The cost of a wrong decision is high
• The output cannot be reliably validated
• The user has not approved tool or file operations
• The agent would need to invent major assumptions
• The work involves deep model authorship

6. Hybrid Mode

6.1 Definition

Hybrid Mode combines deep human-led cognition with selective automation.

It is often the best mode for complex knowledge work.

The core thinking remains interactive. Peripheral operations may be automated.

6.2 Typical Artifact Types

Hybrid Mode commonly uses:

CCPE-Runtime
CCPE-Agent
CCPE-Skill
Model Card
Model Index

6.3 Typical Use Cases

Examples:

Modeling Committee with report collection
Article review committee with synthesis agent
Knowledge extraction pipeline with human approval
Coding workflow with deep planning and later implementation
Long-form essay transformation into Model Cards
Agent upgrade workflow

6.4 Characteristics

Hybrid Mode usually has:

Human-led conceptual work
Agent-assisted analysis
Automated routing or collection
Automated deduplication
Automated formatting
Human approval before finalization
State tracking
Versioning
Review loops

6.5 Human Role

The human:

• Owns the intellectual direction
• Sets the judgment criteria
• Approves model extraction
• Confirms stage transitions
• Resolves conflicts
• Accepts or rejects synthesis
• Controls automation boundaries

6.6 When to Use

Use Hybrid Mode when:

• The core task is deep but has repetitive support work
• Multiple agents produce outputs
• Reports need to be collected or synthesized
• Model extraction needs human approval
• Coding requires substantial planning before execution
• Knowledge work needs archival and indexing

6.7 When Not to Use

Do not use Hybrid Mode when:

• A simple prompt is enough
• The task is fully automatable and low-risk
• There is no need for human decision points
• The overhead of workflow management is too high

7. Runtime Orientations

Runtime can support three orientations:

Interactive Runtime
Automation Runtime
Hybrid Runtime

These correspond to, but are not identical with, operating modes.

7.1 Interactive Runtime

Interactive Runtime is used for human-led multi-stage work.

Examples:

Modeling Committee
Deep writing workshop
Theoretical model refinement
Strategic review process

It emphasizes:

Human decision gates
Dialogic progression
State summaries
Stage transitions
Intermediate artifacts
Versioned conclusions

Interactive Runtime is often used with Workshop Mode.

7.2 Automation Runtime

Automation Runtime is used for tool-heavy or process-heavy tasks.

Examples:

Batch file processing
Index generation
Report collation
Format conversion
Code implementation after plan approval

It emphasizes:

Tool permissions
Validation
Error handling
Rollback
Logging
Repeatability

Automation Runtime is often used with Automation Mode.

7.3 Hybrid Runtime

Hybrid Runtime is used when both deep work and automation are present.

Examples:

Article-to-model extraction pipeline
Multi-agent review with synthesis
Coding workflow from planning to implementation
Agent upgrade pipeline

It emphasizes:

Human-led decisions
Agent-assisted analysis
Automated support steps
State and version management
Review before finalization

Hybrid Runtime is often used with Hybrid Mode.

8. Mode Selection Questions

When selecting an operating mode, ask:

Is this mainly a single expert interaction?
Are multiple predefined roles involved?
Is the task repetitive and verifiable?
Does the work require deep human judgment?
Are tools or file operations involved?
Does the process have stages?
Does output from one stage feed another?
Is there persistent state?
Is there a need for human approval gates?
Would automation reduce quality or increase risk?

9. Mode Selection Table

If single expert interaction:
→ Expert Mode

If predefined roles collaborate under human direction:
→ Workshop Mode

If stable steps can be executed with clear validation:
→ Automation Mode

If deep cognition combines with automated support:
→ Hybrid Mode

10. Artifact Type by Operating Mode

10.1 Expert Mode

Usually:

CCPE-Lite
CCPE-Agent
Model-backed Agent

May include:

Single Skill
Model Card reference

Usually does not need:

Runtime
Complex state
Multi-agent handoff

10.2 Workshop Mode

Usually:

CCPE-Runtime
CCPE-Agent
CCPE-Skill
Model Card

May include:

CCPE-Lite roles
Model Index
Knowledge archival Skill
Synthesis Agent

10.3 Automation Mode

Usually:

CCPE-Skill
CCPE-Runtime
Tool Skill
Workflow Skill
Evaluation Skill

Requires:

Authority rules
Validation
Failure handling
Recovery

10.4 Hybrid Mode

Usually:

CCPE-Runtime
CCPE-Agent
CCPE-Skill
Model Card
Model Index

Requires:

Human decision gates
Automation boundaries
State tracking
Versioning
Review loops

11. Human Decision Gates

A human decision gate is required when:

The work changes canonical model definitions.
The work upgrades or splits a major agent.
The work creates or modifies Runtime automation.
The work writes or deletes many files.
The work uses external tools or APIs.
The work makes irreversible decisions.
The work involves high uncertainty.
The work affects the user's intellectual framework.

Decision gates should be written explicitly.

Example:

Human Decision Gate:
Before promoting a candidate Model Card into the canonical Model Index, ask the user to confirm model name, scope, and status.

12. Automation Boundary

For any Automation or Hybrid Mode artifact, define:

Allowed automated actions
Actions requiring confirmation
Forbidden actions
Validation method
Failure handling
Rollback or recovery

Example:

Allowed:
Generate draft Model Cards from source articles.

Requires confirmation:
Promote draft Model Cards into canonical model-cards/.

Forbidden:
Delete or overwrite original articles.

Validation:
Each Model Card must include source material, scope, mechanism, failure modes, and falsification boundary.

13. Workshop Role Stability

For Workshop Mode, roles should usually be predefined.

This is especially important for cognitive work.

Pre-composed roles are preferred when:

• The user already has a stable committee structure
• The roles represent distinct cognitive functions
• The workflow is repeated over time
• The user wants consistent perspectives
• The user does not want the system to invent new agents dynamically

Dynamic role creation may be useful, but should not be the default.

14. Pre-Composed vs Dynamic Agentic Systems

14.1 Pre-Composed Agentic System

A pre-composed system has:

Stable agents
Stable responsibilities
Stable workflow stages
Known human decision points
Predictable handoff

Examples:

Modeling Committee
Review Committee
Writing Committee

This mode is preferred for deep cognitive work.

14.2 Dynamic Agentic System

A dynamic system has:

Task-dependent planning
Temporary role creation
Dynamic routing
Automated decomposition
Variable workflow

This mode may be useful for operational tasks, but should be used carefully for deep intellectual work.

15. Mode Examples

15.1 Zhangliao Red-Team Critic

Likely mode:

Expert Mode

If used in a review committee:

Workshop Mode or Hybrid Mode

15.2 Cognitive Imaging Specialist

Likely mode:

Expert Mode

If used as a committee member:

Workshop Mode

If invoked along with several reviewers and synthesized automatically:

Hybrid Mode

15.3 Modeling Committee

Likely mode:

Workshop Mode

Runtime orientation:

Interactive Runtime

If report collection, deduplication, and archival are automated:

Hybrid Runtime

15.4 Model Extraction from Long Essays

Likely mode:

Hybrid Mode

Reason:

The extraction process can be assisted by automation,
but canonical model approval requires human judgment.

15.5 Coding Project

Likely mode depends on stage.

Planning stage:

Expert Mode or Workshop Mode

Implementation stage after plan approval:

Automation Mode or Hybrid Mode

16. Operating Mode Output Format

When reporting operating mode, use:

# Operating Mode Assessment

## 1. Recommended Mode
Expert / Workshop / Automation / Hybrid

## 2. Runtime Orientation
None / Interactive / Automation / Hybrid

## 3. Reasoning Summary
...

## 4. Human Role
...

## 5. Agent Role
...

## 6. Automation Boundary
...

## 7. Human Decision Gates
...

## 8. Risks
...

## 9. Recommended Artifact Types
...

17. Final Rule

Operating mode should serve the work, not the other way around.

Do not automate what requires judgment.

Do not manually repeat what can be safely standardized.

Do not create committees when one expert agent is enough.

Do not reduce a cognitive workshop to a pipeline.

Do not simulate canonical participant output.

When a Runtime depends on a CCPE-Lite prompt, CCPE-Agent, CCPE-Skill, Runtime node, native agent, external model participant, or human-run participant, the Runtime must define a real invocation boundary before accepting that participant's output.

Required invocation evidence:

Agent Invocation Packet
prompt-to-send.md with returned external output
Skill execution record
Native agent run record
Manual handoff return record

If the participant cannot be truly invoked, the Runtime must stop and mark:

blocked_waiting_for_participant_output

Any explicitly requested simulation must be labeled:

simulation-only
excluded-from-synthesis
not-a-formal-report

The correct operating mode is the one that preserves depth while reducing unnecessary friction.