Standalone article · part of a sequenced guide

What you'll unlock: MCP extends the COO model from disk to ecosystem — pull, transform, push with staging manifests and least-privilege connectors; read-only first, writes only with HITL.

View full guide New here? Start Chapter 1

Tool guideChapter 4 of 7

MCP in Cowork — Connected Automation

~100 min read

How MCP connectors extend Cowork beyond your local file system into your entire tool ecosystem

Chapter context

Your Cowork Skills already process local exports — but someone still copies results into Gmail, Drive, and Slack by hand. Connected automation closes the last mile without abandoning the TAR and pipeline discipline from Chapters 2–3.IT and security care about connector scope and audit — this chapter gives you the vocabulary and artifacts they expect before production rollout.

Is this chapter for you?

Does the workflow need data that never lands on disk as exports?

MCP read connector — start allowlisted, staging manifest (§1.5).

Will the workflow write to external systems unattended?

HITL tier + security review (§1.6); read-only v1 first (§2.8).

Is the external API rate-limited or outage-prone?

Reliability policy + degraded mode (§1.4); throttle spec (§1.7).

Will compliance ask what Cowork accessed?

Audit manifest + monthly governance review (§1.8) before schedule.

Chapters 1–3 automated your filesystem and schedules. Chapter 4 connects Cowork to the systems where work actually lives — email, calendar, chat, CRM, repos — via MCP connectors.You will learn connector setup, reliability, security, and rate limits — then walk through eight connected workflows you can adapt to your stack.

Chapter insight

MCP extends the COO model from disk to ecosystem — pull, transform, push with staging manifests and least-privilege connectors; read-only first, writes only with HITL.

Reference diagrams

Connector data flow

Always stage between fetch and emit — never blind API passthrough.

FETCHConnector readAPI in

Stagingraw/ + manifestAudit

TRANSFORMSkills + ClaudeTAR

EMITConnector writeAPI out

NotifySlack / emailHuman

Connected workflow stack

Same pipeline discipline as Ch 3 — connectors replace folder watch at the edges.

AllowlistScopes + IDsSecurity

SkillsTAR contractsLogic

ScheduleTime / conditionAutopilot

QABefore emitGate

Auditrun_id manifestGov

Implementation paths

Filesystem automation was chapter 1–3; ecosystem automation starts here.

Concept 1

MCP in the Cowork Context

How MCP works inside Cowork — the integration layer that connects your automation to external systems

1.1

How MCP extends Cowork

From file automation to connected system automation — the capability expansion MCP enables

Key takeaway

MCP turns Cowork from a local file COO into a connected ops layer — read Gmail, write Drive, post Slack — under the same Skill contracts and run history.

Why this matters

Teams plateau on folder automation; MCP is how Cowork participates in the systems where work actually lives.

Chapters 1–3 automated your disk. MCP extends Cowork to SaaS and APIs: email, calendar, CRM, chat, repos. Skills gain tool permissions per connector; workflows chain filesystem steps with connector steps in one pipeline.

The mental model shift: from export → process → save to pull → process → push. File paths may still be staging; connectors are production handoffs.

Workflow — do this next

01List top 5 systems where work stalls outside local folders.
02Mark read-only vs write connectors per system.
03Pick one read-only pilot workflow before any write connector.
04Document expansion in CONNECTOR_ROADMAP.md.

Real example

Before vs after MCP

Before: export Gmail labels to CSV nightly, process locally, paste summary to Slack. After: GMAIL_READ_v1 → PRIORITY_FILTER_v1 → BRIEF_COMPOSE_v1 → DRIVE_WRITE_v1 + SLACK_NOTIFY_v1 — one pipeline, one run_id.

1.2

Available connectors in Cowork

Which MCP connectors work with Cowork and how they differ from Claude.ai connectors

Key takeaway

Cowork connectors run unattended — favour stable, scoped, auditable integrations over experimental chat-only plugins.

Why this matters

Assuming Claude.ai connector parity causes failed pilots — Cowork needs connectors that survive schedules and credential persistence.

Common Cowork connector families: Google Workspace, Slack, Microsoft 365, Dev / data, Claude in Chrome

Differences from Claude.ai: Cowork connectors persist for scheduled runs, log to run history, and respect org IT policy

Workflow — do this next

01Inventory connectors in Cowork settings vs Claude.ai.
02Note read vs write capability per connector.
03Align with IT on approved connector list.
04Start pilot on IT-approved read-only connector.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Connector inventory template

| Connector | Cowork | Claude.ai | Read | Write | IT approved |
|-----------|--------|-----------|------|-------|-------------|
| Gmail     | yes    | yes       | yes  | draft | pending     |
| Slack     | yes    | partial   | yes  | post  | yes         |

1.3

Setting up connectors in Cowork

Authentication, permissions, and testing — the connection workflow

Key takeaway

Connect → scope minimally → test manual Skill → document allowlists → then schedule — never reverse the order.

Why this matters

Over-scoped OAuth on day one triggers security review shutdowns; under-tested connectors fail silently on first cron.

Connection workflow: (1) Admin or user OAuth in Cowork connector settings. (2) Define scope allowlist. (3) Create TEST_CONNECTOR_v1 Skill — one read, one write to sandbox destination. (4) Five manual runs (Ch 2 §1.8). (5) Attach to workflow.

Separate service accounts where policy allows — automation identity distinct from personal inbox. Document token owner and renewal date.

Workflow — do this next

01Complete OAuth with least scope.
02Record connector_id and allowed resources in SKILL_SPEC.
03Run TEST_CONNECTOR_v1 read + write to sandbox.
04Security sign-off before unattended write.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Connector setup checklist

[ ] OAuth complete — least privilege
[ ] Allowlist documented (folders, labels, channels)
[ ] TEST_CONNECTOR_v1 five passes
[ ] Credential owner + renewal date
[ ] IT approval reference #
[ ] Sandbox write path verified

1.4

Connector reliability in automated workflows

What happens when an external service is unavailable during a scheduled Skill run

Key takeaway

Design for outage — retry with backoff, degrade gracefully, never pretend success when the API never responded.

Why this matters

Gmail or Slack outages during Monday brief pipelines are inevitable; reliability policy is part of connector design.

Failure modes: HTTP 5xx / timeout, 401 / 403, 429 rate limit, partial read

Degraded mode: if Gmail unavailable, workflow still writes brief from Drive + local inputs; manifest notes missing_gmail: true. Never post empty brief to Slack as success.

Workflow — do this next

01Define per-connector retry policy in PIPELINE_SPEC.
02Implement degraded path for critical workflows.
03Test by revoking sandbox token — expect clean fail.
04Document manual catch-up when API was down.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Connector reliability policy

transient: retry 2, backoff 30s/120s
auth_fail: stop, notify #ops, no retry
rate_limit: wait Retry-After, max 3 waits
degraded: continue without connector X, flag manifest

1.5

Data flow across connectors

How data moves from an external system through Cowork, through Claude, and back out to a destination

Key takeaway

Data flows: connector fetch → staging artifact → Skill/Claude transform → connector push — never let raw API blobs skip staging.

Why this matters

Direct passthrough from API to API without local staging loses audit trail and makes debugging impossible.

Standard path: FETCH → TRANSFORM → EMIT. manifest.json lists each hop and byte size — redact PII in logs.

Minimise data retention: delete raw/ after successful emit per retention policy. Claude context should reference staging files, not paste entire inboxes into prompts.

Workflow — do this next

01Draw data flow diagram for pilot workflow.
02Enforce staging folder per run_id.
03Log connector call summary in manifest.
04Set retention: raw 7d, outputs per compliance.

Real example

Gmail → brief → Drive flow

Gmail API → raw/emails.json → FILTER_v1 → brief.md → Drive API upload to /Briefs/{date}/ → Slack notify with Drive link.

1.6

Security and credential management in Cowork MCP

How Cowork stores and uses API credentials — the security model

Key takeaway

Credentials live in Cowork's secure store — Skills reference connectors by name, never embed secrets in TAR specs.

Why this matters

Secrets in Skill markdown end up in git, Slack, and run logs — the fastest path to incident response.

Rules: no API keys in Skill files; use connector references; rotate tokens on schedule; separate prod vs sandbox connectors; revoke on offboarding within 24h.

DLP: classify connectors by data sensitivity — customer PII connectors require HITL T2 minimum on writes. Read executive mail only with explicit policy approval.

Workflow — do this next

01Audit Skills for hardcoded tokens — remove.
02Map connectors to data classification tier.
03Calendar quarterly credential rotation.
04Offboarding checklist includes Cowork connector revoke.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Connector security rules

- No secrets in TAR / Skills
- Prod vs sandbox connector profiles
- Write connectors: HITL tier documented
- Revoke tokens on role change
- PII connectors: staging encryption at rest if required

1.7

Rate limits and API quotas in Cowork workflows

How to design Skills that respect external service limits — the throttling discipline

Key takeaway

Batch, paginate, cache, and throttle — connector Skills need budgets like token budgets.

Why this matters

A scheduled Skill that pages 10,000 emails at 6am gets rate-limited and produces empty briefs — design limits upfront.

Patterns: pagination caps, incremental sync, cache, stagger

Document per-connector QPS budget in WORKFLOW_SOP. On 429, write RATE_LIMITED.json and reschedule +15m — do not hammer API.

Workflow — do this next

01Read vendor rate limit docs — note daily + per-minute.
02Set max_items per run in Skill Context.
03Implement cursor for incremental fetch.
04Weekly review connector quota dashboards.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Connector throttle spec

gmail_read: max 50 messages/run, since cursor
drive_list: max 100 files/run
slack_post: max 1 message/run (digest only)
on_429: reschedule +15m, max 3 deferrals

1.8

Auditing connector activity

How to review what Cowork accessed, read, and wrote in external systems — the governance layer

Key takeaway

Run history + connector audit log + manifest = who automated what, when, on whose behalf.

Why this matters

Compliance and security teams will ask 'what did Cowork touch?' — answer before they ask.

Audit sources: Cowork run history (workflow, Skill version, status), per-run manifest (connector calls, resource IDs, record counts), external system audit logs (Drive activity, Slack audit). Correlate by run_id

Monthly governance review: new connectors, scope changes, failed auth, unusual write volume. Export CONNECTOR_AUDIT_SUMMARY for leadership.

Workflow — do this next

01Ensure every connector Skill writes manifest footer.
02Include run_id in Slack notifications.
03Monthly: cross-check Cowork history vs Google/Slack admin logs.
04Investigate any write outside allowlist immediately.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Connector audit manifest footer

{
  "run_id": "...",
  "connector_calls": [
    { "connector": "gmail", "op": "list", "scope": "label:Priority", "count": 12 },
    { "connector": "drive", "op": "create", "file_id": "...", "path": "/Briefs/2026-06-22" }
  ]
}

Concept 2

Connected Workflow Examples

The end-to-end connected workflows that show what Cowork with MCP can actually do — complete designs with example Skills

2.1

The Gmail-to-brief workflow

Gmail read → priority filter → draft brief → save to Drive → notify on Slack — end to end

Key takeaway

Reference connected pipeline — fetch only priority label, synthesise one brief template, write Drive, link in Slack — drafts never auto-reply.

Why this matters

Inbox overload is the universal pilot; this workflow proves MCP value in week one if scoped tightly.

Nodes: GMAIL_FETCH_v1 (label:Priority, max 30, since cursor) → FILTER_DEDUPE_v1 → BRIEF_COMPOSE_v1 → DRIVE_UPLOAD_v1 (/Briefs/{date}/) → SLACK_NOTIFY_v1 (#ops-digest). Schedule 6am weekdays; degraded path if Gmail down (Ch 4 §1.4).

HITL T2: human scans brief before forwarding. Skill never sends email replies. manifest logs message IDs read — not full body in Slack.

Workflow — do this next

01OAuth Gmail + Drive + Slack with allowlists.
02Golden test on sandbox label with 5 fixtures.
03Schedule 6am; notify with Drive link only.
04Review audit manifest weekly.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Gmail → brief pipeline spec

GMAIL_FETCH → FILTER → BRIEF_COMPOSE → DRIVE_UPLOAD → SLACK_NOTIFY
scope: label Priority, max 30
output: /Briefs/{date}/brief.md
HITL: T2 — no auto-reply

2.2

The Drive-to-report workflow

Folder monitoring → document processing → synthesis → formatted report → save and share

Key takeaway

Drive folder watch replaces local inbox — same document Skills, connector handoff for delivery and sharing.

Why this matters

Teams already collaborate in Drive; meeting them there beats forcing local drop zones.

Trigger: Drive folder X new file event (or poll every 15m with cursor). DOWNLOAD_TO_STAGING_v1 → CLASSIFY_DOC_v1 → EXTRACT_v1 → SYNTH_REPORT_v1 → FORMAT_REPORT_v1 → DRIVE_CREATE_v1 in /Reports/{week}/ + optional share link generation.

Reuse Ch 2 document Skills — only ingest/emit change. QA_SKILL reconciles extracted totals before publish.

Workflow — do this next

01Pick single Drive intake folder.
02Map file types to extract Skills.
03QA gate before write to /Reports prod folder.
04Share link only after HITL approval.

Real example

Weekly client folder → report

Watch /Clients/Acme/Intake → extract metrics from PDFs + sheets → weekly_acme.md → /Clients/Acme/Reports/ — notify account lead.

2.3

The Calendar-to-prep workflow

Calendar read → context pull from Drive → briefing document → pre-meeting notification

Key takeaway

Prep doc per meeting — attendees, agenda, linked Drive files, open questions — delivered 30 min before start.

Why this matters

Executives lose prep time searching Drive; calendar-triggered pull assembles context automatically.

Schedule: every 30m scan calendar for meetings in 45–75 min window. CAL_READ_v1 → MATCH_DRIVE_v1 (search by meeting title / attendee project folder) → PREP_DOC_v1 → DRIVE_WRITE_v1 + SLACK_DM_v1 to owner.

Exclude all-day and focus blocks. Max 8 meetings per scan — overflow to digest. Never include confidential calendar notes in shared prep without classification check.

Workflow — do this next

01Connect Calendar read-only.
02Define Drive search heuristics per team.
03Template PREP_DOC with fixed sections.
04Pilot DM-to-self before team DMs.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Meeting prep doc template

# Prep: {meeting_title}
## When / who
## Goal
## Linked files (Drive)
## Last decisions
## Open questions
## Suggested talking points

2.4

The CRM-to-outreach workflow

CRM read → context assembly → personalised draft → queue for review → send on approval

Key takeaway

CRM workflow stops at queue — send requires approval.flag per contact; personalisation from CRM fields + style card only.

Why this matters

CRM write/send automation without approval is a compliance and brand disaster — queue is the product.

Nodes: CRM_FETCH_v1 (segment: stale 14d, max 20) → CONTEXT_ASSEMBLE_v1 (deal history, last touch) → DRAFT_OUTREACH_v1 → QUEUE_REVIEW_v1 (review.md per contact) → optional CRM_SEND_v1 only if approval/{contact_id}.flag exists.

Log segment criteria in manifest for audit. Banned: auto-send to enterprise tier accounts — route to human only.

Workflow — do this next

01CRM read-only OAuth; document segment SQL-like criteria.
02Draft to queue folder only — week 1–4.
03Approval flag per contact after manager review.
04Enable send node only with legal sign-off.

2.5

The Slack-to-summary workflow

Channel monitoring → message extraction → daily summary → formatted report → posted back to Slack

Key takeaway

Summarise allowlisted channels to one digest — post to #summary, not threads; redact secrets and HR channels.

Why this matters

Channel overload hurts remote teams; daily digest restores signal if boundaries are strict.

SLACK_READ_v1 (#product, #sales — allowlist only, 24h window, max 500 messages) → EXTRACT_THREADS_v1 → DAILY_SUMMARY_v1 → FORMAT_DIGEST_v1 → SLACK_POST_v1 (#daily-digest). Exclude DMs and #random by policy.

Include 'decisions' and 'action items' sections with message permalinks. On rate limit, defer post + notify ops.

Workflow — do this next

01IT approves channel allowlist.
02Bot scoped to read allowlist + post digest channel.
03Schedule 5pm local; test with quiet channel.
04Monthly review for leaked sensitive content.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Slack daily digest template

*Daily digest — {date}*
*Decisions* (with links)
*Action items*
*Themes*
*Volume:* N messages across M channels

2.6

The GitHub-to-update workflow

Repository monitoring → change detection → plain-language summary → stakeholder update

Key takeaway

Translate commits and PRs for non-engineers — schedule after standup, post to Slack or Drive, link to GitHub.

Why this matters

Founders and PMs want shipping visibility without living in git; this bridges engineering and ops.

GITHUB_FETCH_v1 (repos allowlist, since last_run) → DIFF_SUMMARISE_v1 (plain language, no jargon) → STAKEHOLDER_UPDATE_v1 → SLACK_POST_v1 (#shipping) or DRIVE_WRITE for board folder.

Filter bots and dependency bumps optional. Include 'user-visible changes' section. Cowork complements Claude Code — does not replace engineering tools.

Workflow — do this next

01Allowlist 1–3 repos for pilot.
02Store cursor commit SHA in manifest.
03Schedule daily 9am after US standup.
04PM reviews before board variant posts.

Real example

GITHUB_SHIPPING_DIGEST_v1

Last 24h: 12 PRs merged — highlights checkout fix, new export API; links to PRs; 'no customer-facing changes' when true.

2.7

The multi-source intelligence workflow

Web search + Drive + Slack → synthesis → briefing → delivery

Key takeaway

Intel pipeline combines connectors — diff-based fetches, single synthesis Skill, one delivery path.

Why this matters

Leadership briefs need external news + internal docs + team signal — multi-source is the capstone connected workflow.

Parallel fetch: WEB_SCAN_v1 (allowlist) || DRIVE_FETCH_v1 (intel folder) || SLACK_READ_v1 (#competitive). JOIN_v1 → SYNTH_INTEL_v1 → FORMAT_BRIEF_v1 → DRIVE_WRITE + SLACK_NOTIFY. Extends Ch 3 §3.6 with connectors.

Citations required for web; internal refs link Drive/Slack. QA checks source count ≥ 3 before notify.

Workflow — do this next

01Build each fetch branch with manifest handoffs.
02JOIN then single SYNTH Skill — avoid duplicate narratives.
03Schedule 5:30am; condition force_run for quiet days.
04HITL on external-forward variant only.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Multi-source intel pipeline

(WEB_SCAN || DRIVE_FETCH || SLACK_READ) → JOIN → SYNTH → QA → BRIEF → DELIVER
citations: required for web
schedule: 05:30 weekdays

2.8

Building your own connected workflow

The design process for a custom multi-connector workflow — from use case to running automation

Key takeaway

Use case → systems map → TAR per Skill → connector allowlists → staging data flow → test → schedule — the same discipline as file-only, with connector reliability layered in.

Why this matters

Custom workflows fail when teams skip the design doc and wire connectors ad hoc in the builder.

Design process: (1) One-sentence outcome + non-goals. (2) System diagram — which connectors read/write. (3) TAR per Skill node. (4) CONNECTOR_ALLOWLIST.md. (5) Staging + manifest schema. (6) Test matrix including outage simulation. (7) Schedule with degraded mode. (8) 30-day audit review.

Start read-only across all connectors for v1; add write nodes as separate workflow version v2 after HITL proof.

Workflow — do this next

01Fill CONNECTED_WORKFLOW_DESIGN.md (artifact below).
02IT + security review on allowlists.
03Implement read path end-to-end.
04Add writes one connector at a time.
05Promote to schedule after five clean runs.

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Connected workflow design template

# Workflow name / owner / version

## Outcome (1 sentence)
## Non-goals

## Systems map
read: [gmail, drive, ...]
write: [drive, slack, ...]

## Pipeline DAG
(node list + handoff manifest schema)

## Connector allowlists
(per connector: scopes, folders, channels)

## Reliability
retry / degraded / catch-up SOP

## Security
HITL tier per write; data classification

## Test log
| run_id | case | pass |

Ready-to-use artifacts

Complete templates — paste directly into your AI tool or automation workflow.

Connector setup checklist

OAuth, allowlist, test Skill, IT approval.

Least scope → TEST_CONNECTOR_v1 ×5 → security sign-off → schedule

Connected workflow design template

From use case to running multi-connector automation.

Outcome · systems map · DAG · allowlists · reliability · test log

Connector inventory template

| Connector | Cowork | Claude.ai | Read | Write | IT approved |
|-----------|--------|-----------|------|-------|-------------|
| Gmail     | yes    | yes       | yes  | draft | pending     |
| Slack     | yes    | partial   | yes  | post  | yes         |

Connector setup checklist

[ ] OAuth complete — least privilege
[ ] Allowlist documented (folders, labels, channels)
[ ] TEST_CONNECTOR_v1 five passes
[ ] Credential owner + renewal date
[ ] IT approval reference #
[ ] Sandbox write path verified

Connector reliability policy

transient: retry 2, backoff 30s/120s
auth_fail: stop, notify #ops, no retry
rate_limit: wait Retry-After, max 3 waits
degraded: continue without connector X, flag manifest

Connector security rules

- No secrets in TAR / Skills
- Prod vs sandbox connector profiles
- Write connectors: HITL tier documented
- Revoke tokens on role change
- PII connectors: staging encryption at rest if required

Connector throttle spec

gmail_read: max 50 messages/run, since cursor
drive_list: max 100 files/run
slack_post: max 1 message/run (digest only)
on_429: reschedule +15m, max 3 deferrals

Connector audit manifest footer

{
  "run_id": "...",
  "connector_calls": [
    { "connector": "gmail", "op": "list", "scope": "label:Priority", "count": 12 },
    { "connector": "drive", "op": "create", "file_id": "...", "path": "/Briefs/2026-06-22" }
  ]
}

Gmail → brief pipeline spec

GMAIL_FETCH → FILTER → BRIEF_COMPOSE → DRIVE_UPLOAD → SLACK_NOTIFY
scope: label Priority, max 30
output: /Briefs/{date}/brief.md
HITL: T2 — no auto-reply

Meeting prep doc template

# Prep: {meeting_title}
## When / who
## Goal
## Linked files (Drive)
## Last decisions
## Open questions
## Suggested talking points

Slack daily digest template

*Daily digest — {date}*
*Decisions* (with links)
*Action items*
*Themes*
*Volume:* N messages across M channels

Multi-source intel pipeline

(WEB_SCAN || DRIVE_FETCH || SLACK_READ) → JOIN → SYNTH → QA → BRIEF → DELIVER
citations: required for web
schedule: 05:30 weekdays

Connected workflow design template

# Workflow name / owner / version

## Outcome (1 sentence)
## Non-goals

## Systems map
read: [gmail, drive, ...]
write: [drive, slack, ...]

## Pipeline DAG
(node list + handoff manifest schema)

## Connector allowlists
(per connector: scopes, folders, channels)

## Reliability
retry / degraded / catch-up SOP

## Security
HITL tier per write; data classification

## Test log
| run_id | case | pass |

Chief of staff — Monday brief without tab archaeology

A Series B startup's chief of staff spent 90 minutes every morning across Gmail, Drive, Slack, and news tabs before leadership standup.

Before

Local Cowork Skills summarised CSVs only; priority email and competitive signal still manual; no audit of what was read.

After

Chapter 4 Gmail-to-brief + multi-source intel pipelines; connector allowlists in IT wiki; run_id manifests; read-only month one, Drive write month two.

Morning prep → 90 min to 20 min review
Connector outages → degraded brief with manifest flag (no silent empty post)
Security review → passed with least-privilege OAuth + audit manifest
Slack digest → single #leadership-brief link, not five screenshots

What goes wrong

OAuth scope too broad — security shuts down pilot.

§1.3 least privilege; document allowlists before connect.

API outage → empty Slack post marked success.

§1.4 degraded mode; never emit empty as success.

Secrets pasted into Skill TAR specs.

§1.6 connector references only; quarterly credential audit.

Rate limit hammering at 6am — banned by vendor.

§1.7 pagination caps + incremental cursors + stagger schedules.

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.