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 Workflow Intelligence:

• Memory is the source of truth.
• Heartbeat owns scheduling and signal readiness.
• Reflection evaluates evidence internally.
• Dreaming curates memory evidence into reviewable candidates.
• Suggestions are the default user-facing output.

Everything else is a surrounding surface:

• Routines are the top-level saved automation product, but not part of the always-on cognitive core
• 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

Routines now sit above several lower-level engines:

• schedule triggers compile into Scheduled Tasks
• API triggers compile into Webhooks
• event triggers compile into Event Triggers

That makes Routines the main user-facing automation abstraction without redefining the actual core runtime boundary.

Task view can also create a task-sourced routine with ... > Add automation.... That flow is not a new core cognition loop; it is a task-prefilled routine authoring shortcut that can continue the existing thread by default or create new tasks on each run. Schedule triggers still compile to Scheduled Tasks, API triggers compile to Webhooks, and event triggers compile to Event Triggers, with the source task title, task ID, and cowork://tasks/<taskId> reference preserved. See Task Automations.

Settings > Automations > Routines is the primary observability surface for task-sourced automations. When a routine compiles to a cron job, Settings > Automations > Scheduled Tasks also shows aggregate run health, the latest result, delivery status, recent run history, and links to generated sessions or continued threads so lower-level scheduled work can be audited without digging through the general task list.

<p align="center"> <img src="../resources/branding/images/cowork-os-6.webp" alt="Automations control center" width="700"> <br><em>The Automations surface separates scheduled work, triggered work, and core automation controls.</em> </p>

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 workflow-intelligence state when activated.

Cognition Path

The intended flow is:

signal or evidence -> Heartbeat -> Reflection -> Dreaming when memory drift exists -> Suggestion or memory candidate -> user response -> Memory

Downstream surfaces can create visible work, but they do not become cognition owners themselves. User response to suggestions is part of the loop: acting reinforces a workflow pattern, editing captures a correction, and snooze/dismiss/ignore lowers similar future suggestions.

Dreaming is the memory-maintenance branch of this path. It can run after task completion or from memory-specific Heartbeat signals, persists dreaming_runs and dreaming_candidates, and leaves final mutation to the existing memory services.

Core Targets

Direct reflection target 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.

Task-sourced automations follow the same rule: they can execute recurring work, continue a task thread, or produce new task evidence, but the original task, deeplink, schedule, webhook, event trigger, or worktree is not a Workflow Intelligence ownership target.

Mission Control

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

• automation profile state
• heartbeat runs
• workflow-intelligence/reflection 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. Mission Control also exposes a global runtime queue summary so operators can see executor pressure, but that queue is separate from Heartbeat state and from workspace-scoped Mission Board work.

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. Workflow Intelligence is review-first by default: it creates suggestions unless explicit policy, low risk, clear scope, and trusted or repeatedly accepted patterns justify auto-create.

The default posture is:

• reviewable suggestions for new or uncertain patterns
• autonomous execution only for trusted routine operator work
• auto-approval only 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 Workflow Intelligence, Heartbeat v3, Mission Control, and Permission System.