Standalone article · part of a sequenced guide
What you'll unlock: Plugins accelerate, Skills encode your SOPs, schedules industrialise — delegate first, steer second, crystallise third; audit with run history + manifests until platform audit catches up.
Product Surface & Power User Guide
Native Cowork capabilities, enterprise observability, steering habits, and patterns vs product controls
Chapter context
The first six chapters are how we want every customer to operate. Chapter 7 is what the product actually is — the architect sign-off chapter.
Is this chapter for you?
Are you onboarding non-operators to Cowork?
Start §2.1 goal+cadence delegation — not the Skill editor.
Does your industry need cited deliverables?
§1.7 citation rules in every Result template + QA gate.
Will compliance audit Cowork usage?
§2.7 audit bundle monthly — do not assume Compliance API alone.
Are you hunting UI controls from playbook patterns?
Read §2.3 native vs pattern legend before rollout.
Chapters 1–6 teach how to run Cowork as production ops. Chapter 7 maps the actual product surface and the power habits that close the gap between our playbook patterns and the desktop app.Read this chapter before telling your team to find a cron field that does not exist — and before your compliance team assumes Compliance API already covers Cowork.
Chapter insight
Plugins accelerate, Skills encode your SOPs, schedules industrialise — delegate first, steer second, crystallise third; audit with run history + manifests until platform audit catches up.
Reference diagrams
Cowork product layers
Plugin → Skill → Schedule — three layers, one library.
Native vs playbook pattern
Patterns are ops discipline implemented on top of native controls.
Implementation paths
Faithful to the app; rigorous in production.
Concept 1
Native Product Capabilities
Plugins, subagents, Projects, Dispatch, Chrome, and the security model — what Cowork ships beyond filesystem automation
1.1
Plugins vs Skills vs workflows
Three layers of reuse — when to install a plugin, when to write a Skill, when to schedule a workflow
Key takeaway
Plugins = curated role packs from Anthropic/marketplace; Skills = your org's TAR contracts; workflows = triggers + composition — use all three, don't duplicate.
Why this matters
Teams write custom Skills for everything plugins already solve, or install plugins without governance — both waste time and create audit gaps.
Plugins accelerate onboarding. Skills encode your SOPs. Workflows / scheduled tasks industrialise what plugins and Skills prepare.
Decision tree: start with a plugin if Anthropic or your enterprise marketplace has a role match → customise via Skills for paths/schemas → schedule when five-run gate passes. Enterprise: private plugin marketplace with CoE approval (Ch 5 §3.5, Ch 7 §2.6).
Workflow — do this next
- 01Browse official + enterprise plugin catalog before writing Skill v1.
- 02Fork plugin procedure into org Skill only where paths differ.
- 03Document: plugin version + dependent Skills in SKILL_INDEX.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Plugin · Skill · Workflow matrix
| Layer | Owns | Example | |-------|------|---------| | Plugin | Role template | Marketing campaign brief pack | | Skill | Org SOP | ACME_CRM_EXPORT_NORMALISE_v2 | | Workflow | When it runs | Mon 6:30 + connectors |
1.2
Subagents and parallel work
How Cowork fans out subagents for long multi-step tasks — scope, cost, and control
Key takeaway
Subagents parallelise branches (research, per-file extract) — parent task owns merge; cap branches and token budget per run.
Why this matters
Unbounded subagent fan-out is the fastest path to invoice shock and inconsistent merges.
Cowork uses subagents for long-running knowledge work. You see parent progress in run history; subagent work should appear in logs or step summaries.
Ops rules: max N parallel branches (Ch 3 §1.6); explicit JOIN Skill; never parallel-write same output folder. For scheduled unattended jobs, prefer sequential unless branches are read-only.
Workflow — do this next
- 01Design parallel only when branches are independent reads.
- 02Add JOIN + VALIDATE before emit.
- 03Log branch count in manifest.
- 04Load-test token cost with max parallelism once.
Real example
COMPETITOR_SCAN with subagents
Parent spawns SCAN_A, SCAN_B, SCAN_C subagents → each writes branch json → JOIN_DIGEST merges → single SYNTH Skill. Scheduled run caps at 3 branches.
1.3
Cowork Projects
Session persistence for multi-day work — distinct from Claude.ai Projects
Key takeaway
Cowork Projects keep context across sessions for one initiative — design and iterate in a Project, then crystallise stable procedures into Skills and schedules.
Why this matters
Without Projects, multi-day board prep resets; without Skills, Project knowledge doesn't become reusable automation.
Cowork Cowork Projects differ from Claude.ai Projects. Use Cowork Projects for week-long deliverables; promote repeatable steps to Skills when stable.
Handoff path: Project exploration → TAR Skill draft → sandbox test → workflow schedule. Archive Project when initiative ships; Skill remains in library.
Workflow — do this next
- 01Open Project per major initiative (board week, RFP, launch).
- 02End each session with plan.md update in Project folder.
- 03When step repeats 3× identically → extract Skill.
1.4
Dispatch — mobile to desktop
Assign Cowork tasks from your phone; execution happens on your desktop
Key takeaway
Dispatch is kickoff + notify — desktop must be awake, paired, and on a paid plan; not a substitute for schedules or server-side automation.
Why this matters
Users expect phone to run overnight jobs; Dispatch requires an awake ops machine — document this or miss SLAs.
Dispatch needs: latest desktop + mobile apps, pairing, computer awake, active internet. Rolling out gradually on Pro/Max.
Use Dispatch for ad-hoc 'start this while I'm commuting.' Use scheduled tasks for Monday 6am brief. Dedicated always-on ops machine for reliable schedules (Ch 5 §3.4).
Workflow — do this next
- 01Pair mobile + desktop once; verify in settings.
- 02Document: Dispatch = human trigger, not cron.
- 03For reliability, prefer schedule over Dispatch for recurring work.
- 04Ops machine: prevent sleep during schedule windows.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Dispatch vs scheduled task
Dispatch: ad-hoc, you assign, desktop executes, phone notified Schedule: recurring, unattended, desktop must be awake Server automation: not Cowork — use API/backend if 24/7 required
1.5
Claude in Chrome and connector fallback
When Cowork uses the browser because no direct connector exists
Key takeaway
Chrome is the fallback path for web apps without MCP — allowlist domains, never for unattended PII or auth flows on scheduled runs.
Why this matters
Chrome access increases injection and exfiltration surface — default deny in production schedules.
Cowork picks the fastest path: connector for Slack/Drive, Claude in Chrome when no direct integration exists. Product also may use screen/app control as last resort — restrict for scheduled unattended workflows.
Policy: interactive sessions may use Chrome with domain allowlist; scheduled jobs = connectors + files only unless security approves Chrome step.
Workflow — do this next
- 01Map each workflow step: connector | Chrome | file-only.
- 02Deny Chrome on scheduled T0–T2 external-facing outputs.
- 03Log Chrome fetches in manifest with URL list.
1.6
VM sandbox and filesystem security
How Cowork isolates execution — not the same as a ~/Sandbox folder
Key takeaway
Cowork runs in a sandboxed VM with mounted allowlisted folders — folder sandbox in ops docs is practice; VM boundary is the actual security model.
Why this matters
Operators think 'sandbox folder' equals security; real boundary is VM + allowlist + no password handoff.
On macOS Cowork uses a sandboxed virtual machine. Windows has analogous isolation. This is why allowlisting matters — not because Cowork browses your entire disk by default.
Product claim: no passwords handed off. Your ~/CoworkSandbox convention (Ch 1 §1.8) is ops best practice on top of VM isolation — test paths before production mounts.
Workflow — do this next
- 01Distinguish VM sandbox (product) vs path sandbox (ops) in SETUP.md.
- 02Allowlist minimum paths on first run.
- 03Never mount entire home directory.
1.7
Citations and source-grounded outputs
Cowork's differentiator — deliverables that cite actual files and messages
Key takeaway
Every production Result template includes a Sources section — file paths, message IDs, URLs, retrieval dates — validated in QA.
Why this matters
Uncited synthesis erodes executive trust; citations are a product promise and a compliance requirement.
Cowork returns citations to source files and messages. Encode in TAR Result: CITATION_RULES. QA Skill fails if HIGH claims lack citations.
Workflow — do this next
- 01Add ## Sources to every external-facing template.
- 02QA check: count(citations) >= count(claims) for flagged sections.
- 03Store source manifest alongside output.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
CITATION_RULES block
## Sources - [claim] → file://path or message_id or url (retrieved YYYY-MM-DD) QA: no uncited numbers in Executive section
1.8
Long-running work
Progress, interruption, resume, and timeouts for multi-step agentic tasks
Key takeaway
Long runs need max_runtime, checkpoint manifests, and interrupt policy — partial outputs must be labeled PARTIAL, not SUCCESS.
Why this matters
Board-week jobs exceed default patience; without checkpoint discipline, reruns duplicate work or lose progress.
Cowork supports long-running multi-step work. Set max_runtime; write checkpoint manifest every N steps; on interrupt, resume from last checkpoint not step 1.
If user steers mid-run (Ch 7 §2.2), Cowork should narrow scope — not restart entire pipeline silently.
Workflow — do this next
- 01Set max_runtime on heavy workflows.
- 02Checkpoint to staging/{run_id}/checkpoint.json each phase.
- 03PARTIAL status + review queue on timeout.
Concept 2
Enterprise, Steering & Power Habits
Delegation-first UX, steering, observability, and the shortcuts experienced Cowork operators use daily
2.1
Goal + cadence delegation
The first-run UX — describe outcome and cadence; Cowork proposes the plan
Key takeaway
Start with goal + outcome + cadence in plain language — approve Cowork's proposed steps before locking Skills and schedules.
Why this matters
Power users who jump straight to Skill editor overwhelm beginners; delegation-first is how the product is designed to be learned.
Cowork's default loop: you state goal, desired outcome, and cadence; Claude lays out steps; you steer and approve; stable version becomes Skill + schedule.
First 10 minutes path: one manual delegation → review plan → run → save as Skill v1 → test matrix → schedule. Do not skip plan approval on first production workflow.
Workflow — do this next
- 01Write one-sentence goal + cadence before opening builder.
- 02Review proposed steps — edit before run.
- 03After 3 identical runs → extract TAR Skill.
- 04Schedule only after Ch 5 readiness gate.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Delegation starter template
Goal: [one sentence] Outcome: [file path / connector / format] Cadence: [manual | daily | weekly] Non-goals: [what not to do] Approve plan before first run.
2.2
Steering mid-run
Interrupt, narrow scope, skip a step, approve next step only — power habits
Key takeaway
Steering beats restart — 'skip web scan,' 'only Finance folder,' 'stop before send' — saves tokens and time on long tasks.
Why this matters
Operators who only cancel-and-retry lose partial work and duplicate connector calls.
Use steering techniques: pause before external write; request citation on a section; exclude a data source; change output template. Document steering phrases in team wiki.
For scheduled unattended runs, steering is pre-encoded in TAR Action failure branches — not live chat.
Workflow — do this next
- 01Practice steering on manual runs before scheduling.
- 02Encode frequent steers as Action ON FAIL branches.
- 03Never steer around T3 approval gates.
Real example
Steering a runaway research task
User: 'Stop fetching — only use files already in ~/Research/inbox.' Cowork continues synthesis from local sources; manifest notes web_skipped: true.
2.3
Patterns vs native product controls
What the playbook teaches as ops architecture vs what the Cowork UI exposes today
Key takeaway
Cron overlap, flag-file conditions, manifest.json handoffs, VALIDATE_* Skills are patterns — native UI offers recurring tasks, connectors, Skills, run history.
Why this matters
Hunting for cron fields that don't exist wastes rollout time; patterns are how mature teams implement discipline on top of the product.
Native today (verify in your build): desktop Cowork mode, folder allowlist, Skills, plugins, scheduled tasks, connectors, run history, notifications.
Playbook patterns (implement via Skills + folders): event debounce, condition flags, pipeline DAG manifests, dry-run via sandbox paths, QA validation Skills. Label internal docs PATTERN vs NATIVE
Workflow — do this next
- 01Tag each workflow spec: native vs pattern.
- 02Map pattern to implementation (Skill, folder, schedule).
- 03Reconcile quarterly with release notes.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Native vs pattern legend
NATIVE: schedule picker, Skills, plugins, connectors, history PATTERN: cron overlap, export_ready.flag, manifest.json, VALIDATE_*, HITL tiers
2.4
Enterprise RBAC and team governance
Role-based access for who can create, connect, schedule, and approve
Key takeaway
Enterprise RBAC: admins control connectors, plugins, spend; creators draft; schedulers bind triggers — aligns with Ch 5 §2.6 roles.
Why this matters
Cowork at scale without RBAC mirrors 'everyone had root on the file server' — one incident ends the program.
Enterprise controls: connector enablement, plugin install policy, folder policy templates, model restrictions, role-based access. Pair with internal Creator / Owner / Scheduler / Admin roles.
Workflow — do this next
- 01Map IdP groups to Cowork roles with IT.
- 02Disable consumer OAuth connectors until allowlist approved.
- 03Quarterly access recertification.
2.5
Analytics API, OpenTelemetry, and spend limits
Enterprise observability and cost caps beyond run history
Key takeaway
Supplement run history with Analytics API / OpenTelemetry where enabled; set org spend limits — TOKEN_LEDGER (Ch 5) is internal discipline on top.
Why this matters
Finance needs org-level meters; ops needs per-workflow — use both layers.
Enterprise may expose usage analytics, Analytics API, and OpenTelemetry. Configure spend limits and alerts at org level; tag workflows with cost_center for chargeback.
Workflow — do this next
- 01Enable admin analytics; assign workflow tags.
- 02Wire OTel to SIEM if security requires.
- 03Set org spend cap + 80% warning.
- 04Reconcile OTel with TOKEN_LEDGER monthly.
2.6
Plugin marketplaces and private registries
Curated plugin distribution for enterprise — install only what CoE approves
Key takeaway
Private marketplace = approved plugins only; version pin; changelog review before org-wide push.
Why this matters
Public plugin install without review is shadow IT for agentic automation.
Enterprise private plugin marketplace works like internal app store. CoE reviews: data access, connector scopes, update policy. Document installed plugin versions in PLUGIN_REGISTRY.md.
Workflow — do this next
- 01Stand up PLUGIN_REGISTRY with owner + version.
- 02New plugin: security review → pilot → catalog.
- 03Deprecate plugins with breaking updates — notify Skill owners.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
PLUGIN_REGISTRY.md
| Plugin | Version | Owner | Data class | Approved | |--------|---------|-------|------------|----------|
2.7
Audit reality — run history vs Compliance API
What you can prove today and what enterprise audit is still catching up on
Key takeaway
Today: run history + your manifests + connector vendor logs = audit trail. Cowork activity may not yet appear in org Compliance API — plan accordingly.
Why this matters
Compliance teams assume Compliance API covers everything; gap creates false confidence during audits.
Use Cowork run history plus your manifest.json and external system audit logs (Google, Slack admin).
Important: as of enterprise documentation, Cowork activity is not yet captured in all org audit logs or Compliance API. Export monthly AUDIT_BUNDLE (Ch 5 §2.7) until platform audit matures. Do not claim Compliance API coverage without verification.
Workflow — do this next
- 01Document audit sources in COWORK_GOV.md.
- 02Monthly export run history + manifests.
- 03Quarterly verify Compliance API changelog with legal.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Audit sources (today)
✓ Cowork run history ✓ Your manifest + approval flags ✓ Connector vendor admin logs △ Org Compliance API — verify coverage ✓ TOKEN_LEDGER / Analytics API
2.8
Platform requirements and cloud desktop
Desktop-only, paid plans, awake machine, Windows/macOS, Foundry deployments
Key takeaway
Cowork requires desktop app + paid plan + internet + awake machine for schedules/Dispatch; Foundry/cloud desktop for regulated enterprise.
Why this matters
Rollouts fail when users expect web Cowork, free tier, or laptop-sleep schedules.
Requirements: Claude Desktop, paid Claude plan, active internet, allowlisted folders, connectors as needed.
For schedules and Dispatch: machine awake. Enterprise may deploy desktop via AWS / Google Cloud / Microsoft Foundry for data residency. Microsoft 365 connector for Outlook/Teams/OneDrive — parallel to Google stack (Ch 4).
Workflow — do this next
- 01Publish PLATFORM_REQ.md: OS, plan, sleep policy, network.
- 02Regulated orgs: evaluate Foundry desktop path with IT.
- 03Document M365 vs Google connector map per workflow.
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Platform requirements checklist
[ ] macOS or Windows desktop app (latest) [ ] Paid Claude plan (team/enterprise) [ ] Internet always during runs [ ] Ops machine: no sleep 5am–8am (or your window) [ ] Dispatch: mobile paired if used [ ] Foundry/VPC desktop if required by policy
Ready-to-use artifacts
Complete templates — paste directly into your AI tool or automation workflow.
Native vs pattern legend
Avoid confusing ops conventions with menu items.
NATIVE: schedule, Skills, plugins, connectors, history PATTERN: cron overlap, flags, manifest.json, VALIDATE_*
Platform requirements checklist
Desktop, plan, awake machine, Foundry if needed.
Desktop · paid plan · internet · sleep policy · pairing for Dispatch
Plugin · Skill · Workflow matrix
| Layer | Owns | Example | |-------|------|---------| | Plugin | Role template | Marketing campaign brief pack | | Skill | Org SOP | ACME_CRM_EXPORT_NORMALISE_v2 | | Workflow | When it runs | Mon 6:30 + connectors |
Dispatch vs scheduled task
Dispatch: ad-hoc, you assign, desktop executes, phone notified Schedule: recurring, unattended, desktop must be awake Server automation: not Cowork — use API/backend if 24/7 required
CITATION_RULES block
## Sources - [claim] → file://path or message_id or url (retrieved YYYY-MM-DD) QA: no uncited numbers in Executive section
Delegation starter template
Goal: [one sentence] Outcome: [file path / connector / format] Cadence: [manual | daily | weekly] Non-goals: [what not to do] Approve plan before first run.
Native vs pattern legend
NATIVE: schedule picker, Skills, plugins, connectors, history PATTERN: cron overlap, export_ready.flag, manifest.json, VALIDATE_*, HITL tiers
PLUGIN_REGISTRY.md
| Plugin | Version | Owner | Data class | Approved | |--------|---------|-------|------------|----------|
Audit sources (today)
✓ Cowork run history ✓ Your manifest + approval flags ✓ Connector vendor admin logs △ Org Compliance API — verify coverage ✓ TOKEN_LEDGER / Analytics API
Platform requirements checklist
[ ] macOS or Windows desktop app (latest) [ ] Paid Claude plan (team/enterprise) [ ] Internet always during runs [ ] Ops machine: no sleep 5am–8am (or your window) [ ] Dispatch: mobile paired if used [ ] Foundry/VPC desktop if required by policy
Enterprise rollout — product surface closes the gap
A financial services pilot passed ops review (Ch 5) but failed security review because teams described cron UI, assumed Compliance API coverage, and scheduled Chrome steps unattended.
Before
No plugin registry; Dispatch on sleeping laptops; uncited briefs to executives; 'sandbox' meant only a folder name.
After
Chapter 7 rollout: PLUGIN_REGISTRY, PLATFORM_REQ.md, native vs pattern tags, citation QA, monthly AUDIT_BUNDLE, Foundry desktop for traders, M365 connector map.
- Security review passed with VM + Chrome policy documented
- Compliance accepted AUDIT_BUNDLE until API coverage ships
- Onboarding time → 2 days with goal+cadence path vs 2 weeks Skill-first
- Plugin reuse → 40% of workflows started from marketplace packs
What goes wrong
Treating playbook patterns as missing product features.
§2.3 native vs pattern; implement patterns via Skills + folders.
Unattended Chrome or screen control on PII.
§1.5 deny Chrome on schedules; connectors only.
Compliance API assumed — audit gap in due diligence.
§2.7 run history + manifest export; verify API changelog quarterly.
Schedules on laptops that sleep.
§2.8 platform requirements + dedicated ops machine.
Vetted by Krishna KumarCurator, FactorBeam
Discussion
Discussion coming soon
Shared comments for this playbook are not live yet. When they are, you'll be able to ask questions, share what worked, and see replies from other readers.