943 lines
18 KiB
Markdown
943 lines
18 KiB
Markdown
# 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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
CCPE-Agent
|
|
Model-backed Agent
|
|
Single Skill invoked inside an Agent
|
|
```
|
|
|
|
### 3.3 Typical Use Cases
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Zhangliao Red-Team Critic
|
|
Cognitive Imaging Specialist
|
|
Socratic Questioner
|
|
Strategic Architect
|
|
Article Reviewer
|
|
Concept Boundary Analyst
|
|
```
|
|
|
|
### 3.4 Characteristics
|
|
|
|
Expert Mode usually has:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Modeling Committee
|
|
Review Committee
|
|
Writing Committee
|
|
Research Council
|
|
Conceptual Architecture Workshop
|
|
Multi-agent critique workflow
|
|
```
|
|
|
|
### 4.4 Characteristics
|
|
|
|
Workshop Mode usually has:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
CCPE-Skill
|
|
CCPE-Runtime
|
|
Tool Skill
|
|
Workflow Skill
|
|
Evaluation Skill
|
|
```
|
|
|
|
### 5.3 Typical Use Cases
|
|
|
|
Examples:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
CCPE-Runtime
|
|
CCPE-Agent
|
|
CCPE-Skill
|
|
Model Card
|
|
Model Index
|
|
```
|
|
|
|
### 6.3 Typical Use Cases
|
|
|
|
Examples:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Modeling Committee
|
|
Deep writing workshop
|
|
Theoretical model refinement
|
|
Strategic review process
|
|
```
|
|
|
|
It emphasizes:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Batch file processing
|
|
Index generation
|
|
Report collation
|
|
Format conversion
|
|
Code implementation after plan approval
|
|
```
|
|
|
|
It emphasizes:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Article-to-model extraction pipeline
|
|
Multi-agent review with synthesis
|
|
Coding workflow from planning to implementation
|
|
Agent upgrade pipeline
|
|
```
|
|
|
|
It emphasizes:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
CCPE-Agent
|
|
Model-backed Agent
|
|
```
|
|
|
|
May include:
|
|
|
|
```text
|
|
Single Skill
|
|
Model Card reference
|
|
```
|
|
|
|
Usually does not need:
|
|
|
|
```text
|
|
Runtime
|
|
Complex state
|
|
Multi-agent handoff
|
|
```
|
|
|
|
### 10.2 Workshop Mode
|
|
|
|
Usually:
|
|
|
|
```text
|
|
CCPE-Runtime
|
|
CCPE-Agent
|
|
CCPE-Skill
|
|
Model Card
|
|
```
|
|
|
|
May include:
|
|
|
|
```text
|
|
CCPE-Lite roles
|
|
Model Index
|
|
Knowledge archival Skill
|
|
Synthesis Agent
|
|
```
|
|
|
|
### 10.3 Automation Mode
|
|
|
|
Usually:
|
|
|
|
```text
|
|
CCPE-Skill
|
|
CCPE-Runtime
|
|
Tool Skill
|
|
Workflow Skill
|
|
Evaluation Skill
|
|
```
|
|
|
|
Requires:
|
|
|
|
```text
|
|
Authority rules
|
|
Validation
|
|
Failure handling
|
|
Recovery
|
|
```
|
|
|
|
### 10.4 Hybrid Mode
|
|
|
|
Usually:
|
|
|
|
```text
|
|
CCPE-Runtime
|
|
CCPE-Agent
|
|
CCPE-Skill
|
|
Model Card
|
|
Model Index
|
|
```
|
|
|
|
Requires:
|
|
|
|
```text
|
|
Human decision gates
|
|
Automation boundaries
|
|
State tracking
|
|
Versioning
|
|
Review loops
|
|
```
|
|
|
|
## 11. Human Decision Gates
|
|
|
|
A human decision gate is required when:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Allowed automated actions
|
|
Actions requiring confirmation
|
|
Forbidden actions
|
|
Validation method
|
|
Failure handling
|
|
Rollback or recovery
|
|
```
|
|
|
|
Example:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Stable agents
|
|
Stable responsibilities
|
|
Stable workflow stages
|
|
Known human decision points
|
|
Predictable handoff
|
|
```
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Modeling Committee
|
|
Review Committee
|
|
Writing Committee
|
|
```
|
|
|
|
This mode is preferred for deep cognitive work.
|
|
|
|
### 14.2 Dynamic Agentic System
|
|
|
|
A dynamic system has:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Expert Mode
|
|
```
|
|
|
|
If used in a review committee:
|
|
|
|
```text
|
|
Workshop Mode or Hybrid Mode
|
|
```
|
|
|
|
### 15.2 Cognitive Imaging Specialist
|
|
|
|
Likely mode:
|
|
|
|
```text
|
|
Expert Mode
|
|
```
|
|
|
|
If used as a committee member:
|
|
|
|
```text
|
|
Workshop Mode
|
|
```
|
|
|
|
If invoked along with several reviewers and synthesized automatically:
|
|
|
|
```text
|
|
Hybrid Mode
|
|
```
|
|
|
|
### 15.3 Modeling Committee
|
|
|
|
Likely mode:
|
|
|
|
```text
|
|
Workshop Mode
|
|
```
|
|
|
|
Runtime orientation:
|
|
|
|
```text
|
|
Interactive Runtime
|
|
```
|
|
|
|
If report collection, deduplication, and archival are automated:
|
|
|
|
```text
|
|
Hybrid Runtime
|
|
```
|
|
|
|
### 15.4 Model Extraction from Long Essays
|
|
|
|
Likely mode:
|
|
|
|
```text
|
|
Hybrid Mode
|
|
```
|
|
|
|
Reason:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Expert Mode or Workshop Mode
|
|
```
|
|
|
|
Implementation stage after plan approval:
|
|
|
|
```text
|
|
Automation Mode or Hybrid Mode
|
|
```
|
|
|
|
## 16. Operating Mode Output Format
|
|
|
|
When reporting operating mode, use:
|
|
|
|
```text
|
|
# 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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
blocked_waiting_for_participant_output
|
|
```
|
|
|
|
Any explicitly requested simulation must be labeled:
|
|
|
|
```text
|
|
simulation-only
|
|
excluded-from-synthesis
|
|
not-a-formal-report
|
|
```
|
|
|
|
The correct operating mode is the one that preserves depth while reducing unnecessary friction.
|
|
|