General Agents on the Web: A Crash Course

12 Concepts · Your first general agent, in the same browser tab where your Foundations ran

For six courses, you worked in a chat tab. You asked. It answered. You asked again. Every turn started with you. That was a good way to learn. But a plain conversation has a limit: when you stop asking, the conversation stops doing.

A general agent changes the division of labour. You give it an assignment. It plans, uses tools, works through steps, and comes back with a finished thing or a decision that needs you. It may run now, later, on a schedule, or after you close the tab. That is the shift this course teaches.

Browser agents did not suddenly appear in 2026. Scheduled tasks, deep research, cloud coding sessions, and browser-control agents already existed. What changed in mid-2026 was product shape: the major assistants pulled sessions, files, connectors, scheduling, approvals, and artifact creation into a clear everyday work surface beside ordinary chat.

Then August 2026 made that surface more interesting. Claude Cowork gained cross-surface memory, Cowork's own browser, a tighter relationship with Claude in Chrome, richer plugins with sub-agents and hooks, and a hybrid architecture in which a cloud session can reach selected tools on your computer through Claude Desktop. The old mental model, "web is remote, desktop is local," became too simple.

So this course now teaches two questions instead of one:

Where does the agent loop run?
Where does each tool execute?

That distinction is more useful than memorising a product button. A Cowork task can run its agent loop in Anthropic's cloud while a browser or selected local-file operation executes through a connected desktop. A different task may be cloud-only. A local session may run entirely on your machine. The session and the tool do not always live in the same place.

This course is still browser-first. You can complete the core route with nothing installed. But you will also learn the optional bridges just beyond the browser, because by late August they are part of understanding what a web Cowork session can and cannot reach.

Two companies still make the comparison especially useful. Claude Cowork and ChatGPT Work expose different products and different mechanics, but they keep converging on the same anatomy: a heartbeat, ways to reach systems, a run-until-done loop, persistent state, a human gate, and a body where work executes. This book calls that wrapper the harness. The race is no longer only model versus model. It is also harness versus harness.

That gives you the durable skill for this course: learn the shape, then inspect the implementation. Product names, plan tiers, approval labels, and browser choices will move. The shape moves much more slowly.

Who this course is for. It is for knowledge workers first: people whose day is documents, spreadsheets, email, dashboards, portals, calendars, and team chat. Lawyers, accountants, marketers, analysts, founders, students. It is also the gentlest entry point for engineers before the desktop and terminal courses. If you can use a browser and describe a piece of work clearly, you can start here.

What you will be able to do by the end. You will be able to tell chat from delegated work, explain cloud versus local execution without falling into a false binary, choose among connector/browser/local reach, organise persistent context, place every file in the right custody tier, set an approval mode to match the stakes, brief work you will not watch, schedule only proven workflows, and route a task to the right surface.

Do this first: the Foundations, and above all AI Prompting in 2026 and Skills & Connectors. This course expects three things from you. You can brief a model clearly. You know what context is. You know what a Skill and a Connector are. If any of that is new, do those two courses first. Together they take about two hours.

How long this takes. Core route (Parts 1 – 3): about 2 to 2½ hours for a careful beginner read, especially if English is not your first language. Part 4 adds roughly 30 to 45 minutes. The seven appendices are reference material, not one sitting. The projects add hands-on time on top, including one week for the scheduling exercise, and they are where the learning sticks.

New here? A 2-minute recap of what you should already know

Briefing means describing a task in full: the outcome, the limits, the reader, and the reason. A vague prompt gets a vague result. (Foundations Course 2.)
Context is everything the model sees in one turn. More is not better. The right context, chosen on purpose, is better. (Foundations Course 2.)
A Skill is a task you teach once. It lives in a SKILL.md file. The AI loads it only when your request matches. (Foundations Course 5.)
A Connector gives the AI safe, limited access to a real service like Drive, Gmail, or Slack, over the MCP standard. You grant the permissions. The AI works inside them. (Foundations Course 5.)
A chatbot vs an agent. A chatbot answers. An agent plans, uses tools, and finishes steps. This course is where you direct one for the first time.

If any of these are new, read the two Foundations courses first. This course uses all of them on real work.

📚 Teaching Aid

Open Full Slideshow

View Full Presentation – General Agents on the Web

For instructors and self-learners. Teach one transferable idea: every serious agent surface can be read as six parts (heartbeat, connectors/reach, run-until-done loop, state spine, human gate, body). Teach it in three passes. First, the shift: chat waits. Delegated work continues, and session location is not always tool location (Concepts 1 – 3). Second, the surface: persistent context, file custody, the ways an agent reaches the outside world, and how much autonomy you grant it (Concepts 4 – 7). Third, working unwatched: workflow discovery, briefing, plan review, and scheduling (Concepts 8 – 9), then routing work by what it touches and who must hold custody (Concepts 10 – 12). The six projects are the assessment. The two habits to leave students with are: finished work exits the platform, and high-consequence work earns tighter gates.

Key words in plain English

You will see these words throughout the course. Read this list once now, then return whenever the product vocabulary starts moving faster than the underlying idea.

Term	Plain-English meaning
Chat box	A conversation that waits for your next turn. It may use tools during a turn, but it does not become an unattended workflow merely because the answer is long.
Agent surface	A place where you assign an outcome and the system can plan, use tools, and keep working across steps.
Agent loop	The part that decides what to do next until the assignment is finished, blocked, or stopped.
Cloud session	A session whose agent loop runs on the vendor's servers. Your tab or phone is a window onto it.
Local session	A session whose agent loop runs on your own machine. If that machine sleeps or disconnects, the run cannot continue normally.
Desktop bridge	A controlled path that lets a cloud session call selected tools on your computer, such as connected local folders or a browser, while the required desktop component is online.
Tool execution location	Where a particular action actually happens. A cloud agent loop can call a cloud connector, a browser on your computer, or a local file tool. Do not assume the tool lives where the agent loop lives.
Connector	Permission-scoped, usually structured access to a service such as Drive, Gmail, Slack, or a business system. Prefer it over screen-driving when it can do the job.
Browser agent	An agent using a browser to read pages and, where permitted, click, type, navigate, and fill forms. Browser use expands both capability and prompt-injection risk.
Task filesystem	Temporary working space used while a remote task runs. Treat it as scratch, never permanent storage.
Platform storage	Files and session state saved to your vendor account. They survive the task, but remain in the vendor's custody and format.
The exit (Tier 3)	The deliverable enters a system you control: your Drive, records system, local folder, repository, inbox, or another durable destination.
Session history	What happened in one task or conversation. It is not the same thing as semantic memory.
Project	A persistent workspace that groups related tasks, files, links, instructions, and – where supported – project-specific memory.
Semantic memory	Facts or preferences the assistant carries forward across sessions. It should be inspectable and controllable. It is different from simply keeping an old session.
Standing instructions	Rules or preferences that apply repeatedly, such as global, organisation, project, or folder instructions.
State spine	The whole persistence stack that lets today's run build on yesterday: sessions, projects, memory, instructions, files, or user-owned state.
Human gate	A control that keeps a person in the loop at the right risk boundary. The gate can be a per-action approval, a safety-screened auto mode, a policy rule, or an escalation.
Approval mode	How often the agent pauses for permission. Products expose different labels. Cowork currently offers Manual, Auto, and Skip.
Scheduled task	Work that starts on a clock or another supported trigger. A true cloud schedule does not need your laptop awake unless the task depends on a bridged local tool.
Custody	Who holds your data and deliverables, on whose machines, under whose retention and access rules.
Metered usage	The plan or compute budget consumed by agent runs. Long, tool-heavy, unattended work usually costs more than a short chat. In Cowork, Auto mode currently uses more of this allowance than Manual or Skip because each action receives an additional safety check.

Where this came from

The dates matter because the mechanical layer of this course is moving unusually fast.

Before 2026. Web agents already existed in pieces. ChatGPT had scheduled tasks, deep research, and an agent mode with its own computer. Claude had cloud coding sessions. The important idea – delegated work that survives your next chat turn – was already real.

July 2026. The pieces became easier to reach from the everyday assistant. Claude expanded Cowork onto web/mobile cloud sessions, while OpenAI shipped ChatGPT Work as a first-class work mode beside chat. Sessions, files, connectors, schedules, approvals, and artifact production began to look less like separate tools and more like one work surface.

August 12. Anthropic made the Claude in Chrome side panel a Cowork session, tightening the connection between browser work and the broader Cowork task history.

August 25. Cowork gained the same semantic memory used by Claude chat for cloud sessions. Memory became inspectable topic by topic, and editable or deletable. That means "saved sessions" and "memory" must now be taught as different things.

August 26. Cowork gained a separate built-in browser in Claude Desktop. It can navigate pages, read, click, type, and fill forms. On the same day, Claude in Chrome became generally available across paid Claude plans and gained autonomous browser actions with safety screening. The two browser paths now serve different jobs: Claude's own browser for delegated web work. Your Chrome profile for work on the page and accounts already in front of you.

These changes are why this edition no longer teaches a clean "web = remote, desktop = local" split. Current Cowork supports cloud-only work, cloud work with a desktop bridge, and local execution. The lasting lesson is to inspect agent-loop location, tool-execution location, custody, and gate separately.

Why this happened, and what it lets you do that you could not before

The web did not suddenly learn to "do work" in July. The important change was assembly. Capabilities that had lived in separate menus and specialist tools were brought into one daily surface, then August added memory, richer browser reach, and hybrid execution.

Six practical changes matter to a beginner:

Delegated work has a home beside chat. You can think in chat, then hand off a multi-step assignment without changing your mental universe. The surface looks familiar even though the execution model is different.
Cloud sessions survive the device. If the agent loop runs remotely, closing the tab or laptop does not end the run. You can reopen the same session from another surface.
Persistence is layered, not one blob called memory. Sessions remember what happened. Projects group durable work. Semantic memory carries selected facts across cloud sessions. Standing instructions express how you want the system to behave.
The agent has several ways to reach the world. A connector is usually best when an API exists. A browser fills gaps where the work lives behind pages and forms. A desktop bridge can lend selected local reach. Full computer use is a more powerful, higher-risk last resort taught later.
Autonomy is configurable. Modern agent surfaces do not have one universal "approval prompt." You choose or inherit a gate policy. Cowork's current Manual, Auto, and Skip modes make the trade visible: interruption versus autonomy versus risk.
Scheduling turns a good workflow into a recurring worker. But scheduling does not repair a bad workflow. It only repeats it more reliably, which is why this course makes you walk the work before you schedule it.

There is also a business consequence. The same persistence that makes these products convenient creates switching cost. Your sessions, memories, projects, plugins, and files become useful precisely because they accumulate. The safest response is not to reject persistence. It is to separate working continuity from system-of-record custody. Use the vendor's spine for active work. Put finished work and portable instructions in places you control.

And there is a security consequence. The more ways the agent can read and act, the more carefully you must design the trust boundary. A connector can expose email. A browser can read an untrusted page and act in an authenticated session. A desktop bridge can expose selected local files. The correct question is never only, "Can the agent do this?" It is also, "What can it read, what can it change, and what stops it when the content is hostile?"

In simple terms

The gift is not "AI got smarter overnight." The gift is that a capable worker, its files, its tools, its memory, its schedule, and its gate now sit together. The cost is that more of your work can also sit together in somebody else's system. Use the convenience, but keep custody deliberate. And remember: autonomy multiplies the quality of your workflow. It does not replace it.

The mindset shift, in one picture

caution

Facts checked: 31 August 2026. Cowork changed materially on August 12, 25, and 26: Chrome became a Cowork surface, cloud Cowork gained shared memory, and Cowork gained a built-in browser through Claude Desktop. Rollouts, plan access, permission defaults, and button names still change quickly. Treat every mechanical detail as a snapshot and verify the live product pages before depending on it.

What this course covers

Part	Topic	What you learn
1	The Shift	Chat versus delegated work, cloud versus local execution, desktop bridges, and the six-part harness lens
2	The Surface	Sessions, Projects, memory, instructions, file custody, connectors, browsers, and approval modes
3	Working Unwatched	Discovering a workflow, briefing it, reviewing the plan, and scheduling only proven work
4	Choosing, and the Open Path	Cloud-only, cloud + bridge, local desktop, coding agents, open paths, and the practical limits of each

Two ways to read this course. First time: read Why this happened below, then Parts 1 – 3 in order, then Projects 1 – 3. That is about 2 to 2½ hours of careful beginner reading, and it makes you an agent user with nothing installed. Second read: Part 4, the deeper notes, and Projects 4 – 6, once you have a week of real sessions behind you.

What to remember, and what to look up. Remember the architecture. Look up the mechanics. Remember: chat and delegation are different. Agent-loop location and tool-execution location are separate questions. Persistence has layers. Every file has a custody tier. Structured connectors beat screen-driving when available. Higher-risk work needs a tighter human gate. And every agent product can be read through the same six parts. Look up: plan tiers, run limits, model names, permission labels, browser availability, connector actions, and rollout status. Those can age between editions.

One boundary, stated up front. This course teaches the surface and the delegation loop. It does not teach the runtime decision: where proven, unattended work should live long-term, what travels in a move, and how trust is re-earned. That is Leaving the Laptop's subject, at the end of this section. This course is the front door. Read that one before you depend on anything behind it.

Part 1: The Shift

1. Same address, two different things

Open claude.ai or chatgpt.com today, and the chat box and the agent sit at the same address. On ChatGPT the split is right there on screen: Chat mode and Work mode, side by side in one app. (Codex remains a separate desktop experience. It is not selectable as a mode on web or mobile, although supported desktop Codex sessions can be opened from the mobile Remote tab.) They are not the same thing, and telling them apart is the first skill of this course.

The chat box is the conversation you know from Foundations. It waits for you every turn. You type, it answers, it waits again. It cannot start on a schedule. It cannot react to an event. It cannot continue after you close the tab. None of that is a missing feature: it is what a conversation is. The chat box will never run work without you, and it does not need to. It is where you think, draft, and design.

The agent surface sits next to it. You give it an assignment, not a message. It makes a plan, uses tools, works through steps, and produces a deliverable. It pauses only where a decision needs you. And it keeps working when you stop watching.

Here is a simple test, and it is worth carrying for the rest of your career, because every company will blur this line in their marketing:

If I stop typing, does the work stop?

Chat box: yes. Agent surface: no. That single question separates the two at any address, from any company, this year and after.

The deeper version of the same idea, once you want it: a plain chat turn is synchronous. It runs while you wait, then stops and waits for your next turn. An agent run is delegated. Once you start it, it keeps moving toward an outcome. It can run later. It can watch for a change. It does not need your next turn to continue. That is the real line, and it will survive future changes to buttons and menus. The "stop typing" test is just the everyday way to feel it.

One caution, so the test does not mislead you. You often start a delegated run from the chat box, in plain words. "Every Monday, summarise these emails." The words go in the chat. But what you set up is a delegated task, not a normal reply. So watch what the work does, not only where you typed it.

One more thing did not change in July 2026, and it matters: the chat box kept its job. Designing a task, drafting a brief, testing an idea by hand: that is chat work, and it is where every assignment in this course begins. The agent surface did not replace the chat box. It moved in next door.

In simple terms

One window, two rooms. In the first room, nothing happens until you speak. In the second room, a worker keeps working after you leave. This course is about the second room. You will keep using the first room to prepare what you hand over.

Check yourself

A colleague says: "I already use claude.ai every day, so I already use agents." Correct them in two sentences.

Show answer

They use the chat box: work that stops the moment they stop typing, which means they are still doing the starting, every turn, by hand. The agent surface is the product next to it: assign it work, and it plans, acts, and continues after the tab is closed. Daily chat use is real skill. It is not agent use.

2. The remote session: the tab is a window, not the runtime

The original version of this course taught a simple split: the agent is either on your machine or on the vendor's servers. That is still a useful first picture, but it is no longer enough.

Use two axes instead.

Axis 1: where does the agent loop run?

Cloud session: planning, tool selection, code execution, and task state run on vendor infrastructure.
Local session: the agent loop runs on your own machine.

Axis 2: where does the tool execute?

A cloud session may call a cloud connector, a vendor-hosted search tool, or – through a bridge – a browser or selected file tool on your computer. The loop can be remote while a particular action is local.

That gives you three common runtime patterns:

Pattern	Agent loop	Tools	What happens if your laptop closes?
Cloud-only	Vendor cloud	Cloud files, connectors, web tools	The run keeps going.
Cloud + desktop bridge	Vendor cloud	Cloud tools plus selected browser/local tools through desktop	The cloud run can continue, but bridged tools disappear when the required desktop component goes offline.
Local	Your machine	Local files/apps/tools	The run depends on your machine staying available.

A Cowork session in the cloud runs its agent loop and code execution on Anthropic's servers. Sessions and files live with your Claude account and can be reopened across supported surfaces. If the cloud session needs a connected local folder or certain browser/computer capabilities, it can call them through Claude Desktop while the required desktop component is available and permitted.

That bridge does not turn the cloud session into a local session. If the desktop goes offline, the cloud session still exists and can continue with cloud-reachable tools, but it loses the bridged reach. And if a cloud session opens a local file through the bridge, the contents are processed in the cloud. That distinction matters for custody and regulated workloads.

Cowork access and feature rollout vary by plan and organisation policy. Treat the live help pages as the source of truth for availability.

ChatGPT Work now makes the same two-axis distinction concrete. Work started on web or mobile runs in OpenAI's cloud and cloud Work conversations can continue across supported web, mobile, and desktop surfaces. In the desktop app, Work can also use local folders and desktop apps when you grant permission. Local Work conversations stay on that computer rather than syncing as cloud Work, and local files and outputs remain on that computer unless you explicitly move or share them.

OpenAI also exposes Work Cloud and Work Local as separate enterprise controls. An administrator can enable Work Local without Work Cloud, allowing members to work locally in the desktop app while preventing them from starting cloud tasks. That is a clean cross-vendor example of this course's rule: ask where the agent loop runs, where each tool executes, and where the files remain.

How to read the picture above now. It shows the two endpoints correctly: local runtime on one side, cloud runtime on the other. August added a bridge between them. So do not replace the picture in your head. Add a cable. A remote worker can sometimes borrow a tool in your house without moving the worker into your house.

This leads to four consequences worth memorising:

Closing a tab is not the same as stopping a cloud run. The tab is a window.
Closing the laptop can remove a bridged tool without killing the cloud session. The runtime and the tool are separate.
A local file can be processed in the cloud. "File came from my laptop" does not imply "file stayed on my laptop."
Scheduling is only device-independent when the workflow itself is device-independent. A schedule that secretly needs your desktop browser is not truly laptop-free.

In simple terms

Ask two questions. Where is the worker? Where is the tool? A worker in the vendor's office may use a tool in the vendor's office, or – through a controlled bridge – a tool in your office. If your office closes, the worker can keep working, but cannot use that borrowed tool.

Check yourself

Ayesha starts a Cowork cloud task that summarises Drive documents and also needs one file in a folder connected through Claude Desktop. Her laptop goes offline halfway through. What continues, and what breaks?

Show answer

The cloud session continues because its agent loop is on Anthropic's servers. The Drive work can continue if Drive is cloud-reachable. The connected local-folder tool becomes unavailable while the desktop bridge is offline. The right diagnosis is not "Cowork stopped". It is "one tool disappeared from an otherwise live cloud session."

3. Two vendors, one shape

Now the reading lens for the rest of the course. Product features keep changing, but serious agent surfaces keep rebuilding the same anatomy.

This book names six parts:

Heartbeat – what starts a run.
Connectors / reach – what the run can read and act on.
Run-until-done loop – how it keeps moving toward an outcome.
State spine – what persists so the next run does not start from zero.
Human gate – where autonomy stops or gets screened.
Body – where the work actually executes.

The image above is a July snapshot of vendor labels. Keep the centre column. Expect the outer columns to drift. Cowork's August changes are a perfect demonstration: its state spine now includes cross-surface semantic memory. Its reach now includes two browser paths. Its gate has multiple modes. And its body can be cloud execution with selected tools bridged through desktop.

A current, product-neutral comparison looks like this:

Part	ChatGPT Work example	Claude Cowork example	What you should learn
Heartbeat	Scheduled Tasks and other supported triggers	Scheduled tasks and on-demand runs	Work can start without another chat turn.
Reach	Plugins/connected apps, cloud browser, and the desktop built-in browser/local tools where available	Connectors, plugins, web tools, built-in browser, Claude in Chrome, optional desktop/local tools	Prefer the most structured, least risky tool that reaches the system.
Run-until-done	Outcome-oriented multi-step work, with Plan mode to gather context, ask questions, and propose a step-by-step approach before execution	Cowork's multi-step task execution and sub-agent coordination	Brief an outcome, inspect the approach, then let the agent work toward the finish line.
State spine	Sessions, Projects, files, memory/instructions where supported	Sessions, Projects, cloud Cowork memory, global/project/folder instructions, files	Persistence has layers. Do not call all of them "memory."
Human gate	Approval prompts and product policy	Manual, Auto, Skip, connector permissions, organisation controls	Autonomy is a control setting, not an all-or-nothing property.
Body	Cloud Work, cloud browser, and desktop execution/local tools where available	Cloud sandbox, optional local session, and bridged desktop/browser tools	Ask where the loop runs and where each tool executes.

Run the lens over any new agent product. Do not begin with its marketing name. Find the six parts. If one is missing, ask how the product compensates. If a part is present but hidden, ask who controls it: you, an admin, or the vendor.

One useful current example is ChatGPT Work Plan mode. It gathers context, asks questions, creates a step-by-step plan, and lets you revise or approve that plan before execution. That is not a seventh part. It is a product implementation of the delegation discipline you will learn in Concept 8.

The comparison image above also captures a useful tension that survives the feature churn. A managed agent surface gives you a great deal of spine for free: saved sessions, sync, permissions, schedules, and tools. The open or local path gives you more control over the runtime and custody, but you must build or operate more of that spine yourself.

Two warnings keep the six-part lens useful.

Same shape does not mean same trust. A connector call and a browser click can reach the same business system but have different permission models, observability, and prompt-injection exposure. A cloud session and a bridged browser may belong to the same Cowork task but have different availability and custody implications.

Same label does not mean same implementation. "Memory," "plugin," "approval," and even "browser" can mean different mechanisms across vendors. Use the name to find the part. Then inspect the implementation.

In simple terms

Cars from different companies still have steering, brakes, power, storage, controls, and a place for the driver. The buttons move. The parts do not. Agent products are becoming the same kind of object: learn the parts, then learn where this vendor put the buttons.

Check yourself

A new agent product launches tomorrow. Its website says: "persistent workspace, autonomous browsing, recurring runs, safe actions, parallel workers." Map those claims to the six parts before you read any review.

Show answer

Persistent workspace → state spine. Autonomous browsing → reach plus body. Recurring runs → heartbeat. Safe actions → human gate/guardrails. Parallel workers → run-until-done loop/body. Then ask what is missing or unclear: where files live, what the browser can see, what approval policy applies, and where the runtime actually executes.

Part 2: The Surface

The shift is behind you. Now inspect what the surface actually gives the worker: persistence, files, reach, and gates. Four concepts. Concept 5 – the three file tiers – is still the custody discipline to memorise. Concept 6 is the largest August update: a connector is no longer the only important way Cowork reaches the outside world.

4. The account spine: sessions and files you did not have to build

The original course used account spine as shorthand for "your saved sessions and files follow you around." Keep that idea, but make it more precise. In 2026, persistent context is a stack, not one thing called memory.

Use these layers:

Layer	The question it answers	Typical lifetime
Session history	What happened in this particular task?	One workstream or task history
Project	What belongs to this continuing body of work?	Weeks, months, or longer
Semantic memory	What relevant facts/preferences should carry across cloud sessions?	Cross-session until edited, reset, or disabled
Standing instructions	How should the assistant generally behave here?	Until you or an admin changes them
User-owned context file	What do I want portable, inspectable, and vendor-neutral?	As long as you maintain the file

The important August change is semantic memory in Cowork. Claude's cloud Cowork tasks now use the same memory as Claude chat. What Claude remembers from chat can be available to a cloud Cowork task, and what matters in Cowork can carry back to chat. Users can inspect memory by topic and edit or delete it. Project memory remains scoped to the project. Local Cowork sessions do not use the same cloud memory mechanism.

That immediately fixes a common beginner mistake: an old session is not memory. A Project is not memory either. A global instruction saying "write concise executive summaries" is not memory. They all persist, but they persist for different reasons.

For current Cowork, think of the state spine as:

Sessions → Projects → cloud memory → instructions → files.

Sessions preserve the task history and outputs.
Projects group related tasks with their own files, links, instructions, and project memory.
Cloud memory is shared with Claude chat where enabled and can be reviewed topic by topic.
Global instructions apply across Cowork sessions. Desktop local folders can also have folder instructions.
Files remain part of the working state, but their custody still depends on which tier they occupy.

Do not replace this stack with a magic CLAUDE.md story. A markdown profile can be an excellent portable user-owned context file, but native Cowork memory and instructions are first-class product mechanisms now. Use the file because you want portability and explicit versioning, not because Cowork lacks memory.

ChatGPT Work likewise benefits from a layered state model: cloud-synced sessions and files, Projects for continuing work, saved instructions, and ChatGPT memory where enabled. The product mechanics differ, but the discipline is the same: know whether a fact lives in this session, this Project, cross-session memory, or an explicit instruction you control.

The convenience has a price: custody and dependency. Vendor-managed memory, projects, sessions, plugins, and files are useful because they accumulate. That also makes the account sticky. So keep two kinds of state:

Operational state may live in the vendor spine while work is active.
Critical state should have a portable source of truth: your files, records, repo, or another system you control.

Three habits keep the spine clean. Name sessions like work products. Keep one workstream per session or Project. Put durable instructions in the right layer instead of repeating them in every prompt. And periodically inspect memory/instructions for stale assumptions – persistence makes old mistakes durable too.

In simple terms

Think of a workplace. A session is today's meeting notes. A Project is the client room. Memory is what your colleague has learned about how you work. Instructions are the standing office rules. Your own context file is the copy of the important rules you keep in your briefcase. All five help continuity, but they are not the same thing.

Check yourself

You want Claude to remember that a client prefers one-page updates, but only inside that client's work. Where should the rule live: global instruction, cross-session personal memory, Project context, or one old session?

Show answer

Project context/instructions are the cleanest home because the preference belongs to that client's work, not every client and not merely one old session. The lesson is scope: persistent information should live in the narrowest layer that reliably applies.

5. The three file tiers: where does the deliverable actually live?

This is the signature concept of this course. Think of every file your agent touches as living in one of three tiers. It is a model, not a law of physics, but it holds up in practice, and it turns a fuzzy question into a sharp one. For every deliverable you produce, you make one decision: which tier does it land in?

Tier 1: the task filesystem. While a remote session works, it uses a temporary working space on the vendor's servers: a scratch area for drafts, intermediate computations, and half-built files. It is cleaned up when the work is done, and its exact retention rules vary by vendor, so never treat it as storage. Tier 1 is clear about what it is. It is never the home of anything you need tomorrow.

Tier 2: platform storage. Files saved permanently to your account on the vendor's platform. They survive the task, the tab, and the week. This is the account spine from Concept 4, applied to files, and it is the natural default: work lands here unless you send it somewhere. Tier 2 is safe. Tier 2 is also the vendor's custody, in the vendor's format, behind the vendor's login.

Tier 3: the exit. The file leaves the platform and lands in a place you control. A connector save to your Drive. An email or a Slack post. A direct download to your own machine. A write to a local folder. A commit to a repo. There are many doors, and the door does not matter. What matters is the destination: Tier 3 is the only tier where the deliverable enters your system of record, the place your firm, your client, or your own future self will actually look for it.

The discipline, in one line, and it is the line to memorise from this whole course:

Finished work exits the platform. Everything else may stay.

Read the tiers as a risk ladder and the line explains itself. A deliverable that exists only in tier 1 is already lost: the wipe is not a bug, it is the tier's definition. A deliverable that exists only in tier 2 is safe today and hostage tomorrow: safe because it survives, hostage because it survives only there, in someone else's custody, reachable only through someone else's login. A deliverable in tier 3 is yours: in your Drive's version history, your firm's matter folder, your repo, governed by your retention rules, findable by your colleagues, and still there if the vendor's product changes shape next quarter.

A Cowork cloud session works in temporary remote execution space (tier 1), keeps task/session outputs in your Claude account or Project where applicable (tier 2), and can push finished work into systems you control (tier 3) through connectors, downloads, or – when a desktop bridge is deliberately connected – a write to an allowed local folder. One custody nuance matters: if a cloud session opens a local file through Claude Desktop, the file may have started on your machine, but its contents are processed in the cloud. The final local destination can still be tier 3. The processing path was not local-only.

The same three tiers. Tier 1 is the isolated working environment a Work task uses while it runs, with its own file system, spun up just for the job. Its exact implementation is managed by OpenAI and is not part of the interface you control. Tier 2 is the finished files it makes: the docs, sheets, decks, dashboards, and Sites, kept with your cloud-synced session and Projects. Tier 3 is the exit: the finished file leaves the platform into a place you control. On this browser surface the main automated exit is a connector save through the Plugin Directory, to Drive, Gmail, or Slack. A download is the manual exit, and where a desktop bridge is connected it can add a local write. One note in OpenAI's favour here: Sites can publish a finished web app or dashboard to a shareable URL. That is genuinely useful. But read it through Concept 5. A Site hosted on the platform is still tier 2 with a public door, not tier 3 in your own custody. The exact keep-and-export rules are weeks old, so verify against the live docs. The three-tier structure underneath will not change, and it is the part to learn.

A worked example. Ayesha runs her monthly invoicing for a client. The draft numbers live in tier 1: the agent's scratch math, the temporary CSV. They live and die there, and that is correct. Nobody audits scratch paper. The invoice template she will reuse next month, so she saves it to tier 2: platform storage, attached to a session she will reopen in thirty days. The finished invoice PDF goes to tier 3, twice: saved to the firm's Drive folder, and emailed to the client through the mail connector. Why twice, and why tier 3 at all? Because one day someone will ask, "where is the March invoice?" An auditor, a partner, or Ayesha herself in November. And the answer must be the firm's records, not "somewhere in my Cowork account." The system of record is the firm's. Tier 3 is the only tier that reaches it.

End every deliverable-producing brief with one instruction, and the tier decision takes care of itself:

End by listing every file you created and where each one landed:
temporary working space, platform storage, or a system I control (connector save, download, local write, or repo commit).

That one line turns an invisible default into a visible decision, and Project 2 makes you run it on real work.

In simple terms

Three places a paper can be. On the worker's scratch pad: thrown away at the end of the day. In the worker's own drawer: safe, but in their desk, not yours. In your filing cabinet: yours, where your rules apply and your people can find it. The rule is simple: anything finished goes into your filing cabinet. Drafts can stay on the pad or in the drawer.

Going deeper: this discipline has a future

Two courses ahead will hand you back this concept, grown up. Loop Engineering will teach the state spine: the memory a loop keeps between runs, and where that memory lives is exactly a tier decision. Leaving the Laptop will teach the suitcase test: what travels when you move homes, and its rule, the repo holds the truth, is tier 3 wearing engineering clothes. And Project 6 in this course, the exit drill, is the beginner's version of that course's vanishing-home drill. Learn the tier habit now, on invoices and briefs, and the engineering versions will feel obvious when you reach them.

Check yourself

A lawyer builds a comparison memo in a web session and shares the platform link with the client. Name the two things wrong with stopping there.

Show answer

First, custody: the memo exists only in tier 2, the vendor's platform, outside the firm's matter folder and retention system, so the firm's own record of the engagement has a hole in it. Second, access: the link's sharing and permission story is the platform's, not the firm's, and the firm cannot govern what it does not hold. The fix is tier 3: save the memo into the document management system, then share from there, under the firm's rules. The platform link was a window. The client was handed a window instead of a document.

6. Connectors on the web: reach and exit door in one

A connector is still the cleanest way for an agent to reach many business systems. It gives the agent structured, permission-scoped access to a service instead of making it imitate a human clicking through screens.

But a connector is no longer the whole reach story. Current Cowork makes four paths worth distinguishing:

Reach path	Best for	Main advantage	Main risk / limit
Connector	Gmail, Drive, Slack, DocuSign, CRMs, databases with supported integrations	Structured permissions and actions	Scope can still be too broad. External content can carry prompt injection
Built-in Cowork browser	Portals, forms, dashboards, sites with no connector	Claude gets its own separate browser for delegated web work	Requires Claude Desktop online. Authenticated browsing raises action risk
Claude in Chrome	The page already in front of you, using your existing Chrome sessions/logins	Works in your own browser context	It inherits the sensitivity of your logged-in browser session
Computer use / desktop tools	Apps with no connector or browser-friendly interface	Reaches the GUI directly	Highest operational risk. Teach and trust separately in the desktop course

The default rule is simple:

Use the most structured tool that can do the job. Connector before browser. Browser before full computer use.

That is not because connectors are magically safe. It is because structure gives you clearer permissions, clearer actions, and less ambiguity than screen-driving.

The built-in browser. Cowork now has a browser inside Claude Desktop. It is separate from your normal browser. Claude can open sites, read pages, click, type, and fill forms. It is meant for delegated web tasks such as pulling numbers from a dashboard or working through a vendor portal that has no connector. From web or mobile, a Cowork cloud session can steer that browser while the desktop app is open and online.

The built-in browser starts separate from your personal browser state. You can sign in as needed, and current Cowork can import selected site logins from supported browsers. That choice creates a new trust boundary: anything you sign into inside Claude's browser can be available to future Cowork sessions on that computer. Treat browser login state as a permission, not a convenience toggle.

Claude in Chrome. This is different. It works in your Chrome browser, on the page and accounts you already have open. Since August 12, the Chrome side panel is part of Cowork's session story, and the task can be continued across supported Claude surfaces. Use it when the work is "help me with this page." Use the built-in browser when the work is "go handle this website task for me."

ChatGPT now has three browser paths worth distinguishing across Work and Codex.

Work cloud browser. Work can use its own browser on a remote computer. It can read pages, click, enter information into forms, and work on supported public or signed-in sites. Because the browser is remote, a delegated task can continue after you close your computer or put away your phone. It pauses when it needs your input, sign-in, or confirmation. Its signed-in sessions are separate from the accounts already open on your device.

Desktop built-in browser. In the ChatGPT desktop app, Work or Codex can open an in-app browser with its own browser state and multiple tabs. You can watch the page, sign in directly in the browser, and work side by side with the agent. On desktop, Work can also use approved local files and desktop apps where your plan and workspace allow it.

Codex Chrome extension. OpenAI directs you to this path when the task needs your existing Chrome profile, cookies, signed-in session, open tabs, or Chrome extensions. This is the closest OpenAI analogue to the "use my existing browser context" role that Claude in Chrome serves. It belongs to Codex rather than Work, so do not confuse it with Work's remote cloud browser.

So the same routing rule applies on both vendors: use a connector or plugin when a structured interface covers the job. Use a browser when the work lives behind pages, forms, or portals. If the task needs your existing browser identity and tabs, choose the product path designed for that context. Treat authenticated browser control as a larger trust boundary than reading a public page.

The security model changes when the agent can both read and act

Prompt injection matters most when two conditions meet:

the agent can read content outside your trusted boundary, and
the agent can take a consequential action.

A malicious instruction hidden in a webpage, email, document, or connector result can try to redirect the agent. Safety classifiers and action screening reduce the risk. They do not erase it.

Anthropic currently goes further for Claude's browser surfaces: completing instructions found inside emails or web content is a prohibited action regardless of permission mode. That policy reinforces a durable security rule. Your brief is authority. External content is evidence. Instructions embedded inside external content are untrusted input, not a new boss for the agent.

So carry five rules:

Start with trusted sites and low-stakes accounts.
Do not casually import or reuse logins for banking, medical, identity, or other highly sensitive systems.
Use Manual approval for unfamiliar sites, new plugins/connectors, or actions that send, spend, delete, publish, or change important records.
Give each workflow only the connectors and browser reach it actually needs.
Use connectors as both an entry and an exit. If the finished report belongs in Drive or the client system, make that destination part of the brief.

A permission label is not a formality. Read is not send, draft is not publish, and view is not edit. If a mail connector can read threads, that does not automatically mean it should be allowed to send messages as you. If a CRM connector can view records, write access is a separate increase in blast radius. Grant the smallest scope that completes the workflow, and widen it only when the workflow proves that it needs more.

This is also where plugins enter the web story. Current Claude plugins can bundle skills, connectors, and sub-agents, and hooks/sub-agents run in Cowork. That makes a plugin more than a shortcut menu: it can be a role-specific mini-harness. Install only trusted plugins, because a plugin can expand both what Claude knows how to do and what systems it can reach.

In simple terms

A connector is a service entrance with a badge reader. A browser is the front door and hallways. Computer use is giving the worker your mouse and keyboard. Use the narrowest entrance that reaches the room you need. And whenever the worker can read untrusted material and act in a real account, tighten the gate.

Check yourself

You need monthly numbers from a vendor portal. There is no connector. The portal account can download invoices but cannot send money or change bank details. Which reach path would you try, and what approval mode would you start with?

Show answer

A browser is appropriate because the work lives in a portal with no connector. Start with Manual approval while you learn the site and the agent's behaviour, even though the account is relatively constrained. After repeated clean runs you may decide a safer automatic mode is appropriate, but the first run earns close supervision.

7. The gate in your pocket

The original beginner story was simple: the agent works, then an approval reaches your phone. Keep the human gate idea. Update the implementation.

A modern agent surface can have several gate layers at once:

the connector's own permission scope,
an organisation policy,
a per-task approval mode,
safety screening on actions,
explicit approval for a particularly destructive action,
an escalation to your phone or another surface.

Cowork currently makes the autonomy choice unusually visible with three modes:

Cowork mode	What it means	Good beginner use
Manual	Claude pauses for actions that need approval. You allow or deny them.	New workflows, unfamiliar sites/tools, sensitive or hard-to-reverse actions
Auto	Claude keeps moving and screens each action for safety, blocking or escalating ones it judges unsafe. The Cowork side panel currently starts in this mode by default, and the extra safety checks consume more usage than Manual or Skip.	Proven, bounded workflows where interruptions are costly but consequences remain manageable
Skip	Claude does not pause for ordinary approvals and does not apply the Auto action check.	Rarely appropriate for beginners. Only tightly trusted, bounded work

Anthropic explicitly warns that no automated defence is perfect. For work with real consequences – money, messages sent as you, important files – stay close or use Manual. Current Cowork also retains explicit protection for permanent file deletion.

The current Cowork side panel defaults to Automatically approve. That is a product default, not this course's recommendation for every first run. For unfamiliar tools, authenticated sites, new plugins, or high-consequence actions, switch to Manual while you learn the workflow. Once a bounded workflow earns trust, Auto can reduce interruptions, with the trade-off that its additional action checks consume more of your usage allowance.

This changes the mental model from "Where will the approval pop up?" to two better questions:

What is allowed to happen without me?
What mechanism stops or screens the action before it counts?

The phone still matters. Cloud sessions can notify you when they finish or need input, so the gate can travel with you. But the phone is an escalation surface, not the definition of the gate.

Match the gate to blast radius

A practical autonomy ladder:

Read and summarise – low consequence. Automatic execution is often reasonable after permissions are understood.
Draft but do not send – medium consequence. The output is reviewable before it leaves the system.
Write to reversible records – higher consequence. Use a stronger gate until the workflow is proven.
Send, publish, purchase, delete, or change critical data – high consequence. Use Manual or another explicit human control unless you have a mature governed workflow.

The important habit is not "always click approve." It is choose the gate deliberately before the run. If you decide autonomy only when the prompt appears, you are designing the safety system too late.

Before you trust an unattended workflow, ring the gate on purpose. Create one harmless step that should require your input, start the task, walk away from the computer, and confirm that the request reaches a surface you actually watch. Then deny or approve it and confirm the run responds correctly. An escalation path you have never tested is only an assumption.

In simple terms

The gate is not one doorbell. It is the whole rule for when the worker must stop, when a safety check may clear the action automatically, and when the worker is allowed to keep moving. For important work, choose the rule before you hand over the keys.

Check yourself

You have a tested weekly research workflow that reads public sites and writes a draft into a test folder. You also have a new workflow that will send renewal notices to customers. Which should get more autonomy?

Show answer

The tested research workflow can reasonably use more automation because its inputs and consequences are bounded and reversible. The customer-notice workflow should begin with Manual approval or an equivalent explicit send gate because an incorrect action leaves the system as you and is harder to undo.

Part 3: Working Unwatched

You know the surface. Now the skill that makes it useful: handing over work you will not watch. This part teaches the delegation loop: the four steps every later course in this book assumes you know. Then it teaches the capability this surface was built for: work that starts on a clock, with no device of yours online.

8. The delegation loop: brief, plan, approve, review

The product can work without you. That makes the quality of the handoff more important, not less.

A useful beginner mistake is to think the answer is a longer prompt. Often the better first move is workflow discovery.

If you do not yet know how to specify the workflow, start with the frustration:

"Every Monday I spend an hour checking three places and still miss something. Interview me until you understand what I am trying to accomplish, what sources matter, what I never want changed, and what a good finished brief looks like. Then propose the workflow before doing it."

That move, drawn from experienced Cowork users, is powerful because the agent helps you discover the procedure instead of waiting for you to already be an automation designer.

Once the workflow is understood, use the four-step delegation loop:

Brief. State the outcome, audience, sources, constraints, permissions, file destinations, and definition of done.
Plan. Ask the agent to show how it intends to get there before consequential work begins.
Approve or redirect. Fix the plan while changes are cheap. Set the permission mode to match the stakes.
Review. Inspect the finished deliverable, the actions that mattered, and where every file landed.

Plan-first is an instruction, not a guarantee of Manual mode

In the current Cowork side panel, Manual mode does not automatically create a plan for you to approve before starting. Claude may ask clarifying questions, then begins work and asks before individual actions. If you want the Concept 8 safety intercept, put it in the brief: "Show me your plan first and wait for my approval before taking consequential actions."

ChatGPT Work's current Plan mode makes this discipline explicit. It gathers context, asks questions, produces a step-by-step plan, and waits for you to revise or approve the approach before work begins. The button may change. The durable practice is the same: inspect intent before expensive or irreversible execution.

The image remains right: Brief → Plan → Approve/redirect → Review. What changed in August is that "Approve" can now mean more than clicking a per-action prompt. It also means choosing an autonomy mode, approving a site or connector, or deciding that a workflow is mature enough to run with safety-screened automatic actions.

A brief for work you will not watch

Use this template in plain language:

Outcome: What finished thing should exist?
Audience/use: Who will use it, and for what decision?
Sources: Which files, Projects, connectors, sites, or accounts may the agent use?
Boundaries: What must it not read, change, send, purchase, delete, or publish?
Method constraints: Required format, calculations, citations, date window, or business rules.
Escalation: What uncertainty should stop the run and come back to you?
Destination: Where should the final deliverable live – name the tier-3 system explicitly.
Done: What observable conditions prove the task is complete?

Then add one line beginners routinely omit:

If the necessary evidence is missing, say what is missing and stop rather than inventing it.

That line matters even more in unattended work because a confident hallucination can otherwise travel through several steps before you see it.

Review the plan, not every click

If the workflow has twenty steps, you do not want to supervise twenty clicks forever. Your leverage is earlier: check whether the plan is pointed at the right sources, the right accounts, the right output, and the right gate. A bad plan executed perfectly is still a bad run.

Use four checks when you read the plan:

Scope: Is it touching only the work and data you named, or has the job quietly grown?
Order: Does it verify before it acts, or is it about to change something before the evidence is settled?
Reach: Is it proposing a connector, browser account, send, publish, write, or delete action that you did not intend?
Assumptions: Is it silently deciding the audience, format, business rule, or missing fact for you?

If one of those is wrong, redirect the plan with one sentence. Fixing direction before execution is cheaper than cleaning up a flawless run of the wrong plan.

For a new browser or connector workflow, stay close the first few times. Watch where it reads, what it tries to write, and which approvals appear. Trust should be earned by repeated bounded runs, not assumed from the product name.

In simple terms

Do not tell a capable colleague every keystroke. First explain the job. If you are not sure what the job really is, let the colleague interview you. Then review the plan before the expensive or irreversible work begins. That is management, and delegation to an agent follows the same logic.

Check yourself

You know you hate preparing a weekly client update, but you cannot yet describe the workflow cleanly. What is the best first prompt: a 40-line guessed procedure, or a short description of the frustration plus a request for an interview?

Show answer

Start with the frustration and ask the agent to interview you. The goal is to discover the real workflow, its sources, exceptions, and definition of done. Once those are clear, turn them into a durable brief and test it manually before scheduling anything.

9. Scheduled tasks with no device online

A schedule is the heartbeat: something other than your next chat turn starts the work.

The four useful heartbeat patterns remain:

Once – run later one time.
On a schedule – run on a clock.
On an event – run when a supported event occurs.
Monitor / watch – check repeatedly and surface a result only when a condition becomes true.

OpenAI now gives the event heartbeat a concrete implementation in ChatGPT Work. Eligible users can create event-triggered tasks from supported Gmail messages, Slack channel messages, or GitHub pull request activity. Before enabling the task, the user reviews three explicit pieces: Trigger, Condition, and Prompt. That is the heartbeat made visible as a product control rather than only a concept.

The important 2026 lesson is not the labels. It is the runtime requirement:

A schedule is truly device-independent only if every required tool is also reachable without your device.

A Cowork scheduled task runs in the cloud and can use the capabilities available to regular Cowork tasks, including connected tools, skills, and installed plugins. But local file access and some browser/desktop capabilities still depend on a desktop bridge. If your scheduled Monday brief needs a file that exists only in a folder on your sleeping laptop, you have rebuilt the laptop as a hidden dependency.

The four answers before you schedule

Write these down:

What starts the run? Clock, event, or watch condition.
What does it touch? Every connector, Project/file source, website, plugin, and destination.
Can it reach all of that with your devices off? If not, either move the source to a cloud-reachable system or accept that the schedule is bridge-dependent.
How will you know it succeeded? A finished file, a dated report, a notification, or another observable signal.

Then add two safety questions:

What may it do without approval? Set the gate before the first unattended run.
What happens on the empty or ambiguous case? "No new items" must be a valid result, not an invitation to invent work.

Ran is not the same as worked

A scheduler can tell you that a run started or completed. That does not prove the output was correct, complete, or delivered to the right place. Give every recurring workflow an observable success signal, for example: the number of items processed, the dated file created, the tier-3 destination used, or an explicit "no new items" result.

If an expected output is missing, silence is ambiguous. First check whether the run is waiting for an approval or other input. Then check usage limits, permissions, connector/browser availability, and the destination. Do not rewrite the prompt or switch products until you know whether the workflow failed to start, failed to reach a tool, paused at a gate, or ran and produced the wrong result.

Start with reporting, then graduate carefully

For beginners, the safest scheduled agent is one that reads, analyses, and reports. It creates leverage without quietly changing the world while you sleep. Once a workflow has a history of clean runs, a clear checker, bounded permissions, and reversible actions, later courses can take you toward schedules that act.

This is a teaching ceiling, not a claim that the products cannot take actions. They can. The point is that capability and readiness are different things.

Walk it before you schedule it

Run the workflow by hand at least twice. Inspect the sources, plan, permissions, output, empty case, and tier-3 destination. Only then attach a heartbeat.

Scheduling a workflow is like photocopying it into the future. If it contains a mistake, the schedule does not dilute the mistake. It reproduces it.

In simple terms

A schedule is an alarm clock for a worker. The alarm can ring in the cloud, but if the worker needs a key that is locked inside your sleeping laptop, the job still cannot finish. Put recurring workflows on sources and tools that are awake when the schedule is.

Check yourself

Your weekly brief reads Gmail and Drive through cloud connectors, writes a PDF to Drive, and sends you a completion notification. Does it need your laptop online? What if you add "also read C:\Clients\notes.md through the desktop bridge"?

Show answer

The first version is cloud-reachable end to end and can run with your laptop off. The second version introduces a desktop dependency: the cloud task may start, but the bridged local file is unavailable when the required desktop component is offline. Either move that source to a cloud-reachable system or accept that the schedule is no longer fully device-independent.

Part 4: Choosing, and the Open Path

You can now direct an agent on this surface, land its files in the right tier, and put a reporting task on a clock. Three practical questions remain. When is this surface the wrong choice? What does the open-source path look like, with no vendor cloud at all? And what can this surface never do for you, no matter how good the products get? This part answers all three, and then hands you to the rest of the section.

10. Web, desktop, or terminal: pick by what the work touches

The old router had two easy buckets: cloud documents/connectors → web. Local files/apps → desktop. August turned the middle into a spectrum.

Keep the original deciding question:

What does the work touch?

Then add two more:

Must it run while my device is off?
Who is allowed to hold/process the data?

The published diagram is still a good first router. Use the updated table below when the edge case matters:

Work pattern	Best starting surface	Why
One-off thinking, drafting, designing a workflow	Chat	No need to delegate a run that has no multi-step execution.
Cloud files + connectors. Must keep working while device is off	Cloud-only Cowork / Work	No local dependency. Strongest unattended continuity.
Cloud session needs one approved local folder or browser session while you are online	Cloud + desktop bridge	Keeps cloud session continuity while borrowing selected local tools.
Work is fundamentally local files/apps and local custody matters	Local desktop agent	The machine and data are the execution surface.
Work is a repository, terminal, tests, CI, or codebase	Coding agent / terminal	The repo and toolchain are the system of record.
Work needs a website with no connector	Browser path	Built-in browser for delegated web work. Claude in Chrome for the page/accounts already open.
Regulated or contractually restricted data	Stop and verify	Product availability is not permission. Obtain the organisation's written compliance answer for the exact surface and configuration.

Two current compliance examples show why the last row cannot be hand-waved. Anthropic now exposes Cowork activity to Enterprise compliance tooling, including Compliance API coverage, but that does not mean every regulated workload is automatically approved. As of this fact check, Anthropic states that Cowork is not covered under its BAA for HIPAA use. OpenAI makes the same point from another angle: event-triggered Work tasks in ChatGPT for Healthcare are not covered under a BAA and must not be used to transmit, store, or process PHI. Governance is surface- and configuration-specific.

The row stands as written: when the work genuinely needs the identifiers, product availability is not permission, and the written answer comes before the upload. What the row leaves out is a branch. Ask what the task actually needs: the identifiers, or only the pattern. A spending-trend analysis rarely needs customer names. Remove them, check what is left against your organisation's standard, and you may not be routing regulated data at all. Removing what the task does not need is a route, not an evasion. The Exam Guide (v1.0, July 2026) states the safeguard as redacting or anonymising regulated identifiers before use, so the analysis can proceed without exposing protected data. Both answers are correct at opposite ends of one fork: strip and re-check when the task needs only the pattern, confirm the route in writing when the specifics are the substance of the work. Governance, Risk & Responsible Use owns the full treatment, including the two ways stripping identifiers quietly fails.

A bridge is a convenience, not a custody loophole

If a cloud Cowork session reads a local file through Claude Desktop, the file came from your machine but its contents are processed in Anthropic's cloud. So do not route sensitive work to "local file" and assume local custody. The first routing question is where the agent loop and processing occur, not where the source file was sitting five seconds earlier.

Browser choice is also routing

Built-in Cowork browser: "Go handle this website task for me." Separate browser state, delegated work, desktop component required.
Claude in Chrome: "Work with me on this page/account I already have open." Uses your Chrome context.
Connector: "Use the service's structured interface." Prefer this when it covers the workflow.

The route can change inside one assignment. A cloud session may read Drive through a connector, visit a portal through a bridged browser, then save the final file back to Drive. That is fine. What matters is that you know which boundary each step crosses.

In simple terms

Do not choose a tool because it is newer. Choose it because it fits where the work lives, whether the work must continue without your device, and who is allowed to process the data. A bridge can reach into your computer. It does not magically move the cloud into your computer.

Check yourself

Route three tasks: (a) a weekly Slack/Drive brief while you travel. (b) reorganising 200 local client files. (c) pulling invoice PDFs from a vendor portal with no connector while your desktop is online.

Show answer

(a) Cloud-only agent surface: all sources are cloud-reachable and the task must survive your device being off. (b) Local desktop agent if the job is fundamentally on-device and custody matters. (c) A browser path – such as Cowork's built-in browser through the desktop bridge – fits the portal task. Start with a tight gate because it is authenticated browser work.

11. The open path: no vendor cloud

A note about this course's structure, and the trade it requires.

Every co-worker course in this book pairs a vendor tool with an open-source twin: Claude Code with OpenCode, Cowork with OpenWork. This course broke that pattern. Its tabs pair two closed products: Cowork on the web and ChatGPT Work. That was on purpose. Two rivals shipped the same shape within days of each other. One did it as a remote session, the other as a mode inside its chat app. That is the evidence for this book's thesis, and you needed to see it side by side. But a pattern broken in silence becomes a bias. So here is the question the missing open-source tab would have answered: can you have this surface with no vendor cloud at all?

Yes, with work. Two open paths exist today. Some of the words in them (self-hosted, cron, GitHub Actions) are the engineer's. You do not need them yet, only that these paths exist.

OpenWork, remote and shared workspaces. OpenWork is the open-source desktop co-worker you will meet properly in the next course. It can connect to a worker running somewhere other than your laptop. That can be a self-hosted OpenWork worker you reach by URL and access token. Or it can be your organisation's shared cloud workers, connected in one step. This is this course's core idea: the machine doing the work is not the machine you are looking at. But here it runs on infrastructure you or your organisation control. The window is yours. So is the building.

OpenCode, with a scheduler you own. For repo-attached work, the open answer to Concept 9 is a coding agent fired by your own clock: cron on a machine you run, or a scheduled GitHub Actions job. No vendor cloud, no plan tiers, no staged rollout. The full pattern is Loop Engineering's to teach. Know today that it exists and is not exotic.

Now the trade, said once and plainly. It is the same trade every open-versus-managed choice in this book comes down to. The companies sell you a spine. The open path makes you build one. On the vendor surface, everything is handed to you, working, on day one: sessions, files, sync, the phone gate, the scheduler. But it lives in their custody, in their format, at their price, under their rules. On the open path, every one of those is yours to set up, run, and fix. In exchange you get the two things no vendor sells. First, custody: your data on machines you control. Second, choice: which model sees your prompts, and the freedom to switch. Neither side of the trade is the noble one. Concept 10's regulated-data row is a case where custody wins outright. A solo consultant shipping briefs by Friday is a case where the working spine wins outright. Most readers will hold both answers at once, one per task. By now that should sound familiar.

In simple terms

The vendor's surface is a furnished office: desk, drawers, doorbell, all working on day one, inside their building. The open path is an empty room you furnish yourself: more work, but your building, your rules, and your choice of who sees what. Neither is simply better. Sensitive work often needs your building. Fast work often needs the furnished office. You are allowed to rent one and own one at the same time.

Check yourself

An NGO asks you to set up weekly donor-report automation. Their data policy forbids donor records on third-party consumer platforms, but the team has no engineer. Which path does the policy force, what does the team lose, and what practical warning do you owe them before they commit?

Show answer

The policy forces the open path: donor records cannot land in tiers 1 and 2 of a consumer vendor platform, and those tiers are the vendor surface's foundation. What they lose is the free spine, sync, the phone gate, the managed scheduler, which someone must now build and keep running. The warning: "This path trades a subscription fee for an operator. Someone here must own the setup, the updates, and the morning it breaks. And with no engineer on staff, that cost, not the software, is the real decision." Custody is not free. It is paid for in operations.

12. What this surface cannot do, and where this goes

End at the practical boundary.

The web surface still does not make weak work good. Memory can preserve a bad assumption. A browser can execute a bad plan faster. Auto approval can reduce interruptions without making the underlying judgment correct. Scheduling can repeat an error every Monday. Your durable controls remain the brief, the plan review, the permission boundary, the checker, and the exit.

The vendor still owns important parts of the harness. On a managed surface you do not fully control the runtime, sandbox implementation, lifecycle, model routing, or enforcement machinery. Cowork plugins can now bring hooks and sub-agents into Cowork, which is more powerful than the July course described, but that is still different from owning a local coding harness where you write and run the guardrails yourself.

A cloud-to-desktop bridge is not the same as a local runtime. It can lend a remote task selected access to local folders, browsers, connectors, or computer-use capabilities while the desktop side is available. It does not remove cloud processing, and it does not make a bridge-dependent schedule device-independent.

Browser agents have a security ceiling. The same thing that makes them useful – reading arbitrary pages while authenticated and taking actions – creates a prompt-injection path. Safety screening reduces risk. It cannot make untrusted web content equivalent to trusted structured data.

Persistent context creates both leverage and lock-in. Sessions, Projects, memory, instructions, plugins, and browser login state can make the assistant dramatically easier to use over time. Keep critical instructions and finished work portable so leaving a vendor is inconvenient, not catastrophic.

And some work still belongs elsewhere:

Cowork & OpenWork goes deeper into desktop/local work, folders, browser/computer use, live artifacts, trust levers, and regulated workloads.
Agentic Coding teaches repo-attached work and coding agents.
Spec-Driven Development turns a good brief into a checkable specification.
Loop Engineering builds recurring loops with explicit stopping conditions, state, and checkers.
Harness Engineering and Trusting the Checker move from rented controls to controls you design and evaluate.
Leaving the Laptop makes the runtime decision explicit: what belongs on a managed surface, a managed runtime, your infrastructure, or a fully owned stack.

The closing thought is now four sentences instead of three. Chat is where you often design. The agent surface is where delegated work runs. The agent loop and its tools may live in different places. The discipline is to know the shape, the boundaries, and the custody at every step.

In simple terms

The product became more capable in August, not less dependent on judgment. You now have more memory, more browser reach, more plugins, and more autonomy. That makes the old disciplines – clear briefs, explicit boundaries, checks, and your own system of record – more valuable, not less.

Check yourself

A colleague says, "Cowork can now use local files and browsers from a cloud session, so the difference between cloud and local no longer matters." Correct them.

Show answer

The bridge makes the boundary more flexible, not irrelevant. A cloud session still processes work in the vendor cloud, and bridged local tools still depend on the required desktop component being available. Runtime location, tool location, and custody remain separate decisions.

Where this book uses this surface (dogfooding)

The current answer, as of 31 August 2026: this book's own unattended loops do not run on this surface, and the reason is Concept 10 doing its job. The book is a repository, its loops are repo-attached, and its review gate lives beside its merge gate in CI, exactly as Leaving the Laptop's dogfooding section explains. What the work touches, a repo, routed it to a different surface.

Where this surface does earn its keep in this book's production is twofold. First, the chat-side design work before every loop: drafting briefs, testing reviewer prompts, running one beat by hand. Second, connector-and-document tasks around the book. That second kind is the reporting work Concept 9 called this course's ceiling. That split is not a compromise. It is the division of labour this course taught: design in the chat box, run on the surface the work touches. You are reading the output of the arrangement right now.

🚀 Projects

Six projects, easy to hard. Use real but low-stakes work. Do not practise on banking, medical, identity, privileged, or other regulated data simply because a tool can reach it.

📱 Project 1 · 20 min · The worker/tool-location test. Difficulty: easy · Uses: Concept 2. Do. Start a cloud task using only a cloud-reachable source. Close the tab and reopen the same task from another surface. Then, if you have Claude Desktop available, try a harmless task that uses one connected local folder or browser and observe what changes when the desktop side goes offline. Done when you can explain, without using product names, the difference between agent-loop location and tool-execution location.

🗂️ Project 2 · 30 min · The three-tier audit. Difficulty: easy · Uses: Concepts 4 – 6 and 8. Do. Run one task that produces a real deliverable. Name the state layer holding the work (session/Project/memory/instructions) and the file tier of every output. Done when the final deliverable exists in tier 3 and you can identify which useful context would be lost if the vendor account disappeared.

🔔 Project 3 · 30 min · The gate lab. Difficulty: easy – medium · Uses: Concept 7. Do. Use a harmless test folder or draft-only connector action. First run the workflow in Manual mode or the closest equivalent and note every interruption. If your plan/product offers a safety-screened automatic mode, rerun the same bounded workflow and compare what changed. Do not use Skip mode for purchases, sending, deletion, or sensitive accounts. Done when you can state what was allowed automatically, what still escalated, and which mode you would choose for the real workflow.

⏰ Project 4 · 30 min, plus one week · The first cloud schedule. Difficulty: medium · Uses: Concept 9. Do. Build a Monday brief from cloud-reachable sources only. Write the six answers first: trigger, touch, device independence, success signal, autonomy, empty case. Walk the workflow twice before scheduling. Done when it has fired at least twice with your computer off and each run left a verifiable success signal in tier 3.

🔁 Project 5 · 45 min · One task, two harnesses. Difficulty: medium · Optional: requires access to both products · Uses: Concept 3. Do. Give the same low-stakes assignment to Cowork and ChatGPT Work. Map what you observe to heartbeat, reach, loop, spine, gate, and body. Ignore superficial button differences. Done when your one-page comparison names at least one implementation difference in each of three parts and still shows the same six-part shape underneath.

🧳 Project 6 · 60 min · The portability drill. Difficulty: capstone · Uses: Concepts 4, 5, 10, and 11. Do. Pretend your preferred vendor disappears tomorrow. Using only tier-3 files and user-owned context, reconstruct one working workflow: instructions, source locations, definition of done, and last deliverable. Done when you have a written list of what you could not reconstruct. That list is your lock-in exposure and your next portability backlog.

Appendices: the later courses, on the web

The rest of the General Agents section goes deeper into desktop and coding surfaces. This course remains browser-first, but August 2026 erased several old categorical boundaries. A cloud Cowork task can now borrow selected desktop tools. Plugins can carry sub-agents and hooks in Cowork. Browser work can happen in Claude's own browser or your Chrome context. So these appendices no longer ask simply, "Can the web do this?"

They ask three more precise questions:

Can a browser-only cloud session do it with nothing installed?
Can a cloud session do it only when a desktop bridge is available?
Does the job require a genuinely local or user-owned runtime?

One rule still holds. On the managed surface, you rent most of the harness. In the later engineering courses, you increasingly build, inspect, and own it. A managed Cowork plugin hook is real automation, but it is not the same as owning the local runtime, repository, hook runner, sandbox policy, and CI system yourself.

The picture shows the earlier, more sealed managed-harness model

Current Cowork exposes more shaping power than the original artwork suggests. You can influence all five verbs through combinations of instructions, permissions, approval modes, plugins, hooks, sub-agents, and review policies. The boundary that still matters is ownership and reproducibility: on the managed surface, the vendor owns the underlying runtime and safety substrate. In the later engineering courses, you own and can reproduce far more of those mechanisms directly.

Read every "does not transfer" row below with that distinction in mind. The boundary is no longer "browser versus desktop" in one clean line. The durable boundary is managed harness versus owned harness, cloud custody versus local custody, and optional bridge versus required runtime.

Appendix A · Agentic Coding, on the web

The Agentic Coding course teaches Claude Code and OpenCode through the filesystem, terminal, repositories, and coding-agent harnesses. Its deepest subject is not syntax. It is context engineering plus enforceable execution: deciding what the agent sees, what it may change, how its work is checked, and how a failure becomes a permanent improvement.

A great deal of the discipline transfers to Cowork. Some of the packaging now transfers too. What still does not transfer is ownership of the coding runtime.

Transfers cleanly:

That course teaches	On this surface
Plan before action	Concept 8. Ask for the plan while changes are cheap, then choose the gate appropriate to the work.
Persistent project instructions	Concept 4. Use Project instructions, Global/Folder Instructions where supported, and user-owned portable context for durable rules.
Context discipline	Start a fresh session when the old conversation is noise. Continue when the history is genuinely part of the job. Memory is useful, not a substitute for deliberate context.
MCP / connected systems	Concept 6. Managed connectors are the web-friendly version of giving an agent structured access to real systems.
Skills	Packaged know-how transfers directly. Skills can be reused across tasks without turning every prompt into a procedure manual.
Prompt-injection discipline	Identical principle, broader attack surface. Untrusted content is still untrusted whether it arrives through a connector, browser, document, or repo.

Now transfers partly through Cowork plugins:

Current Cowork plugins can package skills, connectors, sub-agents, and hooks. That matters because the July version of this course drew too hard a line: it treated sub-agents and hooks as things that existed only after you left Cowork. That is no longer accurate.

But do not confuse managed extension points with owning the coding harness.

Capability	Cowork plugin version	Coding-agent version
Sub-agents	A plugin can package specialist workers that Cowork orchestrates inside Anthropic's managed environment.	You design workers around your repo, tools, models, context, and orchestration code.
Hooks	Plugins can attach hooks that run in Cowork at supported lifecycle points.	Your hook code runs in the harness you operate and can be tied directly to local tools, repo state, tests, CI, and your own enforcement policy.
Reusable role bundles	A plugin can combine know-how and access into a role.	A coding harness can combine roles with filesystem rules, commands, branches, tests, sandboxes, and deployment logic you own.

That is an important upgrade, but the ownership line remains.

Still belongs to the coding surface:

That course teaches	Why it remains different
A real local repo and terminal	A cloud Cowork session can borrow selected local-file or browser access through Desktop, but that is not the same as attaching a coding agent to your repository and shell as its native execution environment.
Git-native isolation and recovery	Worktrees, branches, commits, diffs, and git-backed rollback require the repository to be the execution surface.
User-owned command/runtime policy	In a coding harness you decide how commands run, which paths are writable, what tools exist, and what process surrounds every change. Cowork still supplies the underlying managed runtime.
Model/runtime routing you control	Coding tools and APIs can expose model selection, headless runs, CI integration, and other runtime decisions that a managed knowledge-work surface may abstract away.
Repo-enforced verification	Tests, linters, schema validators, type checks, and CI gates can make “done” machine-verifiable before a change lands.

When the repository becomes the work surface. The boundary is no longer “Cowork has no hooks or sub-agents.” It is managed Cowork extension versus user-owned coding harness. Cowork plugins can now carry surprisingly sophisticated orchestration. Move to the coding course when the repository, terminal, git history, tests, CI, or your own enforcement layer must become part of the agent's native operating environment.

Appendix B · Cowork and OpenWork, on the web

The Cowork & OpenWork course is no longer simply "the local version of this course." Cowork itself now spans cloud sessions, local sessions, web/mobile steering, Chrome, a built-in desktop browser, connected folders, plugins, sub-agents, and optional computer use. The cleaner distinction is browser-first managed Cowork versus desktop/local capability and custody.

Transfers cleanly to browser-first Cowork:

That course teaches	Here, on the managed cloud surface
Outcome-based delegation	Concept 8. Same managerial handoff: outcome, constraints, plan, gate, review.
Projects and persistent context	Concept 4. Sessions, Projects, semantic memory, instructions, and files now form a real cloud state spine.
Connectors and Skills	Concept 6. First-class managed capabilities, no local setup required for cloud-reachable services.
Plugins / role bundles	Current Cowork plugins can bundle skills, connectors, and sub-agents. Hooks/sub-agents execute in Cowork.
Scheduled work	Concept 9. Cloud schedules run without your device when the workflow is cloud-reachable.
Approval/autonomy modes	Concept 7. Manual, Auto, and Skip expose the autonomy ladder directly.

Transfers only with a desktop bridge:

Desktop capability	What changes when the agent loop stays in the cloud
Connected local folders	A cloud session can read/write only folders explicitly connected through Claude Desktop, while the bridge is available. The data is processed in the cloud.
Built-in Cowork browser	The browser lives in Claude Desktop. Web/mobile can steer it while the desktop app is online.
Claude in Chrome	Uses the user's Chrome context and logins. It is a Cowork surface, but depends on the browser extension/desktop connection rather than being a pure cloud connector.
Local connectors/plugins	They can expand Cowork's reach but create a device dependency and a larger trust boundary.
Computer use	Cloud Cowork can call into desktop computer use where supported, but the screen becomes a high-risk execution surface. Teach it in the desktop course.

Still genuinely different in the desktop/local course:

That course teaches	Why it remains a different subject
Local execution and local custody	A local session runs the agent loop on your machine. A cloud session using a local file through a bridge still processes that content in the cloud.
Live artifacts	Current Cowork live artifacts are a desktop capability, useful for persistent interactive dashboards. They are not a reason to bloat this browser-first core.
Backup/recovery through your filesystem	Time Machine, git, Drive history, or other local/system-of-record recovery belongs to the environment that owns the files, not to platform session history.
OpenWork / own-model path	The open-source twin is about controlling the runtime, model path, and custody – different goals from merely reaching a local folder from a cloud task.
Regulated-workload configuration	Governance depends on the exact surface and configuration. Enterprise observability does not automatically make a surface approved for every regulated data class.

Carry Concept 10's compliance rule into the desktop course: observability and enterprise controls do not by themselves approve a regulated workload. Verify the exact surface, configuration, and contractual coverage before use.

Where browser-first Cowork ends. Cowork now looks less like two products called "web" and "desktop" and more like one managed agent system with several execution and tool surfaces. That is precisely why the two-axis model from Concept 2 matters. The desktop course is still essential, but its job is no longer to introduce everything local. Its job is to teach the trust, custody, browser/computer-use, live-artifact, and local-runtime consequences that a browser-first course should not bury beginners under.

Appendix C · Loop Engineering, on the web

The Loop Engineering course teaches a system that starts work, carries state forward, checks the result, retries or stops under explicit rules, and escalates when a person is needed. This course borrowed its six-part lens because the shape is already visible on managed web agents.

The August Cowork changes strengthen the overlap. Scheduled tasks, persistent cloud memory, Projects, plugins, sub-agents, and hooks mean Cowork can host workflows that are much closer to “real loops” than the July version of this appendix admitted.

What transfers well:

Loop concept	Managed-web version
Heartbeat	Concept 9: once, on a schedule, or another supported trigger/watch pattern.
Persistent state	Sessions, Projects, cloud memory, instructions, files, and plugin-managed state where applicable.
Reusable procedure	Skills and plugins keep recurring work from starting from zero.
Worker decomposition	Cowork plugins can include sub-agents, so a managed task can divide work among specialist workers.
Lifecycle automation	Cowork plugin hooks can run at supported points in the managed workflow.
Human escalation	Concept 7: permission modes, blocked actions, and explicit review points provide the human gate.

What still makes Loop Engineering a separate course:

A managed surface gives you a loop. Loop Engineering teaches you to own the loop's contract.

Loop Engineering capability	Why the engineering surface is still different
Explicit stopping and retry logic	You can write the exact cap, no-progress rule, and failure path rather than inheriting the product's run-until-done behaviour.
A spine you own	A repo-owned `progress.md`, rules file, database, or other explicit state can be inspected, versioned, migrated, and deterministically read by every run. Native memory remains vendor-managed state.
Independent maker/checker design	Cowork can orchestrate sub-agents, including review roles, but an engineered loop lets you define the checker as a separate controlled component with its own rubric, model, inputs, and acceptance contract.
Isolation	Worktrees, containers, branches, locks, and per-run sandboxes are engineering controls around shared state.
Re-runnable orchestration	Scripts/workflows can reproduce the same sequence headlessly in CI or another runtime you operate.
Portable unattended runtime	The same loop definition can move from a laptop to CI, a managed runtime, or your own infrastructure with its state and checks explicit.

When the managed loop is not enough. Cowork is no longer merely a scheduler that reports. With plugins, sub-agents, hooks, and persistent state it can run meaningful managed loops. The promotion point is now more precise: move to Loop Engineering when you need the heartbeat, state, checker, stopping rules, isolation, and recovery behaviour to be explicit assets you own rather than capabilities you inherit.

Appendix D · Harness Engineering, on the web

The Harness Engineering course teaches the layer around the model that turns intelligence into dependable work: rules, tools, isolation, verification, recovery, and escalation.

This course began with a simple phrase: on the web, you rent a finished harness. Keep that phrase, but update what “rent” means. Modern Cowork is not a sealed box with only prompts and connectors. Plugins can add skills, connectors, sub-agents, and hooks. Approval modes expose part of the autonomy policy. Enterprise controls can add administration and observability. You can customise more of the rented harness than you could in July.

The deeper distinction is who owns the enforcement substrate.

Harness verb	What you can shape on managed Cowork	What remains vendor-owned
Constrain	Connector/site permissions, folder access, approval mode, plugin behaviour, task boundaries	Core sandbox, platform policy, supported hook points, underlying tool/runtime enforcement
Inform	Global/Project/Folder instructions, memory, Skills, plugin resources, files and connectors	Context assembly rules and product internals you cannot fully inspect or replace
Verify	Review steps, specialist sub-agents, plugin hooks, explicit check instructions	The underlying runtime, product safety classifiers, and enforcement semantics
Correct	Retry/redirection, versioned tier-3 files, workflow/plugin changes	Platform rollback and lifecycle behaviour beyond the controls the product exposes
Escalate	Manual/Auto/Skip choice, approval prompts, blocked-action escalation, notifications	Which events exist, how platform safety decisions are implemented, and infrastructure-level logs unless exposed by the plan/admin tools

That table is more accurate than saying “you cannot add a hook on the web.” You sometimes can. What you cannot do is treat a managed hook as identical to a guardrail enforced in a runtime you control.

When Harness Engineering becomes necessary:

A rule must be enforced even if the model's instructions say otherwise.
A path, network destination, branch, command, or data class must be fenced by infrastructure you control.
Verification must run as code and block acceptance automatically.
Every failure must ratchet into a version-controlled rule, test, hook, or policy.
You need to inspect or replace the runtime component implementing the control.
Governance requires evidence from your own logs, CI, policy engine, or deployment environment rather than only the vendor's product surface.

Cowork plugins can be a valuable intermediate step. They teach the same idea: move repeated behaviour out of ad-hoc prompting and into a reusable harness layer. Harness Engineering simply keeps going until the critical control is yours, inspectable, testable, and portable.

Rented enforcement versus owned enforcement. The updated boundary is not “web equals prompts, desktop equals harness.” Managed Cowork now exposes real harness extension points. The boundary is rented enforcement versus owned enforcement. Use the managed surface while its controls match the consequence of the work. Build your own harness when a control must be provable on your terms.

Appendix E · Trusting the Checker, on the web

The Trusting the Checker course asks the question the loop and harness courses kept postponing: how do you know the checker is any good? When an agent grades its own work, or a reviewer agent returns PASS, that verdict is a model's opinion. This course teaches evals: the discipline of testing the tester, so "the checker said PASS" becomes a number you can defend. It builds a golden set of case files, runs them headlessly, calibrates the judge against your own grading, and gates every change on the result.

This is the deepest measurement course in the section. You can prototype cases, repeated checks, and reviewer roles on a managed agent surface, but the course's dependable form is a version-controlled case set, a repeatable runner, calibrated judges, baselines, and CI. Its way of seeing measurement transfers immediately. Its full engineering discipline belongs in a runtime you can reproduce and inspect.

Transfers, as judgment (this is the real value on the web):

That course teaches	On the web, it becomes a habit of mind
An agent is a distribution, not a function (grade the rate, not the run)	The most useful idea to carry. When your scheduled report runs well once, that is one run, not proof. If it does something important, check it across several runs before you trust it. This needs no tools, only the discipline to not trust a single green result.
The judge is a model too (a PASS is an opinion that needs calibration)	When a web agent says "done" or "I checked it," remember that is a claim, not a proof. Cowork can now include review sub-agents or hooks through plugins, but those checkers still need evidence before you trust them. Spot-check early, and move important checks into an eval suite you can calibrate.
Read which failed before how many (a rate hides severity)	When you review a batch of agent work, the wrong three items matter more than a high overall count. This reading habit works on any output, from any surface.
The bar is a decision, not a discovery	Deciding how good is good enough, and for which tasks, is your call as the person directing the agent. That judgment sits with you on any surface. It is Concept 8's plan-review discipline, applied to results.
Demos are the weakest evidence	"It worked when I tried it" is one run, on a task chosen because it works, watched by someone hoping it does. That caution protects you when you decide whether to trust a web agent with something that matters.

Does not transfer in the course's engineered form:

That course teaches	What the managed surface is missing
The golden set (a version-controlled folder of case files)	Cases are JSON files in a repo, reviewed and dated like code. A managed web task is not a substitute for a version-controlled eval repository you own, even if a bridged tool can reach local files.
The runner (`claude -p` / `opencode run` in a shell loop with `jq`)	The whole runner is headless command-line execution and shell grading. A managed Cowork task may use code or plugin logic in its environment, but it is not the same as operating your own headless shell runner and eval harness. This is the same wall as every appendix before it.
Calibrating the judge (the blind 20-item protocol, the four-cell table)	You can do the thinking of this by hand, but the course's version measures a model judge you can inspect and swap. A native product checker may be vendor-managed, while plugin review agents are configurable but still need calibration. The course's protocol requires a judge and dataset you can run repeatedly under controlled conditions.
The regression suite and CI gate (re-run on every change, fail below baseline)	This is an eval job wired into CI with a committed baseline. A managed agent can help create or run individual checks, but the reproducible gate belongs in the repo/CI system that owns the release decision.
Drift watching on a schedule (nightly runs, alert on a drop)	The course runs the full suite as a scheduled loop against a baseline. A managed surface can schedule repeated work, but the course's version compares a controlled suite against a committed baseline and alerts on statistically meaningful drift. Keep that baseline in a system you own.
Goodhart's law defences (sealed hold-outs the agent never sees)	Sealed hold-outs require a boundary the system under test cannot inspect. That is easiest to guarantee in a test harness/repository you control rather than in the same managed workspace being evaluated.

When evaluation becomes engineering. You can practise evaluation on the managed surface: build test cases, run repeated trials, add a review sub-agent, and record failures. Trusting the Checker becomes a separate engineering course when those checks must be reproducible, calibrated, version-controlled, and able to block a release automatically. Carry the mindset now – grade a rate, not a demo. Read severity before volume. Calibrate the judge – and move the mechanism into a real eval harness when the consequences justify it.

Appendix F · Leaving the Laptop, on the web

Leaving the Laptop asks the final runtime question: where should a proven workflow live, and who operates it? The August Cowork architecture makes that question more interesting because “cloud” and “desktop” can now cooperate in one task.

Do not classify a workflow by the screen from which you started it. Classify it by four facts:

Where does the agent loop run?
Which tools are required, and where do they execute?
Who must keep a device or service alive?
Who holds and processes the data?

A cloud Cowork session controlled from a laptop is still a cloud session. A cloud Cowork session that borrows a local folder through Desktop is a cloud loop with a device dependency. A local session is different again. That two-axis model is the bridge into Leaving the Laptop.

How the web course maps to the runtime journey:

Pattern	What it means	Good fit
Interactive cloud session	Vendor runs the agent loop. You start/review it from web, desktop, or mobile	One-off delegated knowledge work
Cloud scheduled task	Vendor starts and runs the loop on a clock. All required tools must also be cloud-reachable for true device independence	Personal recurring reports and bounded workflows
Cloud loop + desktop bridge	Vendor runs the loop, but one or more tools depend on Claude Desktop / browser / local folders being online	Convenient hybrid work, but not a fully device-independent schedule
Local agent session	Agent loop and local tools run on your machine	Local custody, local apps/files, workstation-centric workflows
Managed runtime / CI	A platform operates a headless workflow defined through code/configuration	Team workflows, repo automation, service integration
Your infrastructure	You operate the runtime and harness	Strongest control, highest operational responsibility

What travels when you move:

Your best assets are not vendor buttons. They are the outcome definition, portable instructions, source-of-truth locations, schema, checks, failure rules, permission boundaries, and examples of good output. Keep those explicit and a move becomes a re-platforming exercise rather than rediscovering the workflow from memory.

What does not automatically travel:

Native memory, session history, Projects, plugin implementations, browser login state, approval labels, and vendor-specific schedule mechanics. Treat these as conveniences around the workflow, not the workflow's only copy.

The runtime decision. The web surface does not have one clean ceiling anymore. It has several runtime patterns, including a hybrid bridge. Leaving the Laptop teaches you to stop asking “web or desktop?” and make the operational decision instead: what must stay awake, where does state live, what is the blast radius, and who is responsible when the loop fails at 3 a.m.?

Appendix G · The harness war, industry-wide

The six appendices above look inward, mapping this course to later courses. This last one looks outward. The durable market signal is not a particular model ranking. It is that major AI vendors increasingly compete on the whole agent system: memory, tools, browser/computer reach, schedules, plugins, approvals, runtime, identity, and governance.

That is the harness war.

Industry snapshot – facts checked: 31 August 2026. This appendix is intentionally less product-specific than earlier editions because names and bundles age faster than the architecture. Verify every live product before making a purchase or curriculum decision.

Three fronts are useful:

Front 1 · The everyday work surface – rent a finished harness.

This is the layer you learned in this course. OpenAI's ChatGPT Work and Anthropic's Claude Cowork are direct examples. Google, Microsoft, and Meta are also pushing agentic capabilities into the consumer and productivity surfaces where their users already work. The competitive advantage here is not just model quality. It is distribution + state + tools + permissioned action.

Use the six-part lens when any new product appears:

Heartbeat: can it start later, recur, or react to a supported event?
Reach: which connectors, browsers, local tools, or computer surfaces can it use?
Loop: how long can it work, and who decides it is done?
Spine: what persists – sessions, Projects, memory, instructions, files?
Gate: what needs a person, and what safety policy runs automatically?
Body: where does the agent loop run, and where do its tools execute?

Front 2 · The managed agent platform – rent the runtime.

Cloud and enterprise platforms increasingly provide agent runtimes, identity, connectors, observability, policy, memory/state services, and deployment controls. Here the customer is not merely delegating a task in a UI. A team is defining an agent or workflow that other people or systems may depend on.

The differentiator shifts from convenience to governance and operations: identity, least privilege, auditability, isolation, evaluation, deployment, cost control, and failure handling.

Front 3 · The open/self-hosted stack – build and operate the harness.

Open-weight model families such as Qwen, DeepSeek, and Llama can be components in systems you host yourself. But “open weights” is not the same thing as “you own the whole agent.” Full control arrives only when you also own or choose the runtime, tool layer, state, sandbox, policy, checker, and infrastructure around the model.

That distinction matters for custody. Calling an open model through somebody else's hosted API is still hosted processing. Self-hosting changes the custody equation, but it also makes operations your problem.

The larger lesson. The market will keep renaming the pieces. One company will call it a task, another a routine, another an agent, another a plugin. Do not chase the noun. Ask the six questions. Then ask the two new August questions from Concept 2: where does the loop run, and where does each tool execute?

If you can answer those eight questions, you can read a new agent product before the marketing page has finished loading. That is why this course teaches the shape rather than a screenshot.

Sources & further reading

Inside this book

Skills & Connectors – the structured reach layer this course assumes.
Cowork & OpenWork – desktop/local deepening: folders, browsers, computer use, trust levers, custody, and open alternatives.
Agentic Coding – repo-attached agent work and user-owned runtime controls.
Loop Engineering – the heartbeat, state, checker, and stopping-condition system behind safe recurring work.
Leaving the Laptop – the full runtime/custody decision after a workflow proves itself.

Claude Cowork – current primary sources

Get started with Claude Cowork – availability, cloud tasks, Projects, Manual/Auto/Skip, Global/Folder Instructions, plugins, and scheduling.
Claude Cowork architecture overview – cloud versus local sessions and the desktop bridge for local files/browser tools.
Use Claude Cowork on web, desktop, and mobile – which capabilities require desktop and how one cloud session moves across surfaces.
Claude's memory works everywhere, and you decide what's in it (Aug. 25, 2026) – shared Chat/Cowork memory and editable memory topics.
Use Claude's chat search and memory to build on previous context – cloud Cowork memory, Project memory, controls, and local-session limitation.
Claude gets its own browser in Cowork (Aug. 26, 2026) – built-in browser launch and the distinction from Claude in Chrome.
Use the built-in browser in Claude Cowork – login handling, web/mobile steering, browser choice, and safety.
Claude in Chrome is generally available (Aug. 26, 2026) – autonomous browser actions and action safety screening.
Claude in Chrome permissions guide – current Cowork side-panel approval defaults and Auto-mode usage trade-off.
Use Claude Cowork safely – prompt injection, trust boundaries, approval guidance, and computer-use cautions.
Use plugins in Claude – plugins as skills + connectors + sub-agents. Hooks/sub-agents in Cowork.
Schedule recurring tasks in Claude Cowork – cloud schedules and capability inheritance.
Compliance API coverage extends to Claude Cowork and Claude Code – enterprise session visibility. Updated Aug. 26 to GA coverage for Cowork/Claude Code surfaces listed there.
HIPAA-ready Enterprise plans and Covered Models under a BAA – why surface-specific compliance verification matters. Cowork is not currently BAA-covered.

ChatGPT Work – live product references

ChatGPT is now a partner for your most ambitious work – Work launch and product framing.
ChatGPT Work and Codex – Work/Codex relationship, cloud versus local Work, local-file custody, and surface-specific availability.
ChatGPT Work – current product overview, built-in desktop browser, and Plan mode.
Using cloud browser in ChatGPT – remote browser behaviour for delegated Work tasks.
Using the built-in browser in the ChatGPT desktop app – desktop browser state, tabs, sign-in, website access, and when to use the Codex Chrome extension for an existing Chrome profile.
Scheduled Tasks in ChatGPT – current scheduling mechanics, including event-triggered Gmail, Slack, and GitHub tasks and the Trigger/Condition/Prompt model.
HIPAA eligible products and functionality – why event-triggered Work tasks in ChatGPT for Healthcare are not BAA-covered and must not process PHI.
Plugins in ChatGPT and Codex – connected-app layer.
Skills in ChatGPT – packaged Skills and current access rules.

Open path

OpenWork – open-source Cowork-style desktop alternative powered by OpenCode.

Independent and practitioner reading supplied for this update

TechCrunch, Claude Cowork finally remembers what you told the app in chat – independent coverage of the Aug. 25 memory change.
Vellum, Official Claude Cowork Breakdown – useful feature/competitive framing, but use Anthropic's live docs for current product facts because parts of the article aged immediately around the Aug. 25 – 26 changes.
YouTube, Everything You Need to Know About Claude Cowork, in the Right Order – useful pedagogy for "start with the frustration, then let Cowork interview you" and the agent/delegation mental model.
YouTube, NEW Claude Cowork Update is CRAZY GOOD – practical explanation of the built-in browser, browser-vs-Chrome distinction, and prompt-injection warning. Product facts in this course were checked against Anthropic's primary docs.

Freshness rule. Everything mechanical on this page was checked on 31 August 2026. The lasting concepts are the six-part harness, the two-axis runtime/tool model, the persistence stack, the three file tiers, the reach ladder, the human gate, the delegation loop, and the routing questions. Recheck plan access, model names, rollout status, permission defaults, connector actions, and browser availability before relying on them.

The one-line summary

Chat is where you converse. The agent surface is where you delegate. A cloud agent can keep working after you leave, may borrow selected tools through a desktop bridge, carries layered state across runs, and should reach the world through the narrowest tool and the tightest gate the job requires.

The habits, in one place

Start with the frustration when the workflow is unclear, then let the agent interview you. Brief the discovered workflow in full. Catch problems at the plan. Prefer connector over browser and browser over full computer use. Match the gate to blast radius. Send finished work to Tier 3. Schedule only workflows you have walked successfully. Ask where the agent loop runs and where each tool executes. Read every new product through the six parts, and take the long-term runtime/custody decision to Leaving the Laptop.

Flashcards Study Aid

Test Your Understanding

Checking access...

📚 Teaching Aid​

Key words in plain English​

Why this happened, and what it lets you do that you could not before​

The mindset shift, in one picture​

What this course covers​

Part 1: The Shift​

1. Same address, two different things​

2. The remote session: the tab is a window, not the runtime​

3. Two vendors, one shape​

Part 2: The Surface​

4. The account spine: sessions and files you did not have to build​

5. The three file tiers: where does the deliverable actually live?​

6. Connectors on the web: reach and exit door in one​

The security model changes when the agent can both read and act​

7. The gate in your pocket​

Match the gate to blast radius​

Part 3: Working Unwatched​

8. The delegation loop: brief, plan, approve, review​

A brief for work you will not watch​

Review the plan, not every click​

9. Scheduled tasks with no device online​

The four answers before you schedule​

Ran is not the same as worked​

Start with reporting, then graduate carefully​

Walk it before you schedule it​

Part 4: Choosing, and the Open Path​

10. Web, desktop, or terminal: pick by what the work touches​

A bridge is a convenience, not a custody loophole​

Browser choice is also routing​

11. The open path: no vendor cloud​

12. What this surface cannot do, and where this goes​

Where this book uses this surface (dogfooding)​

🚀 Projects​

Appendices: the later courses, on the web​

Appendix A · Agentic Coding, on the web​

Appendix B · Cowork and OpenWork, on the web​

Appendix C · Loop Engineering, on the web​

Appendix D · Harness Engineering, on the web​

Appendix E · Trusting the Checker, on the web​

Appendix F · Leaving the Laptop, on the web​

Appendix G · The harness war, industry-wide​

Sources & further reading​

The one-line summary​

The habits, in one place​

Flashcards Study Aid​

Test Your Understanding​

📚 Teaching Aid

Key words in plain English

Why this happened, and what it lets you do that you could not before

The mindset shift, in one picture

What this course covers

Part 1: The Shift

1. Same address, two different things

2. The remote session: the tab is a window, not the runtime

3. Two vendors, one shape

Part 2: The Surface

4. The account spine: sessions and files you did not have to build

5. The three file tiers: where does the deliverable actually live?

6. Connectors on the web: reach and exit door in one

The security model changes when the agent can both read and act

7. The gate in your pocket

Match the gate to blast radius

Part 3: Working Unwatched

8. The delegation loop: brief, plan, approve, review

A brief for work you will not watch

Review the plan, not every click

9. Scheduled tasks with no device online

The four answers before you schedule

Ran is not the same as worked

Start with reporting, then graduate carefully

Walk it before you schedule it

Part 4: Choosing, and the Open Path

10. Web, desktop, or terminal: pick by what the work touches

A bridge is a convenience, not a custody loophole

Browser choice is also routing

11. The open path: no vendor cloud

12. What this surface cannot do, and where this goes

Where this book uses this surface (dogfooding)

🚀 Projects

Appendices: the later courses, on the web

Appendix A · Agentic Coding, on the web

Appendix B · Cowork and OpenWork, on the web

Appendix C · Loop Engineering, on the web

Appendix D · Harness Engineering, on the web

Appendix E · Trusting the Checker, on the web

Appendix F · Leaving the Laptop, on the web

Appendix G · The harness war, industry-wide

Sources & further reading

The one-line summary

The habits, in one place

Flashcards Study Aid

Test Your Understanding