Cowork and OpenWork: A 90-Minute crash course

15 concepts, 80% of Real Use

Do agentic co-workers aap ke computer par chalne wale: Claude Cowork (Anthropic) and OpenWork (open-source, MIT, OpenCode-powered). Chatbot ke baraks, har tool khud plan karta hai aur chalata hai multi-step knowledge work: reading aap ki local files, calling aap ki services, working across aap ki apps and aap ke browser, aur aakhir mein tayyar deliverables wapas deta hai. Aakhir tak aap jaan lenge major pieces kya karte hain, kis waqt kis tool ko use karna hai, and failure modes kahan chhupe hote hain dono tools mein.

Yeh kis ke liye hai. Har woh shakhs jiska din information ko move karne mein guzarta hai between documents, spreadsheets, email, and meeting notes: lawyers, accountants, marketers, HR leaders, healthcare administrators (PHI caveats ke saath in Part 5), plus consultants, analysts, and founders. Asal skill delegation hai; aap ko code karna zaroori nahin aur API ka matlab janna bhi zaroori nahin.

Isay achi tarah karna delegation ka masla hai. Is chapter mein har decision (task ko kaise describe karna hai, agent kaun se folders dekh sakta hai, kya "act without asking" on) aik sawal par wapas aata hai: is task ko waqai kitni oversight chahiye? Har section ko isi nazariye se parhein, dono tools mein.

Prerequisite: AI Prompting in 2026. Is ke thirteen concepts (briefing like a colleague, siyaq o sabaq as the whole game, thinking mode, neutral framing, the iterate loop, AI desktop apps and permissions, and models checking models) woh bunyad hain yeh chapter jis par build karta hai. yeh page dikhata hai ke woh discipline kaisi lagti hai jab AI aap ke folders, aap ke connectors call kar sake, aur aap ki taraf se.

If you haven't read the prerequisite yet, start here

Three fundamentals from that chapter carry the most weight in this one. The full prereq has thirteen concepts; here's the absolute minimum to keep going:

1. Brief agent like a smart, motivated new colleague who doesn't know aap ka siyaq o sabaq. Vague prompts get vague answers. specific briefs (with constraints, examples, the audience for the deliverable, and the why behind task) get kaam ka work. "Help me with this contract" is a query. "Review this draft MSA, flag every clause that materially deviates from our redline standard, and produce a comparison memo with deviations color-coded by risk level" is a brief.
2. Give siyaq o sabaq, don't dump it. agent reads everything you put in front of it, including the irrelevant. Attach file you actually need; describe the constraint that matters; state the format you want. Don't paste an entire matter folder when three documents are the relevant ones; the noise dilutes the signal and runs up aap ka token bill (concept 5 in yeh chapter).
3. Iterate on the plan, not output. When something goes wrong, redirect before the work runs, not after. A one-sentence correction at the plan stage costs nothing; cleaning up after a confident wrong execution costs an afternoon. This is concept 4 in yeh chapter, and it's the single highest-leverage habit aap kar sakte hain build.

For the full picture (sycophancy, multimodal inputs, cross-model review, model routing for cost), the prerequisite chapter is worth the 30 minutes. But the three above will get you through this one.

The chapter in five bullets: read this if you read nothing else

The chapter teaches one operational discipline. If you internalize only these five points, you have 60% of the value:

1. Delegate, don't query. Both tools are co-workers you assign, not chatbots you ask. Think in assignments (outcomes with constraints, audience, and the why), not in prompts. (Full treatment in §1.)
2. Three trust levers: folders, connectors, approvals. Make a dedicated working folder; grant access to that, not aap ka whole Documents directory. Connect each external service as a separate decision with the narrowest scope that works. Stay in the cautious "ask before acting" approval mode until you've calibrated on task type. That's the discipline that earns you the right to relax it later.
3. The plan is the leverage, not output. Ask agent to lay out the plan before it touches any files, and read whatever it produces. Neither tool guarantees an upfront plan unless you ask. (Full treatment in §4.)
4. The autonomy ladder, climbed deliberately. Watch closely → ambient supervision → walk away → high-autonomy → scheduled. One rung per task type, with track record. Step back down the ladder when task type changes (new client, new connector, new edge case). Never schedule what you wouldn't already trust to walk away from.
5. Untrusted content gets the cautious mode, always. An opposing-counsel email, an inbound resume, a vendor PDF, an unknown webpage, these can carry instructions agent reads as commands (prompt injection). Never run high-autonomy mode on tasks that touch text someone else wrote.

The other ten concepts in yeh chapter all serve those five.

Figure 1: The five operational disciplines that carry most of the chapter's weight. Print this and tape it to aap ka monitor.

install

Two tools, not one. On purpose. The discipline yeh chapter teaches has to outlive any single tool: pricing changes, model availability, and data-residency requirements shouldn't strand the lessons you've learned. task loop and the core primitives (skills, connectors, sub-agents) are the same in both; the ecosystems differ, and scheduling is one of the bigger divergences (Cowork has it built in, OpenWork does not; §15 covers the gap). Covering each concept in both is the strongest test of whether it's real: if a technique only works in Cowork, it's a Cowork trick; if it works in both, it's part of how AI desktop work actually behaves.

If you're brand new to either tool, start with Cowork. It's the more polished surface and the lowest-friction path to a working first task. OpenWork is younger, ships frequently, and pays off most once you want choice over which model provider sees aap ka prompts, where the work runs, or which plugins compose with what. Everything you learn here transfers; aap kar sakte hain move between the two later.

Pick aap ka tool below. aap ka choice syncs across every Cowork ⟷ OpenWork switcher on the page.

Cowork is a paid-tier feature: it requires an Anthropic Pro, Max, Team, or enterprise plan. The Claude Desktop app itself is a free download; the Cowork tab appears once you sign in on a paid plan.

1. Download Claude Desktop from claude.com/download (Mac or Windows).
2. Sign in with aap ka Anthropic account.
3. Click the Cowork tab at the top of the window.

You're in. Connectors, skills, plugins, and projects are all reached from inside the Cowork tab. Cowork docs: support.claude.com.

Where these tools live

Both tools are desktop apps. They differ in how they're organized.

Cowork lives inside Claude Desktop under a top-level Cowork tab. The window has three regions: a left sidebar for navigation, a center conversation area where agent narrates each step inline as the work happens, and a right panel that tracks files and siyaq o sabaq. The + next to the prompt input is the main entry point for adding files, skills, Connectors, and Plugins (type / for slash commands directly). Folder access is requested inline when agent first needs it, not granted up front.

Cowork's empty main view inside Claude Desktop.

The + menu beside the prompt, Add files or photos, skills, Connectors, Plugins. This is the single entry point for everything that extends a Cowork session. model picker (here, Opus 4.7) sits on the right of the prompt row, switch per-task as needed.

The conceptual primitives (sessions, plans, approvals, skills, sub-agents) are the same in both. The chrome around them is different.

Try it now (five minutes, applies to whichever tool you have installed)

aap kar sakte hain run aap ka first task before reading another paragraph.

1. Click the Cowork tab at the top of Claude Desktop. Make a working folder first if you don't have one: ~/Claude-Workspace/.

2. Type one read-only prompt: List the files in this folder. Don't open or read any files yet.

3. The first time agent needs file access it posts an inline permission card in the conversation. Click Choose folder and pick aap ka kaaming folder.

   Cowork's folder-permission card. Click Choose folder and pick aap ka kaaming folder.

4. Watch file list appear inline in the conversation.

---

Part 1: Foundations

These first three concepts apply identically in both tools. Where commands or click-paths differ, the difference is called out inline.

1. What these tools actually are

The mental shift that matters: this is not a chatbot you query. It's a co-worker you assign. "Summarize this PDF" is a query. "Read these three vendor MSAs, flag every clause that materially deviates from our redline standard, and produce a comparison memo with deviations color-coded by risk" is an assignment. "Reconcile this month's bank statement against the GL export, list every unmatched item, and produce a draft journal-entry recommendation for each one" is an assignment. The first works fine in chat; the rest are what these tools are for.

This is concept 1 of AI Prompting, novice vs. power user, with consequences: brief poorly and agent executes against the gap.

That delegation shift is what makes both tools kaam ka, and what changes the failure modes. In chat, the worst case is a wrong answer: annoying, but contained. Here, the worst case is a confidently executed wrong action that touched dozens of aap ki files. The crash course is mostly about learning to delegate at the right level, with the right oversight, on the right kinds of work.

2. The architecture in three pieces

The desktop app is where agent lives. Both run locally on aap ka machine. If aap ka laptop sleeps or you close the app mid-task, execution pauses where it left off.

task loop is the core mechanic in both. You describe an outcome, agent creates a plan, you approve / redirect / refine, agent executes, it pauses for approval before significant actions, and you receive a finished deliverable. Most of the discipline of using either tool well lives inside this loop.

The execution surface is where agent actually does work. Three layers in both:

• Local files in folders you've explicitly granted access to.
• Code execution inside an isolated sandbox (charts, calculations, file transformations). You don't configure it day-to-day.
• External services through connectors, different catalogs in the two tools, covered in §10.

What you control in both tools is what's outside the sandbox: agent kaun se folders dekh sakta hai, which connectors are turned on, which approval mode you're in.

Figure 2: Where the work actually runs in each tool. The biggest amali difference is privacy: in Cowork, aap ka prompts and file content agent reads go to Anthropic for processing. In OpenWork, you pick model provider that sees them, Anthropic, OpenAI, OpenRouter, or a self-hosted model on aap ka own hardware. aap ki files themselves stay on aap ka machine in both.

3. Folders, connectors, approvals: the trust model

Figure 3: The three trust levers. Set these three deliberately and you have most of the safety story for either tool.

Folder access is how you tell agent which parts of aap ki filesystem are in-scope. agent cannot read or write outside what you've granted.

When task first needs file access, an inline permission card appears in the conversation ("Claude would like to Cowork in a folder") with Deny / Choose folder buttons. Click Choose folder, navigate to aap ka kaaming folder, confirm. The grant is scoped to the session. (Some Cowork builds also expose a top-level Choose folder button before you start task; the inline gate is what aap most often encounter.)

Cowork's inline folder-permission card. The gate appears at the moment agent needs file access, not as an upfront pre-approval.

The single most-leverage habit in this whole course: make a dedicated working folder (~/Claude-Workspace/ or ~/OpenWork-Workspace/) and grant agent access to that, not aap ka entire home directory or aap ka Documents folder. When something goes wrong, the blast radius is the working folder, not aap ka life. This matters extra for professionals: a lawyer's Documents folder contains privileged matter for forty different clients; an accountant's contains tax returns; a healthcare administrator's may contain PHI you didn't realize was loose. Scope tight from day one.

Once granted, type a small read-only prompt to see the approval asymmetry in its smallest form:

List the files in this folder and tell me what kinds of things
are here. Don't open or read any files yet.

aap see file list appear in the execution view with no approval card. That's the point: agent reads without asking; it asks before it writes. Reads are automatic, writes are gated, and that asymmetry is the whole approval model in miniature.

Connectors extend agent into external services. Each connector you turn on is a separate trust decision: the OAuth scopes you grant at install are what agent can read and (sometimes) write through that service. The catalog, install path, and screenshots live in §10; here, only the trust framing matters.

Two specifics worth surfacing now because they shape the trust calibration:

• Native Cowork mail connectors create drafts; they do not send. Anthropic's Google Workspace connectors documentation confirms this for Gmail: agent assembles, you review, you click send. Third-party tool routers can offer broader send capabilities; if you wire one of those up, treat it as a separate, higher-trust decision. For a lawyer or CFO, "an email that appears from my address" is something a court or board may rely on.
• Read scope = send scope. Granting a mail connector read scope lets agent summarize threads. Granting write/send scope is a different ask. Read the scopes before you click connect.

approval modes govern how agent behaves when it wants to take a significant action.

Two modes set per task: Ask before acting (default; pauses on each significant action) and Act without asking (works through the plan without pausing per step). Even in "act without asking," deletions still require explicit permission.

The approval table is asymmetric on purpose in both tools: reads happen automatically; writes, modifications, deletions, and moves all require an explicit click before agent proceeds.

What file types these tools handle natively. Both Cowork and OpenWork ingest PDFs (native and scanned), Word documents, Excel/Sheets files, and email/chat threads from connectors. No extra setup. A few amali notes:

• Native (text-based) PDFs: read cleanly and accurately.
• Scanned PDFs: go through OCR. Quality depends on the scan: usually good enough for synthesis, not good enough for verbatim quotation without checking. If you're going to cite a specific clause from a scanned document, open the original.
• Excel files with formulas and multiple tabs: read fine. agent can also compute against them in the sandboxed environment. Watch the cell-reference labels in any analysis it reports back: labels are sometimes confidently mislabeled even when the underlying math is right.
• Word documents with tracked changes: readable. Whether agent's edits preserve tracked changes is a separate question. For litigation redlining specifically, do a careful round-trip test on a non-critical document before trusting the result on a real matter.

When in doubt, ask agent to summarize file's structure first ("describe what's in this file: how many tabs, how many pages or clauses, what the columns or sections are") and decide whether to proceed based on what it tells you.

What happens when it goes wrong: recovery patterns. Before granting write access, the question worth asking is "what if agent does something I didn't want?" In either tool:

• files agent edits in place have no automatic version history. Recovery depends on what's underneath aap ka folder. macOS Time Machine, Windows File History, OneDrive / Google Drive / Dropbox version history, or a git repo will all let you roll back. A folder on a plain local disk with no backup running is unforgiving. That's part of why the dedicated working-folder discipline above matters: it limits the blast radius.
• files agent created or moved are recoverable through the same backup mechanisms. Renames are recoverable from the backup history too.
• Connector-side actions (a Notion page edited, a calendar event created, a Slack message posted) are recoverable through that service's own version history or audit log, not through agent. Each connector has its own recovery story. Check it before you grant write scope.
• Messages sent through any send-capable connector (rare in native Cowork, see Concept 10, but possible in third-party setups) are not recoverable. Treat send actions as production deploys.
• The Stop button on the active session halts a running task immediately. A halted task is recoverable. A completed action is only as recoverable as the underlying system makes it.

amali preflight: before aap ka first real-stakes Cowork or OpenWork session, confirm one of the backup options above is running. Two minutes now, peace of mind on every task afterward.

What works dono tools mein: leave approvals tight for the first two weeks. Watch what agent wants to do. Notice the patterns of approvals you keep granting for the same kind of action: that's the work that's safe to delegate more autonomously. Notice the approvals where you actually had to think: that's the work that needs to stay supervised.

Anti-pattern: flipping to "act without asking" (or stacking "allow always" across every action) because the prompts feel slow on day three. The prompts are how you build calibration. Skipping them is how you end up with a confidently-executed mistake across 40 files, which, for a lawyer mid-discovery or an accountant mid-close, is not "annoying" but a billable-hour-eating cleanup operation.

---

aap ka first real task: a multi-source follow-up brief

The trust model is the foundation. The next thing to build is hands-on experience running task end to end. This is the canonical "first real task", bounded, teaches the multi-connector pattern, produces a deliverable you'd actually want.

The example below is framed for a sales / business-development siyaq o sabaq, but the shape is identical across the professions covered here:

If aap hain a...	aap ka "first real task" looks like...
Marketer / business developer	Draft a follow-up email synthesizing a sales call (Notion notes + Slack thread).
Lawyer	Draft a status memo to the client synthesizing yesterday's meet-and-confer (case management notes + opposing counsel emails + aap ka associate's research file).
Accountant	Draft the variance commentary for a monthly review (GL export + last-month's commentary + the operations team's email explanations).
HR partner	Draft a candidate-debrief brief for the hiring manager (interview scorecards across the panel + the candidate's resume + the JD).
Healthcare admin (non-PHI work only)	Draft a board update on this quarter's clinic operations (ops dashboard exports + last leadership meeting notes + the budget email thread). Stop here if any of these contain PHI.

The scenario: you had a sales call with Acme yesterday. aap ka rep took notes; the prospect's questions during the call ended up in a chat thread. You promised a follow-up email. The naive way is to re-read everything aap kaself and draft it. agent way is to delegate the assembly so aap kar sakte hain spend aap ka time on what the email actually says.

aap start with the core: a small starter folder you download and open dono tools mein, no accounts to set up. Once you've felt the delegation pattern end-to-end on local files, the closing section shows how to swap them for live connectors (Gmail, Slack, Notion, whatever aap ka daily workflow runs on), same task, real sources, real impact on aap ka week.

Step 1: Download the starter folder. Grab acme-followup-starter.zip (≈2 KB), it contains acme-call-notes.md, acme-chat-thread.md, and a short README. Unzip anywhere convenient, Desktop, documents, wherever. agent will write the deliverable into this same folder.

Step 2: Open the folder in aap ka tool.

• Cowork. Open Cowork. When you run the prompt below, an inline permission card appears the first time agent tries to read; click Choose folder and pick the unzipped acme-followup-starter/ folder.
• OpenWork. Click + Add workspace > Local workspace, pick the unzipped folder, click Create Workspace. Future sessions in that workspace inherit the scope.

Step 3: First, let agent see what's in the folder. No plan yet, just orient. Type:

Read everything in this folder and tell me what's here.
Then ask me 1-2 questions about what I'm trying to do
before we start.

agent reads both files, summarizes what it found, and asks something like "This looks like a sales call follow-up, are you drafting the email to Raj, or something else from these notes?" Answer in a sentence. Thirty seconds of back-and-forth, much sharper siyaq o sabaq for what comes next. This is the cheapest quality lever dono tools mein.

Step 4: Now ask for the deliverable, with a plan. Once agent has the siyaq o sabaq, send the real ask:

Yes, draft the follow-up email. It should:

- Thank Raj and reference one specific thing from the call
- Answer the two questions he asked in the chat thread
- Suggest next steps (proposal walkthrough, timeline)
- Match my normal email tone (direct, no throat-clearing)

Save as acme-followup.md in this folder. Lay out your plan
first, then pause for my approval before touching anything.

Why "lay out aap ka plan first" matters. Without it, agent may just start executing with per-step approval cards: fine for sada tasks, less kaam ka for multi-source synthesis where you want to catch a misreading before agent commits to it. The instruction makes the plan-review step deterministic across both tools.

Step 5: Read the plan. Look for:

• Did agent identify both source files as inputs?
• Are the two questions from the chat-thread file represented in the plan?
• Are the constraints from aap ka prompt (one specific reference, two answers, suggested next steps, direct tone) all captured?

If something's off, redirect instead of approving: "In step 2, also pull the action items from the call notes, the pricing-by-Friday commitment is what I want to mention as 'one specific thing from the call.'" agent rewrites the plan and re-asks for approval.

Step 6: Approve and watch. agent reads both files, drafts the email, saves it. The first time you run something like this, watch every step in the execution view: you're calibrating what kinds of decisions agent makes well versus where it drifts. After three or four of these, aap have the pattern.

Step 7: Review and iterate on the deliverable. Open acme-followup.md. Does the email read like you wrote it? Does it actually answer the two questions, or did it gloss over one? You have two options, and choosing between them well is its own skill:

• Edit by hand. Right answer if the deliverable is 90% there and you'd just rewrite a sentence or two. tezer than asking agent to revise.
• Iterate with agent. Right answer if there's a structural issue: one of the questions wasn't fully addressed, the tone is off in a specific direction, the next-steps paragraph is too pushy, the second paragraph repeats the first. Don't rewrite the whole thing aap kaself; tell agent what's wrong and ask for a revision: "The answer to their implementation-timeline question is too generic; rewrite it using the 4-6-week security-review detail from the chat thread, not boilerplate." This is concept 7 of the prompting chapter, the brainstorm-iterate loop, applied to a Cowork / OpenWork artifact: feedback in, revision out, repeat until done.

If you're used to working alone, hand-editing will feel like the default. Resist it. The brainstorm-iterate loop is tezer than hand-editing for anything beyond a one-sentence fix, and it teaches agent aap ka taste in the process, which improves the next deliverable's first draft. The goal isn't a perfect first draft; it's a 70% draft you finish in five minutes (with one or two iteration rounds) instead of a 0% draft you spend thirty minutes assembling.

What to notice. Five delegation decisions you just made, identical dono tools mein:

1. Folder scope: chose a working folder, not a broader part of filesystem.
2. Explore before assigning: let agent read and ask before committing to a deliverable.
3. Outcome framing: described the deliverable, let agent propose how to assemble it.
4. Plan request + review: asked for a plan, then read it before approving, caught any misreading before agent committed to it.
5. approval mode: stayed in the cautious mode because content from a third party is untrusted.

That's the template. Every multi-source synthesis task has this shape: folder, explore, outcome, plan, execute, review.

When you're ready: the same task with connectors. Once you've run the local version, the upgrade is small. Replace the two local files with their real-world sources: a Slack/Teams channel for the chat thread, a Notion/Confluence/OneDrive page for the call notes. install the connectors in Cowork via Customize > Connectors (see §10); in OpenWork via Settings > Extensions. Re-run the same prompt with the source lines pointing at the connector sources instead of the local files:

- "Notion page 'Acme Discovery Call, 2026-04-29'" (in place of acme-call-notes.md)
- "Slack thread in #acme-deal from 2026-04-29" (in place of acme-chat-thread.md)

The five delegation decisions stay identical. Only the source surface changes. The extra decision aap add the first time you run with connectors: granting connector scopes at appropriate (not maximum) levels, see §3 and §10.

---

Part 2: siyaq o sabaq, sessions, and projects

Same primitives as in chat, same pitfalls, slightly different surface, and meaningfully different stakes.

4. The plan is the leverage

The defining discipline of either tool isn't that you write good prompts; it's that you intercept work between intent and execution. Every meaningful action agent takes (reading file, writing file, calling a connector, sending a message) passes through a moment where aap kar sakte hain read what's about to happen and redirect, deny, or let it proceed. Skip those moments and the work goes sideways twenty minutes later, after agent has touched dozens of aap ki files. They're the cheapest place in the entire workflow to course-correct.

Figure 4: task loop. Almost all the discipline of using either tool well lives in step 3, reading what's about to happen before it does.

Plan review is two prompting concepts in one move: think hard (concept 5) before any file is touched, and outline before drafting (concept 7) with filesystem behind it. Edit the plan, not the cleanup.

Where the plan and the intercept points appear:

• Cowork. agent opens with a planning message, then narrates each step inline. Per-action approval cards appear before significant operations (folder access, file writes, sends, scheduling). Intercept happens (a) at the opening plan and (b) at every inline approval card, no monolithic "Approve plan?" button; intercept is per-step and continuous.

Figure 4a: Cowork's plan stage. agent has produced a numbered Execution plan with a fenced code block listing each file it intends to touch. The right panel tracks the deliverables it's planning to produce. This is the moment to intercept, read the plan, redirect with a one-sentence correction, or approve.

Figure 4b: After the plan is approved, the same Cowork session narrating each step inline: "Loaded tools / Used tool / Searched / Read / Created." Each line is a message aap kar sakte hain pause on, redirect, or follow. The intercept points are inline and per-step.

• OpenWork. agent posts a numbered plan in the right panel and streams progress as a todos timeline below it. Permission cards (allow once / allow always / deny) appear inline only at gated actions: writes, sends, deletions, scheduling. Same intercept discipline as Cowork, with the plan and progress visually separated from the conversation. agent picker also exposes a dedicated Plagent, a restricted planning mode that asks for approval before any write rather than executing them.

OpenWork's agent picker. Default / build / Plan. Switching to Plan gives you an approval-gated planning mode that asks before any write: the OpenCode-native equivalent of "wait for the plan before any writes happen."

Figure 4c: OpenWork's todos timeline streaming mid-task. The numbered plan is visible top-right; each step's progress appears as a chevron entry below as agent moves through it. The Stop button (bottom-right, replacing Run task) halts execution instantly when something looks wrong.

What to actually look at at each intercept point (same in both):

• Scope: is agent proposing to touch only files you described, or has the scope crept? "Sort this folder" should not turn into "rename everything in three subfolders." "Review the Smith MSA" should not turn into "review every contract in the matter folder."
• Order: does the sequence make sense, or has agent jumped to a destructive step before a verification step?
• tools: is agent proposing to use a connector or plugin you didn't expect, or one you forgot was installed?
• Assumptions: what is agent assuming about file formats, naming conventions, redline conventions, GAAP treatment, or aap ka firm's house style that it shouldn't be?

If the plan is wrong, you don't have to start over. Type a one-sentence redirect:

Skip step 3, and for step 4 use the column headers in the existing
template instead of creating new ones.

agent rewrites the plan and re-asks for approval. Two minutes of plan review prevents two hours of cleanup.

5. siyaq o sabaq still costs money

This is concept 4 of AI Prompting (siyaq o sabaq is the whole game) with a token bill attached. There, bad siyaq o sabaq cost you a worse answer. Here, it costs you a worse answer and aap ka monthly usage allowance.

Every message either tool sends to model includes system prompt, aap ka global instructions, the project / workspace instructions, the conversation so far, the contents of files agent has read this session, and any active skill content. That all costs tokens, and the bill is aap kas.

In Cowork, the bill goes to aap ka Anthropic plan. In OpenWork, the bill goes to whichever model provider you configured (Anthropic API, OpenRouter, OpenAI, or a self-hosted model where the bill is aap ka hardware). OpenWork's flexibility lets you run a smaller / cheaper model for routine tasks and reserve the frontier model for hard ones; Cowork's bundle is sadar but less tunable.

Two amali implications, identical in both:

• Don't dump entire folders into siyaq o sabaq unprompted. If you say "read every file in this matter folder," agent does it, and you've just paid to load potentially hundreds of pleadings, exhibits, and emails. Better: ask agent to list first, propose what matters, then read only those.

  First, list this folder and tell me which files matter for
  [my question]. Read only those, then summarize.

• End long sessions cleanly. When task is done, start a new session for the next one. Carrying yesterday's conversation into today's task pays for siyaq o sabaq you no longer need.

The same compaction discipline that applies in chat applies here: less siyaq o sabaq, used deliberately, beats more siyaq o sabaq dumped in hope.

A worked example from real practice. A litigation associate had a matter folder with 340 documents (pleadings, exhibits, deposition transcripts, opposing-counsel emails: a typical four-month-old case). Her first instinct was the obvious one: "read everything in this folder and summarize what's happened in the case so far." That request would have loaded several million tokens into siyaq o sabaq (every exhibit, every email, every duplicate copy of every order) and produced a generic summary that mostly told her things she already knew. The token bill on the prompt alone would have been substantial, and agent would have been working from a siyaq o sabaq so large that the recall on any specific point would have been weak (this is the "siyaq o sabaq rot" issue from concept 4 of the prompting chapter).

The right move, executed in two prompts:

Prompt 1: "List the files in this matter folder. Group them by type
(pleadings, exhibits, depositions, correspondence). For each group,
tell me which 3-5 files are most likely to be foundational based on
filename and date. Don't read the files yet."

Prompt 2: "Read only the files you flagged as foundational in the
prior step. Produce a 1-page case-status memo covering: current
posture, next deadlines, the strongest claim, the strongest defense,
and the three open questions I should track."

Two prompts, roughly 12 files actually read, a meaningfully better deliverable, and a token bill maybe 5% of what the original prompt would have cost. This is what "siyaq o sabaq is the whole game, but with a token bill attached" looks like in practice: triage first, read selectively, synthesize once.

Same pattern, any domain with a large source folder: have agent triage first, then read only what matters.

Strategic cost: route hard work to the strong model, plumbing to the cheap one. The prompting chapter's Concept 12 said "AI is jagged"; different models are good at different things, and routing matters. amali rule of thumb dono tools mein: use the strongest model available for the thinking work (multi-source synthesis, contract redline, board memo) and an economy model for the plumbing (file listing, format conversion, OCR on a clean PDF). Most professional sessions have one or two genuinely hard decisions surrounded by a lot of plumbing. Route accordingly. Both tools expose model picker right next to the prompt input, so aap kar sakte hain switch per-task without leaving the chat.

6. Persistent workspaces for recurring work

The one idea here: recurring work belongs in a folder with a siyaq o sabaq file, not a fresh chat each time. If you find aap kaself re-explaining the same siyaq o sabaq every Tuesday, that's a signal the work needs a home.

The pattern is the same in both tools:

1. Make a folder for the recurring work, one folder per matter, client, cycle, or campaign.
2. Drop a markdown siyaq o sabaq file at the root: CLAUDE.md for Cowork, AGENTS.md for OpenWork (filename differs because OpenWork inherits OpenCode's AGENTS.md convention; the job of file is identical). Inside it, the persistent siyaq o sabaq aap ka co-worker should always know: aap ka role, the matter's conventions, terminology, file layout, tone, governance rules, anything you'd otherwise re-paste at the start of every session.
3. Open the folder, run prompts. The siyaq o sabaq file loads automatically. You don't reference it explicitly.

Cowork adds two extras on top of this base pattern: Projects (a named bundle with cross-session conversation memory) and scheduled tasks (built-in cadence, see §15). OpenWork is just folder + AGENTS.md; you re-fire the prompt aap kaself when aap ko chahiye a fresh run, and the siyaq o sabaq file does the persistent heavy lifting.

Misaals of recurring work that map well:

• Lawyer: one folder per active matter. Pleadings and deposition transcripts in the folder; the firm's redline standard, the matter-specific glossary, and citation conventions in CLAUDE.md / AGENTS.md.
• Accountant: one folder per recurring close cycle (monthly close, quarterly review, year-end). TB template in the folder; variance threshold and last-period commentary's tone in the siyaq o sabaq file.
• Marketer: one folder per ongoing campaign or client. Brand guidelines and voice samples in the folder; campaign goals and prior results in the siyaq o sabaq file.
• HR partner: one folder per hiring loop. JD and scorecards in the folder; panel calibration notes and weighting rules in the siyaq o sabaq file.

The two failure modes:

• Putting everything in one folder. siyaq o sabaq bleeds. The "Q1 financial analysis" folder starts pulling in CLAUDE.md rules you wrote for "marketing copy review" two months ago. Separate workstreams, separate folders. Lawyers especially: separate matters, separate folders, always, both for siyaq o sabaq hygiene and confidentiality discipline.
• Standalone sessions for recurring work. If you're re-explaining the same siyaq o sabaq every Tuesday, that's the missing siyaq o sabaq file talking.

The 80/20 rule: every recurring task gets its own folder + siyaq o sabaq file; every one-off task stays as a standalone session.

---

Part 3: Rules and instructions

Both tools have a layered instruction system. Knowing the layers saves you from the most common confusion: "why did agent ignore what I said?"

7. Global, folder, and session instructions

The three layers below are concept 4's context stack with explicit slots: global is the always-on layer (aap ka role, default tone, output formats), folder is what you'd otherwise re-paste every prompt (this client's terminology, this matter's structure, this period's GAAP treatment), and session is the ask for this task.

Figure 5: The three nested layers of instruction. Putting folder-specific rules in global is the single most common mistake.

Three layers, in order of how broadly they apply:

• Global instructions. Apply to every session you ever run.
  • Cowork: set once in Settings > Cowork.
  • OpenWork: set in OpenWork's Settings panel. (Power-user: see Appendix A for the underlying config-file path.)
• Folder / project instructions. Apply when that folder is in scope.
  • Cowork: attach to a specific folder; agent can also update folder instructions on its own during a session as it learns about the folder's structure.
  • OpenWork: set when a project folder is open, through the OpenWork Settings panel. (Power-user: see Appendix A for the project-scoped config files and the AGENTS.md convention.)
• Session prompts. What you type for the current task. Same in both.

The most common mistake is putting everything in global instructions. The result is a 3,000-token system prompt that costs you on every turn and confuses agent with rules that don't apply to most tasks.

The right model: global is sparse, folder is specific, session is the goal. Global should fit in two short paragraphs. Folder instructions live with the work they describe. Session prompts state the outcome.

A working example of good layering, for a marketing analyst:

Global:
I'm a marketing analyst at a mid-size SaaS company. I write in concise,
direct prose. Default to markdown for documents, .xlsx for any tabular
output, and skip the throat-clearing intros.

Folder (Q1-campaign-analysis/):
This folder contains weekly campaign reports from Jan-Mar 2026. Files are
named YYYY-MM-DD-campaign-report.csv. Conversions in column G, spend in
column H. The "control" segment is always row 2.

Session prompt:
Compare conversion rates across the 12 reports in this folder. Identify
the top 3 weeks and what they had in common. One-page summary.

A second example, for a litigator:

Global:
I'm a litigation associate at [firm]. I write in direct, plain English
with no Latinisms unless they appear in the source text. Default citation
style is Bluebook 21st. Always flag any claim that should be verified
against the underlying record before I send it.

Folder (Smith-v-Acme/):
This is the Smith v. Acme matter. Plaintiff is "Plaintiff" or "Ms. Smith"
in our filings, never "Smith." Defendant entity is "Acme" (short form
throughout). Exhibit numbers follow EX-NN-description.pdf. Deposition
transcripts in /depositions; pleadings in /pleadings; opposing counsel
emails in /correspondence/opposing.

Session prompt:
Summarize the key admissions in the three depositions in /depositions
that bear on the breach-of-contract claim. One paragraph per deposition,
with citations to page:line.

Notice what's not in global: the matter-specific naming, the citation form for this filing, the folder layout. Those belong with the matter.

8. The "ask me questions before you execute" pattern

This is concept 6 of AI Prompting (neutralizing sycophancy) moved upstream. There, you rewrote aap ka own prompts before sending so model didn't quietly agree with the answer you implied. Here, you ask agent to surface what aap ka prompt didn't say before it executes against an assumption.

A pattern from Anthropic's own best-practices docs that's worth internalizing dono tools mein: instead of stating task and hoping agent got it, end with "ask me 1-2 clarifying questions before you start."

For non-trivial tasks, this surfaces unstated assumptions that would otherwise become bugs: "Should I include the canceled subscriptions in the count?" / "For the variance commentary, do you want me to flag the FX impact separately or roll it into the line item?" / "In the candidate brief, should I weight technical fit and culture fit equally, or did the panel agree to weight one more heavily?" Two questions, ninety seconds, a much better deliverable.

This is the cheapest quality lever dono tools mein, and the easiest one to skip. For lawyers and accountants in particular, where the cost of getting the framing wrong is a billable-hour rework cycle, the ninety-second clarifying step is an objectively positive ROI on every non-trivial task.

A second instruction worth adding for multi-source tasks: "if the sources contradict each other, flag the contradiction; don't silently pick one." When agent reads three or four source documents, it will sometimes encounter genuine conflicts: the email thread says one delivery date, the contract says another; the panel scorecard rates the candidate "strong hire" but the hiring manager's email is more cautious; one deposition transcript admits a fact that another denies. Without explicit instruction, agent's training pulls it toward smoothing the conflict and producing a confident-sounding output that picks one answer. For a litigator or an auditor, that's the failure mode that produces malpractice. The fix is one line: append "if any sources contradict each other on a material point, flag the contradiction explicitly in the deliverable; do not silently pick one" to task description. This generalizes Concept 6's anti-sycophancy discipline to multi-document synthesis specifically.

---

Part 4: Extending the tool

Both tools extend in four major ways. Decision tree:

• Need agent to follow a specific procedure when a matching task comes up? Skill
• Need agent to read or write through an external service? Connector
• Need a packaged bundle of skills and connectors for a specific role? Plugin
• Need to give agent a richer or different surface to act on? MCP server / desktop extension

Every one of these is a delegation tool, not just a feature. skills shape how agent works. Connectors shape where it can reach. Plugins shape what role it's playing. MCPs shape what surfaces it can act on.

9. skills

A skill is a playbook aap ka co-worker keeps on a shelf. It has a title (so agent knows when to grab it), a procedure (so it knows what to do), and optionally a few bundled tools, a checklist, a script, a calculator, for the steps that need them. You install playbooks once; agent reads spines all day and only opens the one that matches the question in front of it.

Concretely, a skill is a folder with a SKILL.md file at its root. The frontmatter has a name and a description (the "spine"); the body is the procedure. Both tools use the same SKILL.md format (agentskills-compatible), so a skill written for one often works in the other unchanged.

A minimal SKILL.md (works in both):

---
name: weekly-brief
description: Generate the user's weekly status brief from a folder of meeting notes
---

1. List files modified in the last 7 days in the current project folder.
2. Read each meeting-notes file (filename matches *meeting*.md).
3. Read each project file modified this week (filename matches *project*.md).
4. Produce a one-page brief with:
   - 3 bullet "what shipped"
   - 3 bullet "what's at risk"
   - 1 paragraph "next week's focus"
5. Save as weekly-brief-YYYY-MM-DD.md in the current folder.

The description is the single most aham field. It's the spine agent reads to decide whether to open this playbook. Vague descriptions ("helps with weeks") fire on everything; specific ones ("Use when user asks for the weekly brief from meeting-notes files") fire only when relevant.

Three ways skills enter aap ka tool, identical in shape across both:

• From a catalog. Open Customize > skills. Anthropic publishes a built-in catalog; community-run marketplaces have emerged for third-party skills (search "Claude Code skills marketplace" for current sources). Browse, click install.
• Generated in chat. Cowork ships with a /skill-creator skill, type /skill-creator and describe task you do every week. It asks clarifying questions, generates the skill, runs evaluations against test cases, and saves it.
• Authored manually. ZIP and upload via Customize > skills > Upload (private to aap ka account; on Team/enterprise plans, owners can provision skills org-wide).

Cowork's skills tab with /skill-creator selected. Three columns: install scope on the left, skill list in the middle, skill detail and preview on the right. Each skill has an on/off toggle in the detail pane; click a skill to read its full procedure before enabling.

Generated-in-chat is the cheapest path to a first custom skill dono tools mein, and easy to miss if you haven't tried it. For a lawyer: "draft a privilege log entry from a document." For an accountant: "generate variance commentary for a single GL line." For a marketer: "produce a one-line campaign summary in our voice." agent interviews you, drafts the playbook, tests it, and saves it where it belongs.

How agent picks a skill. Auto-invocation happens when task description matches a skill's description; that's why the description spine matters so much. Or you invoke explicitly by typing / to open the slash-command menu (/privilege-log, /variance-commentary, /candidate-brief). Cowork's + button and OpenWork's lightning icon both expose a quick-browse menu (covered in "Where these tools live" and below) so aap kar sakte hain discover and trigger skills without typing the slash command from memory.

OpenWork's lightning-menu popover above the prompt. Three top-level categories (Commands / skills / MCPs) covering every way OpenCode-native extensions surface to user.

Skill content loads on demand. The frontmatter (name + description) loads when the skill registers; the full body loads only when task matches. installing many skills costs less siyaq o sabaq than you'd expect: the gating is built into the architecture.

Auto-invocation depends on the model you're running

Skill auto-invocation, the "ask me clarifying questions" pattern (Concept 8), and the "flag contradictions, don't smooth them" instruction all lean on a strong instruction-following model. On a frontier-class model (Claude Sonnet or Opus, a GPT-5-class model, Gemini 2.5 Pro) they fire reliably. On a smaller or local model, which OpenWork lets you choose for cost or data-residency reasons, auto-invocation can miss the match and output format can drift. The architecture is the same; the operational reliability is not. If you're on a non-frontier model: invoke skills explicitly with / rather than trusting the description to match, and be more prescriptive in aap ka prompts (state output format and what NOT to produce, not just the goal). This is model-capability issue, not a broken skill.

Security note that matters in both tools

skills are trusted code running in aap ka agent environment, sometimes with access to install third-party packages. Only install skills from sources you trust, and read the contents of community skills before enabling them. The OAuth tokens, API keys, and connector credentials in aap ka session are reachable from a misbehaving skill in ways that aren't always obvious. For a lawyer or healthcare admin in particular: a misbehaving skill connected to aap ka email or aap ka case management system is a confidentiality incident, not a productivity hiccup.

10. Connectors

Cowork's catalog is broad: the common workplace services (mail, drive, chat, notes, calendar, code, and more) are typically all available, and the directory updates regularly. Browse and install via Customize > Connectors (or the + button next to the prompt > Connectors). Each install opens a browser for OAuth: sign in, review the scopes, grant. Web connectors run through Anthropic-hosted remote MCP servers; Desktop extensions (local MCP servers running on aap ka machine, with deeper system access) sit behind the same menu at a higher trust bar.

The Cowork Connectors page. Each row is one connector; CUSTOM badges mark non-Anthropic-published connectors that you (or a teammate) wired in. The right pane shows the scope of a selected connector, review this before granting.

(Note for sales/CRM users: there is no native first-party Salesforce connector in Cowork today. Per Salesforce's own announcement, the Salesforce-to-Claude relationship is rolling out through MCP, starting with Slack and expanding across Agentforce 360. Pulling Salesforce records into a Cowork session typically goes through Slack today, or through a third-party MCP server such as Composio. Plan accordingly.)

Where connectors get powerful is combinations. One connector is kaam ka; three connectors that work together unlock workflows that didn't exist before:

• Sales / BD: "Pull last week's Slack thread on the Acme deal, cross-reference with the Notion page on Acme's renewal, and draft a follow-up email."
• Litigation: "Pull the email thread with opposing counsel from last Tuesday in Outlook, cross-reference with the deposition outline in OneDrive, and draft a response that preserves our position on the privilege dispute."
• Finance: "Pull the variance email thread from controllership in Outlook, cross-reference with the close checklist in SharePoint, and draft tomorrow's leadership update."
• HR: "Pull the panel debrief thread from Slack, cross-reference with the candidate's interview scorecards in Greenhouse, and draft a hiring-manager recommendation memo."

Each is three connectors in one task; the answer would have taken a insani 20 minutes of siyaq o sabaq-switching to assemble.

Discipline (same in both): install a new connector when you have a specific workflow it unlocks. Don't install connectors speculatively. Each one expands the surface area where things can go wrong, including new prompt-injection vectors from content on the other side of those services.

11. Plugins

The word "plugin" means different things in the two tools, worth flagging up front:

• A Cowork plugin is a role bundle (skills + connectors + slash commands + sub-agents + config in one download), in Anthropic's plugin format.
• An OpenCode plugin, surfaced in OpenWork's UI as "Plugins (OpenCode)," is an npm package with event hooks that extends the underlying OpenCode engine. OpenWork doesn't have its own plugin format; it's the UI layer over OpenCode's plugin system.

The two are not interchangeable. A Cowork plugin won't install in OpenWork; an OpenCode plugin isn't a bundle of role-specific skills. They serve different needs.

Cowork plugins are role bundles. Each plugin packages one or more skills, connectors, slash commands, sub-agents, and configuration into a single download. Anthropic open-sourced their internal knowledge-work plugins at anthropics/knowledge-work-plugins, the canonical shuruaati nuqta. Slash commands are namespaced (/legal:privilege-entry, /fin:variance-comment, /hr:candidate-brief) to prevent collisions. install via + > Plugins, which opens the Directory.

Cowork's Plugins Directory. Anthropic & Partners shows the published catalog; Personal is where aap ka own plugins live. Each card is a role bundle, Marketing, Finance, Legal, Sales, and so on, bundling that role's skills, connectors, and slash commands together.

amalily:

• If you want a role bundle (say, a Sales plugin packaging Slack + call-prep skills + outreach drafting skills + namespaced slash commands ready-to-go), Cowork's plugin system gets you there tezer out of the box.
• If you want fine-grained control and you're comfortable composing aap ka own bundle from individual skills and plugins, OpenWork is more flexible.
• If aap ka firm or org has standardized on the OpenCode ecosystem already, OpenWork's plugins compose with that work; Cowork's plugin format is its own thing.

For enterprise customers, Cowork admins can publish private plugin marketplaces and auto-install approved plugins for new team members. OpenWork for teams centers on a shared skills repository and a standardized plugin set distributed via aap ka existing source-of-truth (a shared repo, an internal package, etc.).

Caution that matters for both tools

A plugin may install third-party MCP servers and software that run with the same permissions as any other program on aap ka machine. In Cowork, plugins with an Anthropic Verified badge have undergone additional quality and safety review; plugins without it should be reviewed before you install them. OpenWork plugins are open-source and reviewable; "open-source" is not the same as "audited." Each plugin you add expands agent's surface area in ways that aren't always obvious, including new prompt-injection vectors from whatever data sources the plugin's connectors reach.

A worked example: a marketer who installed too many plugins, too tez. A growth marketer at a SaaS company saw the plugins announcement and installed seven of them in one afternoon: Sales, Marketing, Research, Comms, Analytics, plus two community plugins from a forum thread. The next morning she opened Cowork, started typing / for a slash command, and got a list of forty-three options across the seven plugins, many with overlapping names (/marketing:brief and /comms:brief and a community /brief), and one community plugin that had silently installed an MCP server reaching into a third-party analytics tool she didn't remember authorizing. Two hours of cleanup followed: uninstall everything, audit what was left, reinstall only the two she actually used (Sales and Marketing), confirm the namespaced slash commands didn't collide. The lesson she internalized: install plugins the way you install browser extensions: one at a time, with a specific workflow you wanted to enable, and audit monthly. The friend who'd pointed her at the seven-plugin install meant well; speculative installation is the same anti-pattern at scale that "act without asking on day three" is at the per-task level.

12. Sub-agents

Sub-agents are the feature most readers under-use, because the trigger isn't obvious. yeh bunyadi mechanics are identical in Cowork and OpenWork.

When task breaks into parallel work, agent can spawn sub-agents: parallel workers that each handle a piece simultaneously. Instead of reading 20 contracts sequentially, agent dispatches four sub-agents that read five contracts each in parallel. Each works in its own siyaq o sabaq, so the main session stays clean: what comes back to aap ka main thread is the sub-agent's result, not the raw documents it read.

aap kar sakte hain tell sub-agents fired by watching the execution view: instead of one linear stream of file reads, aap see multiple parallel workers progressing at once, often labeled by their slice of the work (e.g., "contract 3 of 12", "dimension: indemnification"). When they finish, the view collapses back to a single thread for the synthesis step.

Cowork dispatching two parallel sub-agents on the acme-followup-starter folder. The "Ran 2 agents" cards each show a sub-agent's slice ("Inspect README and chat thread / Inspect call notes"); below them, the main thread synthesizes what each one found. The cards collapse back into a single result once all sub-agents finish.

OpenWork's explore prebuilt sub-agent dispatching three workers in parallel, one per file. Each "Explore task" chevron above is one sub-agent's slice of the work; the numbered list below is the synthesis the main thread produces from their results. Same pattern as Cowork, rendered as a timeline.

The exact token accounting (whether sub-agent tokens count against aap ka usage cap, against aap ka siyaq o sabaq budget for the parent session, or are independent in both senses) varies by plan and product version, so check aap ka plan's specifics if cost matters to you. The qualitative point holds: a 30-minute sequential job often becomes a 5-minute parallel job, and aap ka main session doesn't bloat.

You don't write special syntax for this. You frame task to make the parallelism obvious, and agent dispatches sub-agents automatically. Three patterns that reliably trigger parallelization:

Figure 6: Three patterns that reliably trigger sub-agent parallelization. Frame task right and a 30-minute sequential job becomes a 5-minute parallel one.

The fan-out pattern. "For each of these N items, do X." Misaal:

"Process each of the 12 transcripts in this folder. For each one, produce a one-page summary covering [the three or four things that matter to aap ka domain, admissions/inconsistencies/questions for litigation; pain points/feature requests/buying signals for customer interviews; duplicate risk/missing fields/dormant flags for vendor records]. Then synthesize a top-level themes document across all 12."

Same shape, any domain with a batch of similar source documents.

The dimension pattern. "Analyze X across N dimensions."

Legal: "Audit this draft MSA across these dimensions: indemnification scope, limitation of liability, IP assignment, termination triggers, governing law. Flag deviations from our redline standard on each."

The compare pattern. "Compare A and B."

HR: "Read last year's compensation philosophy doc and this year's draft. Extract the principles in each. Identify what changed, what didn't, and which changes are likely to require comms."

When not to invoke sub-agents. Three categories where sequential is better, regardless of tool:

• Genuinely sequential work. Each step depends on the last. "Read the contract, draft the redline based on what it says, then prepare the cover memo summarizing what changed" is three dependent steps, not three parallel ones.
• Small batches. Three files isn't worth parallelizing. Twelve files is. The threshold is somewhere around 5-7 items.
• Tasks where coherence across items matters more than throughput. If the right output for item 3 depends on what was decided about items 1 and 2, sub-agents fragment the reasoning.

A debugging note for both tools. When sub-agent runs go wrong, the symptom is usually consistency drift: sub-agents made different choices about the same edge case because each one only saw its own slice. The fix is to put the consistency rules into the main task description, not into the sub-agent prompts. Telling agent up front "use the same naming convention across all summaries: lowercase-hyphenated, dated YYYY-MM-DD; treat every late-payment clause the same way regardless of how it's labeled in the source" gets passed down to every sub-agent.

The right mental model: sub-agents are best for work that is embarrassingly parallel, many independent units, each with the same shape, where the only thing that matters is doing them all and assembling output.

---

Part 5: Safety and the autonomy ladder

The discipline that matters most lives here, and it applies identically in both tools.

Regulated workloads: full guidance for PHI, attorney-client-privileged matter, and federally regulated data

Do not assume Cowork is approved for PHI, FedRAMP, FSI, or privileged-client workloads on standard plans. The accurate picture as of May 2026, drawn from Anthropic's own Public Sector FAQ and HIPAA-ready Enterprise documentation. Compliance scope changes; re-verify with aap ka account team before relying on any line below:

• Standard Cowork plans (Pro / Max / Team / enterprise without HIPAA enabled): not approved for PHI; no BAA in place.
• HIPAA-ready enterprise configurations: exist for Claude with a click-to-accept BAA, but Cowork is not yet available on any HIPAA-ready enterprise plan per Anthropic's HIPAA-ready enterprise documentation. Do not process PHI in Cowork.
• Claude for Government (C4G): FedRAMP-High authorized, but Cowork is not yet included in C4G's scope per Anthropic's Public Sector FAQ (on the roadmap).
• FSI / financial-services regulated workloads: sales-negotiated; depends on plan, region, and the specific connectors in use.

Before pointing Cowork at regulated data, verify in writing with aap ka compliance team and aap ka Anthropic account team: the exact plan, aap ka BAA / ZDR status, the specific connector and feature limitations under that configuration, and whether Cowork itself is included in the approved scope of aap ka enterprise agreement.

The three things to actually check, regardless of regime, before any regulated data goes through either tool:

1. data residency. Where, geographically and legally, do the prompts and file content land? Cowork: Anthropic-hosted infrastructure (US-based unless aap ka enterprise agreement specifies otherwise). OpenWork: depends on model provider you've configured (Anthropic-direct, AWS Bedrock GovCloud, Google Vertex with Assured Workloads, Azure AI Foundry, or self-hosted) and each has a different residency story. For EU work, "where" matters legally. Ask the question explicitly.
2. Model provider BAA / DPA. Whoever processes the prompt needs the right contract for the regime you're under. HIPAA → BAA. GDPR → DPA. The vendor with the BAA is the one whose servers see the prompt. For OpenWork users that's model provider, not OpenWork. For Cowork users that's Anthropic. Confirm the BAA covers the specific product (Cowork, not just Claude API), the specific features (some MCP and connector features are excluded under HIPAA-ready configurations), and the specific data flow you're running.
3. Logging and audit trail. Who logs what, where, and for how long? HIPAA requires six years of audit-log retention. The BAA does not automatically include application-level logs; those are usually aap ka responsibility. If aap kar sakte hain't show who accessed what regulated data and when, you have a compliance gap, even if model provider's BAA is in order.

OpenWork's local-first architecture changes the data-flow story. The app and file operations run on aap ka machine; the host doesn't ship aap ki files to a vendor by default. But this does not automatically solve compliance. model calls still go to whatever LLM provider you've configured (Anthropic, OpenAI, OpenRouter, a self-hosted model, etc.). The data-residency, BAA, and audit story is that provider's, not OpenWork's. "Local-first" is not the same as "compliant." Get aap ka compliance team's written sign-off on the specific model provider, the specific data flow, and the specific use case before pointing OpenWork at regulated data either.

For both tools: lawyers, the guidance here assumes outside-counsel restrictions on third-party AI processing have already been honored for the matters you'd touch. Healthcare professionals, same with PHI. The safety practices below are necessary but not sufficient for regulated siyaq o sabaqs.

13. The autonomy ladder

Concept 11 of AI Prompting introduced the permission ladder for AI desktop apps as a one-time install decision. The autonomy ladder below is the same shape applied turn by turn, task by task: trust grows with track record on this kind of work, not with how long the tool has been installed.

Figure 7: The five rungs. Climb deliberately, one rung per task type, with track record. Step back down when task type changes.

There's a spectrum from full oversight to full autonomy, and you climb it task by task as you build calibration. Same five rungs in both tools:

• Watching closely. Default mode, novel task. You read the plan carefully, you watch every approval prompt, you stop and redirect at the first sign of drift. This is week one for any new kind of task.
• Ambient supervision. You've done this kind of task a few times. You read the plan, approve, then check in periodically while doing other work. Most regular use lives here.
• Walk away. You trust task pattern. You start it, leave the room, come back to a finished deliverable. Reserve for tasks you've watched succeed multiple times.
• Act without asking (Cowork) / stacked allow always (OpenWork). agent works through the plan without pausing for per-step approval. tezer, riskier. Use only when (a) you're actively supervising the screen, (b) files and sites are trusted, and (c) aap kar sakte hain hit stop the moment something looks wrong. Even here, deletions still require explicit approval in both.
• Scheduled tasks (Cowork only; see Concept 15 for OpenWork's scheduling-gap caveat). agent runs the work on a cadence (daily, weekly) without you watching.

The mistake is climbing this ladder too tez. The discipline is climbing it deliberately, one rung per task type, and being willing to step back down when task type changes (new client, new connector, new edge case) until you've recalibrated.

A worked example: an HR partner who climbed too tez on candidate screening. A recruiter at a 200-person company built a Cowork project for first-round candidate screening: read each resume in inbound/, score against the job description, produce a shortlist with one-paragraph rationales. After running it at the ambient supervision rung a few times and seeing it produce reasonable shortlists, she promoted it to walk away and stopped reviewing the per-candidate plans. Three weeks in, the hiring manager flagged that one candidate agent had ranked as a "strong yes" had a credential discrepancy: the resume claimed a degree from a university that didn't offer that program in the listed years. agent hadn't checked the credential because the job description hadn't asked it to; the recruiter hadn't caught it because she'd stopped reviewing. The fix wasn't to give up the autonomy gain; it was to step back down to ambient supervision for that task type, add a credential-verification step to the project instructions, and only re-promote to walk-away after the new behavior had been watched succeed. This is what "step back down when task type changes" looks like in practice: the change wasn't task description, it was the discovery that task had a hidden quality-check the original calibration didn't cover. New edge case, recalibrate. The autonomy you've earned is task-specific, not skill-generic.

14. Prompt injection is a real attack class

Prompt injection happens when a malicious document, webpage, or email contains instructions that try to hijack agent into doing something you didn't ask for: exfiltrating files, sending messages, disabling safeguards. The instructions look like normal text to you; agent reads them as commands.

This isn't theoretical, and it isn't tool-specific. The combination of (a) agent reading content you didn't author, (b) agent having access to aap ki files and connectors, and (c) any high-autonomy mode means a single poisoned input can move through aap ka system tez. For lawyers reading opposing-counsel correspondence, accountants reading vendor invoices, marketers reading inbound press inquiries, HR reading inbound resumes, and healthcare administrators reading inbound referrals: every one of these inputs comes from someone outside aap ka organization who could, in principle, embed instructions.

Practical defenses (both tools)

• Don't run high-autonomy modes on tasks that involve untrusted content: emails from strangers, web pages you didn't choose, documents from unknown senders, vendor proposals, opposing-counsel filings, inbound resumes. The whole point of "ask before acting" / allow once is to give you a chance to notice when agent is about to do something the actual content asked for, not what you asked for.
• Be careful with new MCPs and plugins. Each one is a new ingestion point.
• Watch for scope creep in the plan. If the proposed plan names files, folders, or connectors you didn't mention, do not click Approve. Either redirect ("only touch the inbox-review/ folder; do not write to anything else") or close task and start over. That's the symptom of either an injection or a confused model.
• Hit Stop the moment things drift mid-task. The Stop button on the active session halts execution immediately dono tools mein. If the execution view shows agent opening file, calling a connector, or sending a message you didn't authorize, click Stop first and ask questions after.
• Remember concept 6's neutral-framing rule, in reverse. In prompting, you learned to strip leading questions out of aap ka own prompts. Here, the risk inverts: someone else's content (an opposing counsel email, a vendor PDF, a candidate's resume, a webpage you didn't write) can carry leading instructions agent reads as commands. The defense is the same instinct, applied to inputs instead of outputs: treat untrusted text as a potential prompt, and stay in the cautious approval mode whenever it's in the loop.

The mitigations are real but not perfect dono tools mein. user-side defense is staying in the cautious approval mode for any task that touches untrusted content.

A worked example: the vendor PDF that almost exfiltrated a client memo. A corporate lawyer at a mid-sized firm was reviewing a software-vendor proposal for one of his clients. He uploaded the vendor's 40-page PDF to Cowork along with the client's strategy memo, and asked agent to draft a one-page comparison of the vendor's claims against the client's stated requirements. He was in the cautious "ask before acting" mode by habit. The plan that came back included an unexpected step: "after producing the comparison, send a copy to [an external email address] for the vendor's records." That instruction wasn't in his prompt. It had been embedded in the PDF: buried in the footer of page 32 in white-on-white text, which his eyes had skipped over but agent had read as an instruction. He clicked Redirect, deleted that step, and the rest of task ran fine. The story shows two things concretely: (a) untrusted content from outside aap ka organization (a vendor proposal, an opposing-counsel email, an inbound resume, a public webpage) can carry instructions that look like text to you and read as commands to agent; (b) "ask before acting" is what saved him. In "act without asking" mode, the exfiltration attempt would have completed before he saw the plan. The lawyer now treats every uploaded vendor document as untrusted by default and runs them only in cautious mode, regardless of how routine task feels. That's not paranoia; it's the discipline section 13 calls "step back down when task type changes." Untrusted-content tasks are their own category, no matter how many trusted-content tasks you've done before.

15. Scheduled tasks need extra care

Cowork has built-in scheduling with two flows. Pick based on whether you're already in the middle of a relevant task or starting fresh.

Quick-fire /schedule from chat. In the prompt input, type /schedule followed by a natural-language description that includes the cadence, for example "/schedule share weekly content updates every Monday 9 AM for agent factory book." Cowork parses the cadence, loads the create_scheduled_task tool, and posts an inline Schedule task card with a parsed Name, Description, time, and a Schedule / Cancel pair. Click Schedule and it's saved. Best for ad-hoc scheduling when you're already running a related task and realize "I should make this a recurring thing."

Step 1 of the slash-command flow: type /schedule followed by a description that includes the cadence in plain language.

Step 2: Cowork parses the cadence and posts an inline Schedule task card. No modal opens, the card lives in the chat itself, and Schedule saves it.

Full-form modal: Scheduled → New task. Click Scheduled in the left sidebar, then New task in the top-right of that view. The Create scheduled task modal opens with: Name field, Description (multi-line textarea), a row of pills for Work in a project, Ask (approval mode), and Default model, and a Frequency dropdown (Manual / Hourly / Daily / Weekdays / Weekly). Best for setting up a recurring task from scratch where you want to fill every field carefully.

The Create scheduled task modal, filled in for the Part 6 weekly-brief example and showing the full Frequency dropdown. Reach this modal via Scheduled → New task; the slash-command flow earlier doesn't open it.

Whichever flow you use, task lives under Scheduled in the left sidebar. From there aap kar sakte hain run any task on demand, edit it, or delete it. A Keep awake toggle in that view tells aap ka OS to suppress sleep during scheduled windows so task doesn't silently miss its trigger because aap ka laptop dozed off.

The Scheduled tab. Both flows land here. From here you manage existing tasks, find the Keep awake toggle, and click New task to open the modal directly.

Cowork's scheduled tasks only run while aap ke computer is awake and the Desktop app is open. OpenWork has no scheduler, so its recurring work is a calendar reminder plus a manual re-fire (you're present for every run). The autonomy-ladder rule still applies in its strictest form for anything you put on a cadence: if you wouldn't already trust this task in "walk away" mode, don't schedule it. A Cowork scheduled task runs without you watching, and aap kar sakte hain't course-correct task you're not watching.

What works well as a scheduled task (either tool):

• Information-gathering jobs (compile yesterday's billable-hour totals, summarize Slack channels, check a folder for new files, summarize the day's docket alerts).
• Tasks with bounded outputs (always produces file in a specific folder, never sends mail, never makes purchases, never files anything).
• Tasks you've watched succeed at least three times under supervision.

What doesn't:

• Anything that sends messages on aap ki taraf se without final review.
• Anything that takes financial actions: purchases, payments, transfers, bill-pay approvals.
• Anything that operates on sensitive files (HR, legal, financial records, anything client-privileged) without an explicit insani-review step.
• Anything that processes content from people you don't know.
• Anything that touches a court filing, a regulatory submission, a board package, or a client deliverable without aap ka eyes on it before it leaves.

build the deliberate path: supervised, then walk-away, then scheduled, with at least a week between each step.

---

Part 6: A complete worked example, twice

You ran a one-off multi-source brief at the top of this guide. This second walkthrough is the inverse: a recurring task you eventually trust enough to schedule. It walks the autonomy ladder deliberately (supervised first run to scheduled) and is run twice: once in Cowork, once in OpenWork. The shape is the same; the surfaces differ.

The example uses a Monday-morning industry brief; the same shape works for any recurring multi-source brief in aap ka domain.

You read industry news every Monday, and synthesizing it eats aap ka morning. You want agent to do the synthesis on Sunday night so Monday morning is just review. The flow is the same plan-then-execute loop from §4, now on a recurring task.

Recurring weekly brief: same task, two surfaces

Step 1: Make it a project, not a session. This is recurring, so create a Cowork project. Name: "Industry weekly brief." Add the relevant folders and connectors (aap ka RSS pipeline, a Google Drive folder where you save articles, the Notion page where you keep ongoing themes).

Step 2: Project instructions.

This project produces a weekly industry brief, delivered Monday at 8am.

Sources:
- Articles saved to /weekly-brief/articles-this-week/
- Slack #industry-news channel from the past 7 days
- Notion page "Ongoing Themes" - topics already on my radar

Output:
- Top 3 stories (one paragraph each, with link)
- 1 paragraph "what changed for our space this week"
- Up to 3 new themes that didn't exist last week
- Save as weekly-brief-YYYY-MM-DD.md to the project's root folder

Tone:
- Direct. No throat-clearing. Assume reader is a domain expert.
- If a story is hyped but actually nothing-burger, say so.

Step 3: Run it once manually. Don't schedule yet. Trigger task while watching, end-to-end. Check the deliverable. Refine the project instructions accordingly.

Step 4: Run it manually a second time. Check again. If it's good twice in a row with no edits, you're ready to schedule.

Step 5: Schedule it. Type /schedule and set frequency to Weekly, time to Sunday 9pm. Confirm task shows in aap ka Scheduled list.

Step 6: Monday morning review. The brief is in the folder. Read it. File feedback into project instructions: "In future briefs, please cluster mentions of the same company across sources rather than repeating them."

What to notice, same lessons, two surfaces

This walks the autonomy ladder deliberately in both tools:

1. Manual run with watching: supervised mode.
2. Manual run again: checking calibration.
3. Scheduled (Cowork) / regularly-triggered workspace (OpenWork): walk-away mode with downstream review.
4. Eventually, after six or eight successful runs, the brief becomes ambient.

What's reusable. The shape (workspace, instructions, manual runs, recur once trusted, feedback loop) is the template for every recurring workflow dono tools mein: Friday cleanup, Monday brief, daily inbox triage, end-of-month variance commentary, end-of-quarter board-package prep, weekly hiring-pipeline status, weekly matter-status updates to clients. Same five steps, different content, two tools.

---

Part 7: Where to grow

Connector combinations are where the real value lives

Early on, most tasks lean on one connector at a time dono tools mein. The bigger wins come once you start chaining them. The Slack-search-plus-Notion-cross-reference-plus-email-draft pattern is the canonical example; the actual win is whatever specific combination cuts twenty minutes out of aap ka week. The way to find them: notice the multi-tool tasks you keep doing manually. Any sentence that contains "and then I open the other tab to..." is a candidate.

Audits, dono tools mein

Once a month: review what agent has access to. Folders. Connectors. skills. Plugins. Scheduled tasks (Cowork) / persistent workspaces. Last month's experimental connector is this month's permanent surface area you forgot you had. Ten minutes; skip it for six months and aap find aap ka assistant has access to four things you don't remember granting.

When aap ki team uses the same tool

Most of the chapter assumes one professional working solo. If you're part of a litigation team of six lawyers on the same matter, a finance org with four people running the same monthly close, or an HR partner pair sharing a hiring loop, the tool gets used by a team, and the discipline shifts:

• Cowork at team scale (Team / enterprise plans). Owners can publish private plugin marketplaces, auto-install approved plugins for new team members, and provision skills org-wide. The right move is to treat aap ki team's plugin set, skill library, and Project templates the same way aap ka firm treats document templates and house style: a maintained shared resource, owned by someone, versioned, and audited. Without that ownership, every lawyer ends up with a personal Smith-v-Acme Project configured slightly differently, and the matter team's outputs lose consistency.
• OpenWork at team scale. Distribute the team's standardized state through aap ka existing source-of-truth: a shared repo containing the team's skills library, the agreed plugin set, and shared instructions. New team members clone the repo, open the workspace in OpenWork, and inherit the same skills, plugins, and conventions. This is more setup than Cowork's marketplace approach, and it assumes someone on the team is comfortable with version control, but it composes naturally with how engineering and ops teams already manage shared configuration. (Power-user: Appendix A walks through the concrete files and steps.) For teams without that comfort, the Cowork-with-enterprise route is the sadar answer.
• Confidentiality discipline for shared work. When two associates work the same matter through Cowork, both their sessions touch the matter folder, and both their conversation histories now contain extracts from privileged documents. For a law firm: this is a discoverable record. The audit checklist applies double (whose Cowork sessions, in this matter, are still open from a closed engagement?) and the answer should be zero, because we deleted them at the engagement close.
• Don't share approval-mode habits across teammates. The autonomy ladder is calibrated per person, per task type. A senior lawyer who's earned "walk away" trust on a routine privilege-log task should not assume the junior associate has, and the junior should not feel pressure to climb the ladder tezer than their calibration allows. The shared instructions / shared plugins are team-level; the autonomy ladder stays individual.

For org-wide rollouts, the next step is the vendor's enterprise team. Anthropic's enterprise team for Cowork. For OpenWork, check the project's GitHub for current support and enterprise contacts. Either will walk through SSO, audit logs, and admin controls. The discipline in yeh chapter is what to install before that conversation, not a substitute for it.

Cross-model review for high-stakes outputs

One last move worth importing from the prompting chapter: for high-stakes deliverables (a board memo, a settlement letter, a regulatory filing, an offer letter, a clinical workflow document, a client-facing strategy memo) apply concept 13 to agent's outputs. Different family, different blind spots. A draft agent produced, scored against a rubric in a second model, then revised, is the closest thing to a senior reviewer this technology offers when no senior reviewer is in the room.

In Cowork, the second model is whatever chat tool you have open in another tab. In OpenWork, aap kar sakte hain configure a different model provider in the Settings panel and ask agent itself to do the cross-model pass: same workflow, different mechanics.

How to actually get good at this

Reading this crash course doesn't make you good at either tool. Using it does, and the path is the same shape as it was for the previous chapter on prompting fundamentals.

You start manual. You feel friction: every plan you have to read, every approval prompt, every "wait, why does it want that connector." That friction is where the skill comes from. Each piece of friction maps to one of the concepts above:

• "Why does agent keep formatting the report wrong?" Global or folder instructions are missing the format spec.
• "Why does it want to touch files I didn't mention?" The plan has scope creep; redirect, don't approve.
• "Why is it slow on this batch of 20 files?" Frame task to make sub-agent parallelism obvious.
• "Why am I describing this same workflow every Tuesday?" That's a Cowork Project / OpenWork persistent workspace, not a fresh session.
• "Why did it just send something it shouldn't have?" High-autonomy mode on task that wasn't ready for it.

build the response when you hit the problem, not before. aap ka global instructions should be two paragraphs, not twenty. aap ka list of persistent workspaces should have three before it has ten. aap ka high-autonomy usage should be earned, not defaulted.

The 80/20 isn't memorizing concepts. It's noticing which one a given problem belongs to, tez enough that you reach for the right tool. That noticing is the skill.

The portability dividend. Cowork's intercept pattern is the same as OpenWork's; sub-agents work the same way; the autonomy-ladder discipline is identical. Once you've built delegation calibration in one tool, the other is mostly learning where the buttons live.

Start with one task. Use a working folder. Read the plan. Approve cautiously. Audit monthly. The rest builds itself.

---

First week path (dono tools mein)

If you want a concrete sequence rather than a bag of concepts:

• Day 1. install (Claude Desktop for Cowork; openworklabs.com/download for OpenWork, the desktop download, not the source build). Make a working folder, grant access, run one read-only prompt. That's aap ka installation acceptance test.
• Day 2. Run one low-stakes task. Pick a multi-source synthesis from the table at the top of "aap ka first real task", the one that maps to aap ka profession. Stay in the cautious approval mode. Watch every prompt.
• Day 3. Write aap ka global instructions. Two short paragraphs. aap ka role, aap ka tone, aap ka default formats. Resist writing more.
• Day 4. Pick one recurring task you do manually each week. Set it up as a Cowork Project / OpenWork persistent workspace. Add folder access and any obvious connectors.
• Day 5. Run that recurring task manually inside the workspace. Capture what worked into the project instructions. Don't schedule yet.
• Day 6. Run it manually a second time. Refine. Notice what agent got wrong twice: that's a pattern that needs to be written into instructions.
• Day 7. Audit what you've installed: folders, connectors, skills, plugins. Decide what stays. Schedule the recurring task only if both manual runs were clean.

Aakhir tak of week one, you should have one supervised one-off pattern and one in-progress recurring workflow, with a permission profile that fits aap ka actual usage rather than the defaults. Add the second recurring workflow in week two; don't try to automate everything in week one.

---

Quick reference

The 15 concepts in one line each

1. What these tools actually are: agentic co-workers that run on aap ka desktop, plan-then-execute, return finished deliverables. Delegate, don't query.
2. The architecture in three pieces: desktop app (where it runs), task loop (plan, approve, execute), execution surface (files, sandboxed compute, connectors).
3. Folders, connectors, approvals are the trust model. Dedicated working folder; per-connector decision; cautious approval mode until calibrated.
4. The plan is the leverage. Read it before approving. Two minutes of plan review beats two hours of cleanup.
5. siyaq o sabaq still costs money. Don't dump folders into siyaq o sabaq unprompted. End long sessions cleanly.
6. Persistent workspaces. Cowork Projects / OpenWork workspaces with saved project instructions for recurring work; one-offs stay as fresh sessions.
7. Global, folder, and session instructions stack. Global is sparse, folder is specific, session states the goal.
8. Ask-clarifying-questions pattern: end task descriptions with "ask 1-2 clarifying questions before you start." Cheapest quality lever.
9. skills are agentskills-compatible across tools. Auto-invoke on description match, or /-browse. Use the skill-creator pattern. Read third-party skills before installing.
10. Connectors link to external services. Cowork has a richer out-of-box catalog; OpenWork is leaner-but-ejectable to OpenCode's ecosystem.
11. Plugins. Cowork: bundles, namespaced slash commands. OpenWork: opencode.json plugins, atomic capabilities.
12. Sub-agents parallelize embarrassingly-parallel work dono tools mein: fan-out, dimension, and compare patterns. 30 minutes becomes 5 minutes for batch jobs.
13. The autonomy ladder: watch closely, ambient supervision, walk away, high-autonomy mode, scheduled. Climb deliberately.
14. Prompt injection is real dono tools mein. Don't run high-autonomy mode on tasks that touch untrusted content.
15. Scheduled tasks need stricter trust. Cowork has built-in scheduling; OpenWork's pragmatic answer for non-developer users is a calendar reminder + a manual re-fire of the saved prompt in the workspace, not cron.

Action quick-ref

Both columns describe the in-app UI path. OpenWork's underlying config-file paths are in Appendix A for power users.

Want to...	Cowork	OpenWork
Open the tool	Cowork tab in Claude Desktop	OpenWork desktop app
Grant folder access	Grant Access button in Cowork tab	Project folder picker on session/worker create
Add a connector	+ > Connectors > Browse	Settings > Extensions > tap an Available app; or Add Custom App; or add an OpenCode plugin
install a skill	+ > skills > Browse, or Upload ZIP	skills tab > Import local skill, or Create skill in chat
Trigger a skill manually	Type / to browse, or describe naturally	Type / to browse, or describe naturally
Generate a custom skill	/skill-creator	skills tab > Create skill in chat
Set global instructions	Settings > Cowork > Global instructions	Settings panel, global scope
Set folder instructions	Available when a folder is in scope	Settings panel, with the project folder open
Make a persistent workspace	New Project in the Cowork sidebar	+ Add workspace > Local workspace; save project instructions in Settings
Schedule task	Run it manually first, then /schedule	Calendar reminder + manual re-fire of the saved prompt
Switch to high-autonomy mode	Per-task "Act without asking" toggle	Stack allow always across each permission task needs
Stop a running task	Stop button in the active session	Stop button in the active session

Trust-level decision tree (both tools)

New kind of task?
    -> Cautious approval mode. Watch every prompt.

Done this kind of task a few times?
    -> Cautious approval mode. Check in periodically.

Done this kind of task many times, all clean?
    -> Walk away. Review the deliverable.

All of the above + bounded output, no messages, no purchases, no filings?
    -> Eligible for scheduling (Cowork) or for a
       calendar-triggered manual re-fire (OpenWork).

Task involves untrusted content (stranger email, opposing-counsel filing,
inbound resume, vendor proposal, unknown web pages)?
    -> Stay in cautious approval mode. Never high-autonomy.

Task involves PHI, attorney-client-privileged matter outside your firm's
approved AI workflows, or other regulated data?
    -> Don't run it dono tools mein until compliance has approved
       the specific tool, model provider, and data flow in writing.

Audit checklist (monthly, both tools)

• Which folders does agent have access to? Still want all of them?
• Which connectors are enabled? Each one still in active use?
• Which skills and plugins (Cowork) / .opencode/skills/ and opencode.json plugin entries (OpenWork) are installed? Anything you don't recognize?
• Which scheduled tasks (Cowork) or persistent workspaces are configured? When did each last succeed?
• Global instructions: anything stale or contradictory?
• Any task type that has drifted into a more sensitive category since you set it up? (A matter that has now gone into litigation; an HR project that now involves confidential separation negotiations; a finance project that now touches material non-public information.)

Cowork vs. OpenWork: the honest comparison

Dimension	Cowork	OpenWork
License	Proprietary; requires Anthropic Pro/Max/Team/enterprise	MIT open source
Where work runs	Anthropic-hosted infrastructure (model + most connectors)	Local OpenCode host on aap ka machine; remote optional
models	Claude (Opus, Sonnet, Haiku)	Any OpenCode-supported provider (Anthropic, OpenRouter, OpenAI, self-hosted, etc.)
Cost model	Bundled into aap ka Anthropic plan	Bring aap ka own model API keys; OpenWork itself is free
Connectors out of box	Broad workplace catalog; check the live directory	Lean tap-to-connect grid in Extensions; rest via Custom App or OpenCode plugins
Persistent workspace	Projects (with cross-session memory)	Folder-based workspaces (lighter; state lives in the folder's project instructions)
Plugin model	Bundles with namespaced slash commands; published catalog	Atomic opencode.json plugins; OpenCode ecosystem
Scheduling	Built-in /schedule, multiple frequencies, Keep-awake toggle	No built-in scheduler; pragmatic pattern: calendar reminder + manual re-fire
skills format	agentskills SKILL.md (portable to OpenWork)	agentskills SKILL.md (portable to Cowork)
Sub-agents	Yes (same patterns)	Yes (same patterns)
Best for	Professionals who want polish and out-of-box breadth	Professionals who want local-first execution, model flexibility, or open-source control

Pick the tool whose tradeoffs match the constraints of aap ka kaam. The 15 concepts apply either way.

---

Appendix A: OpenWork power-user reference

Everything below is optional. The OpenWork desktop app exposes the same functionality through its UI; non-developers can stay on the in-app path indefinitely. This appendix exists for users who want the underlying file paths, config syntax, and CLI commands, the kind of content that's kaam ka when you've outgrown the UI or are setting up a team-wide standard.

A.1: OpenWork's configuration files at a glance

OpenWork inherits OpenCode's configuration model. Three files cover almost everything:

• Global opencode.json. Lives at ~/.config/opencode/opencode.json (or $XDG_CONFIG_HOME/opencode/opencode.json if you've set that). Holds aap ka default settings: model provider, default plugins, global preferences. Edit-equivalent in the OpenWork UI: Settings panel.
• Project opencode.json. Lives at <workspace>/opencode.json inside whatever folder you've opened as a project. Overrides the global file for that project: project-specific plugins, custom model choice for this matter, project-scoped instructions. UI equivalent: when a project folder is open, the Settings panel exposes project-level controls.
• AGENTS.md. A plain-Markdown file in the project root containing project-level instructions for agent, tone, terminology, conventions. UI equivalent: project instructions in the OpenWork Settings panel.

A.2: skills folder layout

OpenWork's skills tab reads from two locations:

• Project-scoped skills: <workspace>/.opencode/skills/<skill-name>/SKILL.md (with any supporting files in the same folder). These apply only when this project is open.
• Global skills: ~/.config/opencode/.opencode/skills/<skill-name>/, apply to every project.

To install a skill manually, drop the folder in either location; the skills tab picks it up on the next refresh. The skills tab's Import button does the same thing through the UI without needing to open file browser.

A.3: Plugins via opencode.json

Plugins are listed in the "plugin" array:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["opencode-wakatime", "opencode-notion-mcp"]
}

Each entry is the name of an OpenCode plugin from the ecosystem. OpenWork's Plugins (OpenCode) section in Settings > Extensions lets you add and remove entries by typing npm package names; this is the underlying file that gets edited.

A.4: Team distribution via shared repo

The team-distribution pattern from Part 7's When aap ki team uses the same tool section, in concrete steps:

1. Create a shared git repo with the team's standardized state: .opencode/skills/ directory of skills, an opencode.json listing the team's plugin set, an AGENTS.md capturing shared conventions and terminology.
2. New team members git clone the repo into their workspace.
3. They open OpenWork and select that workspace as their project folder.
4. Their OpenWork sees the same skills, plugins, and instructions everyone else has.
5. Updates flow through normal git workflow, pull requests, code review, release tags. The team-wide AI configuration becomes versioned the same way the rest of the team's tooling is.

A.5: Where to look when something doesn't match

OpenWork is the younger of the two tools and ships frequently. When the chapter says one thing and the app does another, the canonical sources are:

• Repo: github.com/different-ai/openwork, README.md, ARCHITECTURE.md, and PRINCIPLES.md for current scope and design.
• Releases: github.com/different-ai/openwork/releases, what shipped most recently, including UX changes that may have moved click-paths since yeh chapter was written.
• OpenCode docs: opencode.ai/docs, for the underlying CLI, plugin format, and skill format that OpenWork inherits.

---

Appendix B: Plain-English glossary

Terms used throughout the chapter, in alphabetical order. Flip back here the first time any term puzzles you.

• Agent. A program that, given a goal, plans a sequence of steps, takes actions on aap ki taraf se, and reports back. Both Cowork and OpenWork are agents, they do work, they don't just answer. yeh chapter calls them agentic co-workers when it wants to emphasize the assignment-not-query mental model.
• BAA (Business Associate Agreement). A legal contract under U.S. HIPAA that covers a vendor's handling of protected health information. Without a BAA, no PHI should go to that vendor. See the regulated-workloads alarm at the start of Part 5 for which Claude products have BAAs available.
• Connector. A bridge between agent and an external service (Gmail, Slack, Notion, OneDrive, etc.). Each connector requires you to grant scopes (what agent can read, what it can write) when you connect it.
• Ejectability. OpenWork's term for: if you stop using OpenWork, aap ka skills, plugins, and configurations still work in plain OpenCode. The work isn't locked into the OpenWork UI. (Cowork's plugins, by contrast, are Cowork-specific format.)
• Embarrassingly parallel. Used in §12 for a workload that splits cleanly into independent pieces with no order dependency between them, "summarize each of these 14 contracts" is embarrassingly parallel; "draft, then review, then revise" is not.
• MCP (Model siyaq o sabaq Protocol). The open protocol that lets agents talk to external services and tools in a structured way. aap see it in two places: MCP servers (a service that exposes itself to agent, most connectors are MCP servers under the hood), and MCP apps (Anthropic's term for connector-like extensions inside Claude). You don't need to know how MCP works to use either tool; you do need to know that "MCP" is shorthand for "the standard way these tools talk to outside services."
• OAuth. The standard sign-in flow connectors use to ask permission on aap ki taraf se. When you connect Gmail, you get redirected to Google, you sign in there, you click Allow, and the connector receives a token. Anthropic / OpenWork never see aap ka password.
• Plugin. A bundle that packages skills, connectors, and slash commands together for a specific role (e.g., a "Sales plugin" with call-prep skills and Slack integration). In Cowork, plugins are discrete published bundles. In OpenWork, plugins are atomic capabilities composed via configuration.
• Sandbox. An isolated environment where agent can run code without affecting aap ka machine. Cowork's sandbox is Anthropic-managed; OpenWork's sandbox runs locally via the OpenCode host. You don't configure either day-to-day.
• Session. One conversation with agent, scoped to one task. Like a chat thread, but agent can read and write files inside that thread. sessions can be saved and resumed.
• Skill. A reusable, shareable instruction file (SKILL.md) that tells agent how to do a specific recurring task, "draft a privilege log entry from this document" or "generate variance commentary for a single GL line." Once installed, agent uses it automatically when task matches.
• Sub-agent. A parallel worker the main agent dispatches when task splits into independent pieces, "process each of these 12 transcripts." Each sub-agent works in its own siyaq o sabaq, returning only its result, which keeps the main session clean.