Core Automation

CoWork OS now treats always-on automation as a strict core runtime, not a blended product story.

Core Boundary

The core runtime is only:

• Memory
• Heartbeat
• Subconscious

Everything else is a surrounding surface:

• Mission Control is the cockpit for observing and configuring the core
• Triggers are ingress and signal normalization only
• Devices are execution routing only
• Digital Twins are optional persona presets and are not part of core ownership

Ownership Model

Core automation is owned by AutomationProfile, not by persona templates and not by raw role editing.

An automation profile is attached to a generic operator agent role and stores:

• enabled state
• cadence
• stagger offset
• dispatch cooldown
• dispatch budget
• active hours
• heartbeat profile

Digital Twin roles do not own automation profiles and do not create heartbeat or subconscious state when activated.

Cognition Path

The intended flow is:

signal or evidence -> heartbeat -> subconscious -> decision -> downstream surface

Downstream surfaces can create visible work, but they do not become cognition owners themselves.

Core Targets

Direct subconscious ownership is intentionally narrow:

• global
• workspace
• agent_role
• code_workspace
• pull_request

Non-core concepts such as triggers, schedules, briefings, mailbox threads, and devices can still contribute evidence or execute outcomes, but they are not direct cognition targets.

Mission Control

Mission Control is the main control surface for the core runtime. It should be read as:

• automation profile state
• heartbeat runs
• subconscious runs
• core traces
• failure clusters
• eval cases
• experiments
• learnings

It is not the owner of runtime state; it is the operating cockpit around that state.

Core Harness

Core automation now includes a learning loop built around:

• core traces
• memory extraction and distillation
• failure mining
• recurring failure clustering
• living eval cases
• gated experiments
• promoted learnings

This gives the always-on runtime a narrow improvement loop centered on operator quality, rather than a broad feature sprawl.

Approval Model

Core-created automated tasks now inherit a real autonomy policy instead of only allowUserInput: false.

The default posture is:

• autonomous execution for routine operator work
• auto-approval for common automation-safe actions such as shell commands and trusted network/external-service operations
• hard guardrails, workspace capability denials, and explicit dangerous actions still remain enforced

See Heartbeat v3, Subconscious Reflective Loop, Mission Control, and Permission System.