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 chat has a limit. When you stop typing, that conversation stops.
Agents that keep working on their own are not new to the web. ChatGPT could run scheduled tasks from early 2025. It could do deep research on its own while you stepped away. It had an agent mode with its own computer. These were real, and they were powerful. But they were scattered. A task here, a research tool there, an agent mode in a menu. There was no single, clear place for everyday work, with your files, your sessions, and your services all in one flow.
July 2026 fixed that. Two big companies pulled those pieces together into one clear work surface, next to the chat box, at the same web address. On claude.ai, Claude Cowork runs as a remote session on Anthropic's servers. On chatgpt.com, ChatGPT Work is a new mode inside ChatGPT, next to the Chat mode you already know. It runs on OpenAI's GPT-5.6 model. (ChatGPT also has a Codex mode for coders, but on the web and phone you mostly see Chat and Work.)
So July 2026 did not invent browser agents. It made them a first-class place to work. The chat box did not change. It still waits for you, and it always will. What changed is the surface next to it. Start a session there, and it runs on the company's servers. You can close the tab. You can get on a plane. The work keeps going. And when it reaches a choice only you can make, the question comes to your phone.
This course is a tour of that surface. It is also your first lesson in one skill that every later course needs: directing a general agent. You will learn what a remote session is. You will learn where your files really go. You will learn how an approval reaches your phone. You will learn how to hand off work you are not watching. And you will learn how to look at a new agent product and spot the same parts inside it.
Two companies built this at almost the same time. They arrived at the same set of parts. That is strong proof of this book's main idea: the shape, not the tool, is the skill.
There is a bigger story here too, and it is worth naming on your way in. The two companies are no longer racing only on the model. They are also racing on everything wrapped around it: the schedule, the connectors, the memory, the gate. This book calls that wrapper the harness, and that race is a harness war. It used to be fought in code, by engineers. Now it has reached the web. Your seat in that race is simple: you do not build the harness here. You pick the one that fits, and you direct it well. Concept 3 shows you exactly what the two harnesses look like side by side.
You will not install anything. Your Foundations ran in a browser tab. So does this.
Who this course is for. It is for anyone coming from Foundations who wants to direct a real agent with nothing installed. That means knowledge workers first: people whose day is documents, spreadsheets, email, and chat. Lawyers, accountants, marketers, analysts, founders, students. It is also for engineers who want the gentlest first step before the terminal. If you can code, you lose nothing by starting here. If you cannot code, this is exactly where you belong. It is the first course of the General Agents section for that reason. Everyone can take it, on day one, in a browser.
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 90 minutes to read. The full course with Part 4 and the appendices: closer to two hours. The projects add hands-on time on top, including one week for the scheduling exercise, and they are where the learning sticks. Seven appendices follow as reference: six map this course to a later course (read each when you get there), and a final one maps the whole industry. Read them as reference, not in one sitting.
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.mdfile. 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.
Key words in plain English
You will see these words throughout the course. Read this list once now, then return to it whenever a term feels unclear.
| Term | Plain-English meaning |
|---|---|
| Chat box | The conversation that waits for you every turn. It cannot start anything on its own. |
| Agent surface | The product next to the chat box that plans, acts, and runs multi-step work. |
| Remote session | A session that runs on the vendor's servers. Your tab is a window onto it, not the machine running it. |
| Local session | A session that runs on your own machine. It pauses when the machine sleeps. You will meet these in the next courses. |
| Task filesystem | The temporary working space a remote session uses while it works. Treat it as scratch, never permanent: retention and cleanup rules vary by vendor. |
| Platform storage | Files saved permanently to your account on the vendor's platform. They survive the task and the tab. |
| The exit (Tier 3) | Getting a deliverable off the platform into a place you control: a connector save, a download, a local write, or a repo commit. The file enters your system of record. |
| Account spine | Your saved sessions and files, synced across your devices. Memory you did not have to build. |
| Human gate | The point where a person must approve before a risky action continues. On this surface, it arrives on your phone. |
| Scheduled task | Work that starts on a clock, on the vendor's servers, with no device of yours online. |
| Metered usage | A budget of runs or hours per plan. Unattended work on someone else's servers always has one. |
| Custody | Who holds your data: on whose machines it lives, and who can reach it. |
Where this came from
The dates matter here, because this surface is only weeks old, but its roots are older.
Browser agents did not begin in 2026. ChatGPT shipped scheduled tasks in January 2025. It shipped deep research, which browses on its own for many minutes, in February 2025. It shipped an agent mode with its own computer in mid-2025. So the web could already run work on its own well before this course. What it did not have was one clear home for that work. The pieces were spread across menus and tools.
Claude followed its own path to the same place. Anthropic offered cloud coding sessions that ran on its servers with your laptop closed. Useful, but aimed at coders.
Then, in July 2026, both companies pulled the pieces into one place, within days of each other.
Cowork came to the web at claude.ai (beta, Max plan first, more plans to follow). Sessions run on Anthropic's servers. Your sessions and files save to your account. Scheduled tasks fire with no device online.
ChatGPT Work shipped on July 9, 2026. It is not a separate product. It is a new agent mode inside ChatGPT, next to Chat mode. It runs on GPT-5.6. It makes finished files: spreadsheets, slide decks, documents, dashboards, and small web apps. It reaches your services through a renamed Plugin Directory. Its Scheduled Tasks can run once, on a schedule, on an event, or while watching for a change. It is not a new price tier. On web and mobile it comes with eligible paid plans, not Free or Go, and it draws down each plan's agent allowance. (On the ChatGPT desktop app, Chat, Work, and Codex are on every plan, including Free. Codex is a separate view in that desktop app. It is not selectable on web or mobile.) Availability keeps changing, so confirm your access on the live product page.
Two companies, days apart, put an agent next to the chat box. Two different products. One shape. This course teaches the shape.
Why this happened, and what it lets you do that you could not before
Before you learn the surface, it helps to know why it exists. There are two sides to this. One side is what it gives you. The other side is what the companies get back. Read both. When you understand what the company wants, you use the surface with open eyes instead of blind trust. It also explains a rule this course will push on you later.
The gap this closed. Before July 2026, the web could run work on its own. But the pieces were scattered and uneven. A scheduled task lived in one menu. A research tool lived in another. An agent mode lived in a dropdown. Each was powerful on its own. Together they were hard to find and harder to combine. There was no single place where your files, your sessions, your services, and a hands-off run all met. So most people never used any of it. These launches gathered the pieces into one clear surface, at the address people already open every day. The power was there before. What changed is that it became easy to reach and easy to combine.
Four capabilities that July 2026 brought together in one clearer work surface:
- Long-running work in the same everyday surface. A remote session runs on the company's servers, so you can close the tab, shut the laptop, or get on a plane, and the task keeps going. Remote agent runs had existed before. What changed is that Work and Cowork placed them beside ordinary chat, in one general-purpose flow. (Concept 2.)
- Scheduling built into the work surface. A scheduled task starts on a clock or a trigger, with no device of yours online. The Monday brief is done before you sit down. Scheduled tasks existed earlier too. Now they sit next to your projects, files, connectors, and agent runs, instead of in a separate tool. (Concept 9.)
- Work organized around sessions and projects. Your sessions and files stay in your account and follow you across devices. The new surfaces gather related files, instructions, and continuing work into one visible place, so you re-paste your context far less than before. (Concept 4.)
- Many steps across your files and connected services. The agent connects to your services. It plans. It works through many steps for hours. It hands back finished files, not just a chat reply. And it sends the choices that need you to your phone. What is new is that it does all of this without sending you through several separate product modes. (Concepts 5–8.)
Now the other side, because it changes how you should use all of this. The stated goal is your power to get work done. The business goal is reach and lock-in. All through 2026, both companies fought the story that they were selling a chat product in a market that wanted agents. The fastest fix is to put the agent where hundreds of millions of people already are. No install. No new app. No terminal to learn. In one move, chat users become agent users. And saving your sessions, files, and connectors into the company's account does one more thing. It makes leaving costly. This is called a switching cost. The account memory that is so handy is also the thing that makes it hard to walk away.
That is not a reason to be suspicious. It is a reason for one clear habit. The feature that helps you most (a free, working memory) and the feature that helps the company most (your work piling up on their servers) are the same feature. This is why Concept 5 will teach you to push finished work out of the platform and into your own storage. You keep the convenience. You refuse the lock-in. Once you see the company's goal, this habit feels obvious, not paranoid.
And one honest limit. None of this makes the work itself better or safer. A weak instruction now runs on its own, with no one to catch it partway through. And putting code, a browser, and live connectors into one always-on surface makes the reach of a bad run wider. Security reviewers pointed this out about ChatGPT Work in its launch week. The new power is leverage, nothing more. Whether that leverage helps you or hurts you still comes down to your brief, your review, and your judgment. That is why this course puts a discipline next to every new power, instead of selling you the power alone.
Agent power already existed on the web, but it was spread across separate tools and modes. Now it lives together at the web address you already use, in one place made for everyday work, and it keeps working after you leave. That is the gift. The catch is that your work now piles up on the company's servers. That is handy for you and sticky for them. So enjoy the convenience, but send anything finished to your own storage. And remember: this surface makes work run without you. It does not make the work good. That part is still yours.
The mindset shift, in one picture
Facts checked: 21 July 2026. Cowork on web and ChatGPT Work are both weeks old. Rollouts are staged by plan, usage is metered, and names change. This is the fastest-aging page in this book. Check the live product pages before you rely on a limit, a plan tier, or a feature.
What this course covers
| Part | Topic | What you learn |
|---|---|---|
| 1 | The Shift | What changed in July 2026, what a remote session is, and why two vendors arrived at one shape |
| 2 | The Surface | Sessions, the account spine, the three file tiers, connectors without folders, and the gate in your pocket |
| 3 | Working Unwatched | The delegation loop, briefing work you will not watch, and scheduled tasks with no device online |
| 4 | Choosing, and the Open Path | Web or desktop per task, the open-source path with no vendor cloud, and where this course hands off |
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 ninety minutes of 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. Two layers run through this course, and they age very differently. Remember the first. Look up the second. The lasting layer: the chat box waits and always will. A remote session lives in your account, not your tab. Every deliverable lands in one of three tiers, and finished work exits the platform. The human gate must reach a place you actually look. And every agent product, from any vendor, is the same shape wearing different names. The mechanical layer: every plan tier, run limit, button label, and product name below. These are weeks old and change monthly. Treat each one as a pointer to the live docs, not a fact to memorize.
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.
📚 Teaching Aid
For instructors and self-learners. This course teaches one transferable idea: an agent product is made of six parts (heartbeat, connectors, run-until-done loop, state spine, human gate, body), and once you know the parts, any new product is a short look-around, not a new subject. Teach it in three passes. First, the shift: the chat box waits, the agent surface next to it does not (Concepts 1–3). Second, the surface itself: where files live, how connectors reach out, how approvals reach your phone (Concepts 4–7). Third, working unwatched: the delegation loop and scheduled tasks (Concepts 8–9), then choosing a surface by what the work touches (Concepts 10–12). The six projects are the assessment. The single most important habit to leave students with: finished work exits the platform.
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. (On the desktop app there is also a separate Codex view for coders. On the web and phone, you mostly see Chat and Work.) 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, summarize 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.
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
This is the core architecture concept of the course, and everything else in it follows from this one fact.
There are two places an agent can live. It can live on your machine: the desktop apps and terminals you will meet in the next three courses. There, the app is the runtime (the thing that actually runs the work). Close the laptop, and the work pauses where it stood, because the machine doing the work went to sleep. Or it can live on the vendor's servers: this course. There, your browser tab is a window onto the session, not the machine running it.
The consequences are simple to state, and each one changes how you work:
- Close the tab: the work continues. The session was never in the tab. It is in your account, running on infrastructure that does not sleep when you do.
- Open the session from your phone: it is the same session. Not a copy, not a summary. The same running work, viewed through a smaller window.
- A scheduled task fires from a tab you closed last week. The schedule lives on the vendor's servers too. Your devices are not in the critical path.
Start a Cowork session at claude.ai, in the same browser tab where you chat. It runs as a remote session on Anthropic's servers. Your sessions and your files are saved to your account: continuity you did not have to set up. When the work reaches a decision only you can make, the approval comes to the Claude app on your phone.
Cowork on the web is in beta as this course is written: Max plan first, more plans to follow, and usage is metered. The mechanical layer moves fast here. Confirm your plan's access on the live product page before you rely on it.
Switch to Work mode in ChatGPT at chatgpt.com (shipped July 9, 2026, powered by GPT-5.6). It is not a separate app: it sits beside Chat mode in the same interface, and it is built to stay on a multi-step project for hours, breaking a goal into steps and completing parts on its own. Sessions are cloud-synced across web, desktop, and mobile: start on the laptop, check from the phone, same session. And Scheduled Tasks run from the cloud whether or not any device of yours is online.
Access is staged by plan. On web and mobile, Work rolled out across eligible paid plans, not Free or Go. (On the ChatGPT desktop app, Chat, Work, and Codex are available on every plan, including Free. Codex is a separate view in that desktop app: it is not selectable on web or mobile.) It is bundled into those paid plans at no extra list price, and usage draws down each plan's agent-usage allowance, so "metered" here means your plan's included allowance, not a separate bill. Availability keeps changing, and these plan specifics are the fastest-aging claims in this book. Confirm your current access on OpenAI's live product page before you rely on one.
One honest limit, so this concept does not oversell itself. A remote session runs on the company's machines. On its own, it reaches what those machines reach: your connectors, its own task filesystem, your platform files. On its own, it does not reach your local hard drive, your desktop apps, or the browser profile where you are logged in to your bank. Work that needs those things needs a local bridge or a local agent, and that is what the next courses teach. (One nuance for later: a desktop app can act as a bridge. While it is open, it can hand the remote session limited access to local files or the browser. Close the app, and the session keeps running but loses that local reach. You do not need this yet. Just know the wall is not absolute.) Part 4 gives you the full decision table.
A desktop agent is a worker inside your house: when your house loses power, the worker stops. A remote session is a worker in the vendor's office: your house's power does not matter, and your laptop and phone are just windows you look through to check on them.
Going deeper: you will meet this idea again, twice
Hold this concept loosely in mind for later in the section. Loop Engineering will teach you that unattended work needs something that stays awake between runs, and will ask where that something lives. Leaving the Laptop will name the machine on your desk "the last single point of failure" and teach the full decision about removing it. What you are looking at in this concept is the consumer-grade version of both ideas: the vendor's servers staying awake so yours do not have to. Same idea. No config files.
Check yourself
Ayesha in Lahore starts a client report in a web session at 5pm. Load-shedding cuts her power at 6. At 8pm she opens the session from her phone. What does she find, and why was her power never the problem?
Show answer
She finds the work finished, or waiting at an approval for her to clear from the phone. The session ran on the vendor's servers the whole time: her laptop was only ever a window onto it, and a closed window does not stop what is on the other side of it. A desktop agent, which she will meet in the Cowork desktop course, would have paused the moment her machine lost power, because there the machine is the runtime.
3. Two vendors, one shape
Now the concept this course exists for. In July 2026, Anthropic and OpenAI shipped their agent surfaces into the browser within days of each other. Both products expose a recognizably similar set of parts. And they arrived with the same anatomy.
This book teaches that anatomy as six parts, and later courses build each one in depth. You do not need those courses to use the parts as a reading lens today. Here is each part in one sentence, and where it appears in ChatGPT Work, every name below is OpenAI's own, taken from the July 2026 launch:
| ChatGPT Work calls it | This book calls it | One-sentence meaning |
|---|---|---|
| Scheduled Tasks | The heartbeat | What starts work without you: once, on a schedule, on an event, or while monitoring for changes. |
| Plugin Directory (connected apps) | Connectors | Permission-scoped reach into your real services — Slack, Gmail, Drive, and dozens more — so the agent can act, not only suggest. |
| Outcome-based task execution | The run-until-done loop | Give it an outcome, and it works toward that outcome across steps: not one answer, a finish line. |
| Cloud-synced sessions & Projects | The state spine | Memory that survives between devices and between runs, so work continues instead of restarting. |
| Approval prompts (mobile) | The human gate | Risky or judgment-heavy decisions come to a person — on the phone — before the work continues. |
| Work's cloud execution environment and artifact tools | The body | Where a run's work actually happens, producing finished artifacts: docs, sheets, decks, dashboards, small web apps. |
Run the same lens over Cowork on the web and the same table appears with Anthropic's names on it: scheduled tasks, connectors, sessions saved to the account, the approval on your phone. Two vendors. One shape.
Why does this matter to you, three weeks into your agent career? Because products will keep shipping and names will keep changing, and you cannot re-learn from zero every time. When independent builders keep arriving at the same parts, the parts are the discipline and the products are the packaging. Learn the shape once, and every new agent product becomes a half-hour read instead of a new field. That is this book's central claim, and July 2026 is its strongest evidence so far: the shape, not the tool, is the skill.
Two honest notes, so the lens stays a lens. First, the same shape does not mean the same behavior. Rollout order, plan tiers, limits, and the fine details differ between the two, and they change weekly. The mapping tells you what to look for. It does not promise you will find it set up the same way. Second, the six parts are introduced here as vocabulary only. Loop Engineering teaches you to design each one, and you should not schedule anything serious before it (Concept 9 says more).
One more note that is really a Concept 6 preview. ChatGPT Work's launch put code execution, browser access, and enterprise connectors inside one always-on space, so a single bad run could reach further, a point security reviewers flagged immediately. That is not a knock on the product. It is the shape's cost, and every vendor pays it. It is exactly why connectors get their own concept later, and why the approval gate is not optional.
Cars from different companies look different, but every one has an engine, wheels, brakes, and a steering wheel. Once you know the parts, you can drive any car after a short look around. Agent products are the same. This table is the parts list. This book teaches you the parts, so no vendor's packaging can confuse you again. And notice: two companies are racing to build the better car around a similar engine. That race is the "harness war." On the web, you are the driver choosing a car, not the engineer building one. Both jobs matter. They are just different jobs.
Same shape, so where do the two actually differ? The six parts are shared. The packaging is not. Here is the honest side-by-side, built from each vendor's own July 2026 launch. Treat every row as mid-July 2026 and verify against the live pages, this is the fastest-aging table in the book.
| Cowork on the web (Anthropic) | ChatGPT Work (OpenAI) | |
|---|---|---|
| What it is | A remote session, reached from the Cowork surface at claude.ai | A mode inside ChatGPT, next to Chat mode, at chatgpt.com |
| Where it runs | Anthropic's servers | OpenAI's servers |
| Model | Claude (Opus/Sonnet tier, per task) | GPT-5.6 family |
| How it's sold | Web beta, staged by plan; metered | Bundled into eligible paid plans on web and mobile, every plan on the new desktop app; draws down each plan's agent allowance |
| Connectors | Anthropic's connector catalog, over MCP | Plugin Directory (renamed from App Directory at launch), also MCP-based |
| Run-until-done | Stated stopping condition in the brief | Give an outcome, and it works across steps toward it |
| Persistent workspace | Projects + a saved context file (Anthropic's is named CLAUDE.md) | Projects + memory (reviewable, correctable) |
| Finished artifacts | Docs, sheets, decks, files | Docs, sheets, decks, dashboards, and Sites (publishable web apps at a URL) |
| Coding sibling | Claude Code (a separate surface) | Codex (merged into the same app as a mode) |
| The mobile gate | Approvals in the Claude app | Approvals in the ChatGPT app |
Read that table with the parts in mind, and a pattern jumps out: almost every difference sits in the packaging column. The parts down the middle are shared. The model differs. The plan rules differ. The connector list has a different name. One ships a URL-publishing feature the other does not. A few differences run deeper than labels: where a task can reach your local files, how approvals work, whether the coding agent lives in the same app. Those are real, and Concept 10 uses them. But the heartbeat is still a heartbeat. The gate is still a gate. The spine is still a spine, in both. The shared parts are the lasting layer. The rest is the mechanical layer this course told you to look up, not memorize. That is the point of the six-part lens, shown instead of claimed. If you had learned only one product, the other would still be a short look-around, because the parts that carry the work are the parts they share.
A word for what you are watching. Notice where the two products fight. Not only on the model. The models still matter, and both are strong. But the products compete on everything wrapped around the model: the scheduler, the connector layer, the session spine, the phone gate, the way files exit. This book has a name for that wrapper. It is the harness, and Harness Engineering is the course about it. For most of the last two years, the harness was something engineers built by hand, in code, in the terminal. What these July 2026 launches show is that the harness has come to the web, as a finished product, and two companies are now competing on whose harness is better. That competition is good for you. It is why the surface improved this fast.
But hold one line clearly, so you read this right. On the web, the companies fight the harness war. You do not fight it. You are not building a harness here. You are choosing between two that are already built. The engineer's job, wiring the loop, the tools, the context, the checks, is the subject of the later Harness Engineering course, and it is real, deep work. Your job on this surface is smaller and different: pick the pre-built harness that fits the task, then direct it well. Knowing the war is happening helps you choose. It does not turn you into a harness engineer. That is a different course, and a different chair.
Who is each one for? The parts are shared, but the vendors are aiming at overlapping-but-different people, and knowing the aim helps you pick. Two layers to it:
What the companies aimed at. Both products are pitched at the same core user: the knowledge worker. That is the person whose day moves information between documents, spreadsheets, email, and chat, and who does not code. That is who "produce a finished spreadsheet, deck, or report" is written for. But the shape around that user differs. ChatGPT Work is a mode inside one app that also holds a coding agent (Codex). So OpenAI is aiming at a workplace where the same person, or team, might do both knowledge work and code without switching apps. And it comes with existing paid plans at no new list price, which aims wide. Cowork on the web launched Max-first and metered. That is a narrower, higher-intent early group. Its coding agent (Claude Code) stays a separate surface. That is a cleaner split between the two kinds of user.
Who should pick which. This is this book's guidance, not a vendor claim. For most document-and-connector knowledge work, either one fits. The honest tie-breakers are ordinary: which company's model you prefer, which one your connectors already live behind, and which plan you already pay for. The decision sharpens mainly in one case. If you do knowledge work and code and want them under one roof, ChatGPT's desktop app carries Chat, Work, and Codex together, which is the lighter setup. If you would rather keep the work agent and the coding agent as separate, separately governed surfaces, the Cowork and Claude Code split is the cleaner fit. Either way, this is mostly a packaging choice, not a capability one, which is why it is a footnote to the shape and not the headline.
One audience this course rules out for both, and it matters: anyone handling regulated data. PHI (protected health information), privileged matter, regulated financial records, is not the target user of either web surface until compliance says so in writing, because the working files and platform storage live in the vendor's custody by definition. Concept 10 carries that in full. Note here only that "who it's for" has a hard boundary neither vendor's marketing draws for you.
One real difference is worth flagging beyond packaging, because it changes a choice you will make. OpenAI's coding agent, Codex, lives in the same ChatGPT app as Work, though on the desktop app it sits as a separate view, and it is not selectable on the web or phone. Anthropic keeps its coding agent, Claude Code, as a wholly separate surface. For a knowledge worker, this is invisible. For someone who does both knowledge work and code, it matters. On the desktop, ChatGPT holds Chat, Work, and Codex under one roof. The Claude side asks you to move between Cowork and Claude Code. Neither is better. It is a real shape difference, and Concept 10's "pick by what the work touches" table is where it pays off.
The two products are built the same way and differ mostly in their labels, their model, and how each plan sells them. The one real structural difference: OpenAI put its coding tool in the same app as its work agent. Anthropic keeps them apart. For document work you will not notice. If you also code, it is worth knowing.
Check yourself
Next quarter, a third vendor ships an agent product called "Flows." Its launch page lists: triggers, integrations, an autopilot mode, and workspace memory. Map the four names to the book's parts before reading a word of their docs.
Show answer
Triggers: the heartbeat. Integrations: connectors. Autopilot mode: the run-until-done loop (and your first question for the docs is: what is the stopping condition, and who checks it?). Workspace memory: the state spine. You just read a product you have never seen, in under a minute, and arrived with the right questions. That exercise is the skill this concept teaches.
Part 2: The Surface
The shift is behind you. Now the working parts of the surface itself: where your sessions live, where your files actually land, what a connector does when nobody is watching, and how the one decision that needs you finds you. Four concepts, and one of them, the three file tiers, is the single most important discipline in this course. Slow down when you reach it.
4. The account spine: sessions and files you did not have to build
In your earlier Foundations workflow, a standalone conversation often started from zero. You re-pasted context, re-explained your project, re-uploaded the file. Continuity was your job, done by hand, much of the time.
The agent surface hands you continuity as a feature. Your sessions are saved to your account. The files a session produces are saved to your account. Open any of it from any device, and it is the same work, at the same point. This course calls that the account spine (this surface's version of the state spine from Concept 3): memory that survives between sessions and between devices, built by the vendor, maintained by nobody you have to hire.
That is a real gift, and you should use it. It also has a price, and you should know the price before you lean your work on it. The spine lives in the vendor's custody and the vendor's format. Your sessions, your files, and the history of your work sit on their machines, under their account system, in shapes they defined. Nothing about that is sinister. Everything about it is a dependency: on the plan you pay for, the product surviving, and the vendor's rules staying compatible with yours. Concept 5 gives you the discipline that keeps the dependency safe. For now, hold both halves: the spine is free continuity, in someone else's house.
Every Cowork session is saved to your claude.ai account, with the files it produced attached to it. Return to a session tomorrow, from any device, and the context, the plan, and the files are where you left them. Your sessions list is, in effect, your work log on this surface.
Sessions in ChatGPT Work are cloud-synced across web, desktop, and mobile: start on the laptop, reopen on the phone, and it is the same session, state, and files. Two features extend that spine. Projects group related chats, files, and instructions into one persistent space that shares context across sessions, the natural home for recurring work (Concept 6's persistent-workspace idea, built in). And memory, where enabled, lets it carry relevant context from past chats, with a reviewable summary and sources you can inspect or correct. The session list, your projects, and memory are the spine. The devices are windows. Everything the Cowork tab said about custody applies here identically: this spine lives on OpenAI's servers, in OpenAI's format.
Three small habits make the spine work for you instead of against you. Name sessions like work products, not chats. "Acme renewal brief. May invoice run" finds itself in three months. "Quick question" never does. One workstream per session. Mixing the client report and the holiday planning into one session bleeds context between them, and you learned in Foundations what stale context does to quality. Prune what is dead. A long session carries its whole history into every turn, and context still costs money on this surface exactly as it did in chat: less context, chosen on purpose, beats more context dragged along by habit.
In the chat tab, you carried your papers home every evening and brought them back every morning. On the agent surface, you have a desk with drawers: everything stays where you left it, reachable from anywhere. The desk is very useful. Just remember the desk is in the vendor's building, not yours.
Check yourself
Name the gift and the price of the account spine, one sentence each.
Show answer
The gift: continuity you did not have to build, sessions and files that survive the tab, the day, and the device. The price: that continuity lives in the vendor's custody and the vendor's format, so anything that exists only there depends on your plan, their product, and their rules. The next concept turns that price into a working discipline.
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 honest 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 memorize 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 web session works in a temporary task filesystem (tier 1), saves outputs to your account with the session (tier 2), and can save or send files through your connected services. Drive, Gmail, Slack (tier 3). The tier-3 path runs through the connectors you grant, which is why the next concept treats connector scope with new seriousness.
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 favor 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.
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
You met connectors in Foundations: permission-scoped access to a real service. Drive, Gmail, Slack, over the MCP standard. You grant the scopes. The AI works inside them. Nothing about that definition changes here. What changes is the weight a connector carries when an agent, not a chat, is holding it.
On this surface, your trust controls come down to two levers: connector scope and approvals. Desktop agents, which you will meet in the Cowork desktop course, add a third lever (which local folders the agent may see) and build a whole discipline around it. That lever does not exist on a browser-only session, because there is no local filesystem for it to scope on its own. Its job is split between the tier decision you just learned and the connector scopes you grant.
Which leads to the fact this concept exists to state plainly: on the web, connectors carry double weight. A connector is the agent's reach into your services, that was always true. On a browser-only session it is also the main automated exit door for files: the tier-3 path from Concept 5 mostly runs through the connectors you have granted. A download is the manual exit, and a desktop bridge can add a local write where supported, but for hands-off work the connector is the door. The same permission screen you saw when you connected the service now governs both what the agent can read and where your finished work can go. So the Foundations habit gets a promotion from good practice to rule: read the scopes before you click connect, and grant the narrowest scope that does the job.
Two specifics worth knowing before your first real task:
- Read scope is not send scope. Granting a mail connector read access lets the agent summarize threads. Write or send access is a different grant, and a bigger one. A message sent from your address cannot be recalled, and people will act on it. Do not assume a safe default here. Connectors vary a lot: some are read-only, some can only create drafts, and some can take real write or send actions, depending on the app, the plan, and the workspace settings. So inspect the actual actions and permissions for the specific connector you enable. Then require approval for anything with consequences, and treat any setup that can send as a separate, higher-trust decision.
- Untrusted content always gets the careful mode. Here is the short form of a rule the Cowork course teaches in full. Text that someone else wrote can carry hidden instructions. An inbound email, a vendor PDF, an unknown webpage. To you it looks like normal sentences. To the agent it can read as commands. This trick is called prompt injection. It is a real attack, not a theory. The defense at this level is simple. When a task touches content you did not write, stay in ask-before-acting mode. Read the plan for steps you never asked for. If a plan proposes a connector action you did not request, do not approve it. Redirect, or start over.
Discipline for granting, unchanged from Foundations but worth repeating where the stakes rose: connect a service when a specific workflow needs it, not speculatively. Every connector is reach, and now also a door.
A connector is a key you give the worker. On this surface, the same key opens two things: the rooms the worker may enter to fetch information, and the mail slot through which your finished documents leave the building. A key that opens more than the job needs is not convenience. It is risk you chose. Read what each key opens before you hand it over.
Check yourself
On the desktop (next course), the trust levers are folders, connectors, and approvals. On the web there are two. What happened to the third, and what took over its job?
Show answer
The folder lever disappeared because a browser-only remote session has no local filesystem to scope on its own. (A desktop bridge can lend scoped local access while the desktop app is open, but that is the desktop's lever, not the tab's.) Its job was inherited by two things: the tier decision (Concept 5), which governs where files live, and connector scope, which governs what the agent can reach and where files can exit. That inheritance is exactly why connectors carry double weight on this surface.
7. The gate in your pocket
Every agent product in this book keeps one promise: the decisions that genuinely need a person come to a person. This book calls that the human gate. What this surface changes is not the gate. It is where the gate finds you.
On a desktop agent, you are usually at the screen when the approval card appears: the gate and your eyes are in the same place by accident. On this surface, that accident is gone. The work runs while you are at lunch, in a meeting, or asleep, that is the point of the surface, so the approval cannot wait on your tab. It comes to your phone: a notification, an approval card, a decision you can read and clear in thirty seconds from anywhere.
Get the phone's role exactly right, because both mistakes are common. The phone is the gate, not the workbench. From the phone you review a plan, approve a step, redirect with a sentence, or stop the task. You do not draft the brief there, and you do not review a forty-page deliverable there. Design work belongs on the big screen. The phone exists so that a session never stalls for six hours waiting on a ten-second decision.
And now the caution this concept exists for. It is borrowed from a course you will read later, because it is too important to wait: the gate did not move. The doorbell had to. When you worked at the screen, an escalation landed in front of your eyes on its own. Now the work runs where your eyes are not. So an approval can sit unseen. And an unseen escalation is a delayed decision, which is sometimes a decision made by default. A session paused three days on an approval you never saw did not fail loudly. It failed silently, which is worse.
So the habit, and it is non-negotiable before you trust anything unattended: ring the gate on purpose, once. Design a small task that will require one approval (for example, ask it to save a harmless test file to a connected test folder, the kind of step it pauses to confirm). Start it. Walk away from the computer. Confirm the notification actually reaches your phone, the app installed, notifications on, not smothered by a focus mode, and clear the approval from the phone. An alarm you have never heard is a rumor. Project 3 walks you through it.
Approvals from a Cowork remote session reach you in the Claude mobile app. Before your first walk-away task: app installed, signed in to the same account, notifications enabled. Then run the deliberate-approval test above once, end to end.
OpenAI built the mobile gate directly. The ChatGPT mobile app lets you stay connected to running work. You can answer questions, review outputs, and approve important actions while away from your desk. OpenAI describes Work as breaking a goal into steps while you follow along, answer questions, change direction, and approve important actions. So the gate reaches your phone by design. Same preflight as Cowork: app installed, same account, notifications on. Then run the deliberate-approval test once, end to end, before you trust anything unwatched. (Some of the most detailed mobile-approval docs are written for Codex work on a host Mac. Confirm the exact Work-mode behavior on the live pages. But the gate-on-mobile idea is first-party.)
The worker keeps working while you are away, and once in a while they must ask you a question. On this surface, the question comes to your phone. Two rules. First: answer questions from the phone, but do the real designing at your desk. Second: before you trust the arrangement, make the worker ask you one question on purpose, and check the question actually arrives. A doorbell you have never heard ring might be broken, and you would never know.
Check yourself
Your scheduled Monday-morning brief has produced nothing for two weeks. You never received an error. What is the first thing you check, and what is the second?
Show answer
First: whether the gate reaches you at all, is a session sitting paused on an approval that never arrived on your phone? Silent non-delivery of the gate is this concept's failure mode, and it produces exactly this symptom: no output, no error. Second: whether the task ran at all, because metered usage and plan limits (Concept 9) can make a scheduled task pause, fail to run, or need your intervention when the budget is spent, and you should not rely on getting an error. Notice what both checks share: on this surface, silence is ambiguous until you have made it mean something. That idea returns, with engineering teeth, in Leaving the Laptop.
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
This is your first delegation lesson in this book, and it may be your first ever. Everything you did in Foundations was conversation: you asked, you read, you asked again, and nothing happened that you did not watch happen. Delegation is different. You describe an outcome, the agent does multi-step work, and you see the result. The quality of that result is decided almost entirely by four moments, and only one of them is the prompt.
Step 1: Brief. Describe the assignment the way you would brief a smart, motivated new colleague who does not know your context: the outcome, the constraints, the audience, and the why. This is Foundations Course 2's briefing discipline with the stakes raised, because now the model does not just answer against the gaps in your brief, it acts against them.
The difference in one pair:
- A query: "Summarize this PDF."
- An assignment: "Read these three files. Flag every deadline and every open commitment. Produce a one-page brief for my manager: direct tone, deadlines first, no introduction paragraph."
The query works fine in chat. The assignment is what this surface is for. Notice what the assignment contains that the query does not: what to produce, from what, for whom, in what shape, with which rules. Every one of those is a decision the agent would otherwise make for you, silently, mid-task, while you were not watching.
Step 2: Plan. End every non-trivial brief with one line:
Lay out your plan first, and pause for my approval before doing anything.
Here is why this line matters more on this surface than anywhere else. On a desktop agent, you often watch the work run and can interrupt mid-step. Here, you will walk away. That is the point. So the plan is usually your only intercept between intent and finished work. Skip it, and your first chance to catch a mistake comes too late: after the mistake has run across every file in the task.
Step 3: Approve or redirect. Read the plan before you approve it. Four things to check, and they take two minutes:
- Scope: is it touching only what you named, or has the job quietly grown?
- Order: does anything act before anything verifies?
- Reach: is it proposing a connector or a send you did not ask for? (If yes, and the task involves content someone else wrote, stop and reread Concept 6.)
- Assumptions: what is it assuming about format, audience, or rules that you never stated?
If something is wrong, do not start over. Redirect with a sentence: "In step 2, use the headings from the existing template instead of inventing new ones." The agent rewrites the plan and asks again. A one-sentence correction at the plan stage costs nothing. Cleanup after a confidently executed wrong run costs an afternoon.
Step 4: Review. The deliverable arrives while you are elsewhere, so build the review into the brief itself. Two lines, added to the end of every deliverable-producing assignment:
Before you start: ask me 1–2 clarifying questions.
If any sources contradict each other on a material point, flag the
contradiction in the deliverable. Do not silently pick one.
When done: list 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).
The first line surfaces the assumption that would have become a defect. The second exists because a model's training pulls it toward smoothing conflicts into confident answers, and for a lawyer or an accountant, silently picking one of two contradicting sources is the failure that matters most. The third is Concept 5's tier discipline, made automatic. Then, when you read the result: if it is 90% right, edit the last sentence by hand. If something structural is off, tell the agent what is wrong and ask for a revision. Iterating with the agent teaches it your taste. Rewriting by hand teaches it nothing.
Run your first assignment now (ten minutes, nothing to connect). Take any real messy input you have, meeting notes, a project plan, three related emails pasted into files. Open the agent surface, attach or paste them, and send a full four-step assignment: an outcome with constraints and audience, the plan-first line, the three review lines. Read the plan. Redirect one thing on purpose, even a small thing, so you feel the redirect work. Approve. Walk away for the length of a tea. Come back and read the deliverable against your brief. That single run teaches you more than the rest of this concept, and it is the exact loop you will run, unchanged, in every course after this one.
The anti-pattern, named. The most common failure on this surface is treating it as a chat box with superpowers: firing a one-line prompt at unattended multi-step work. The math of it is unforgiving: the vaguer the brief, the more decisions the agent makes alone. The longer the unwatched run, the more of those decisions compound before you see any of them. A vague query in chat wastes a reply. A vague assignment on this surface wastes an afternoon, yours, cleaning up.
Four steps, every time. Say what you want, fully: the result, the rules, the reader. Ask to see the plan before any work starts. Read the plan and fix it with one sentence if it is wrong. Then read the result against what you asked for. The plan is the important step. Fixing a plan takes one minute. Fixing finished wrong work takes an afternoon.
Going deeper: this loop is the whole section, in miniature
Every course ahead of you deepens one step of this loop. The Cowork course deepens steps 2 and 3 for desktop work: per-step approval cards, the execution view, the full trust model. Spec-Driven Development deepens step 1 until a brief becomes a spec precise enough to check work against. Loop Engineering automates step 3: a checker agent reads the work so you do not read every run. Trusting the Checker deepens step 4 until review becomes measurement. Nothing you learn later replaces this loop. Everything sharpens one of its steps.
Check yourself
You brief a multi-source task, skip the plan-first line, and leave for a meeting. You return to a finished deliverable built on a misreading of one source. On a desktop agent you might have caught it mid-run. Why was that safety net never available here, and which single line replaces it?
Show answer
The net was your eyes on the screen, and on this surface your eyes were never going to be on the screen, because working unwatched is the point. The mid-run intercept does not exist for you, so the only intercept left is before the run: "Lay out your plan first, and pause for my approval." On this surface, that line is not good practice. It is the safety net.
9. Scheduled tasks with no device online
Everything so far still began with you pressing start. This concept removes that too, and it is the capability that made July 2026 worth a course.
A scheduled task is an assignment you describe once, with a cadence, that then runs on the vendor's servers on its own clock: laptop closed, phone in your pocket, no device of yours online. Every Monday at 8, the week's brief is waiting before you sit down. That is the promise, and on this surface it is real. What this concept adds is the discipline that keeps it from quietly becoming a mess.
Every scheduled task is four answers. Write them down before you create it, in this order:
- What should it do? The standing brief. Everything Concept 8 taught, with one addition: nobody will be there to clarify, so the brief must survive your absence, including the empty case. "If there are no new items this week, produce a one-line note saying so" is the difference between a quiet week and a silent failure you cannot tell apart.
- What may it touch? The files and platform storage in scope, by name. A scheduled task with vague scope drifts wider every week, and nobody is watching it drift.
- What can it reach? The connectors, listed. Connectors are permissions, not suggestions: a task with no mail connector cannot send mail no matter what the brief says, and that is a feature. Grant the task the narrowest reach its job needs, exactly as Concept 6 taught, and nothing more, because this grant will be exercised unattended, on a schedule, indefinitely.
- When does it start? The cadence. And one honest fact about every scheduler ever built: "Monday at 8" means around Monday at 8. Schedulers stagger and occasionally slip. If a hard deadline hangs on the output, the schedule alone is not a guarantee, a topic Leaving the Laptop treats properly.
Three rules before your first schedule, each earned the hard way by someone else:
- Never schedule what you would not already trust to walk away from. A schedule is the last rung of a ladder, not the first. Run the task by hand, watched, at least a few times. Run it unwatched a few more. Only what has survived walking away earns a clock. Scheduling a task you have run once is not automation. It is a weekly surprise, subscribed to.
- Do the metered math in writing. Hands-off work on someone else's servers always has a budget: runs per day, or hours per plan, staged by tier, and different for each company. Count your scheduled tasks against your plan's limit before the week they collide. When usage or task limits are reached, a task may pause, fail to run, or need your intervention. Do not rely on the absence of an error message. Check the Scheduled page and your notifications. This is the failure Concept 7 warned about: silence means nothing until you have made it mean something.
- A run that completed is not a task that succeeded. The scheduler's job ends at "it ran." Whether the work is right is not the scheduler's business. So build the success signal into the task's own output: the brief ends with a stated line, items processed, files produced and their tiers, or the explicit empty-case note, and you read for that line. Green means "ran." Only the line means "worked."
Cowork's scheduled tasks are described in plain language with a cadence, and on the web they run remotely: they fire with no device of yours online, and the results wait in the session for you. Access and run limits are staged by plan and metered, do the arithmetic against your plan's live limits, not against anything printed here. One caveat worth knowing early, and it is the opposite of a limit: Cowork's scheduled tasks run remotely, even when your computer is asleep or the desktop app is closed. They work with your connectors, plugins, and files saved to your Claude account, but they cannot be tied to a folder on your computer. So if a recurring workflow depends on local files or desktop apps, it needs a different, desktop-dependent setup. Keep scheduled work on connectors and account storage, and the promise holds.
ChatGPT Work's Scheduled Tasks cover all four heartbeats you just learned, in OpenAI's own words: perform an action once, repeat on a schedule or when an event occurs, or monitor for changes over time. (On this web surface, event-style triggers such as "a new file appears" are handled by periodic monitoring, not an instant push, so treat "trigger" and "monitor" as one family here.) Its launch examples include both kinds. Some report: check dashboards each morning and summarize what changed. Others act: update a presentation when new feedback arrives, or turn recurring feedback themes into prioritized product ideas. So the product does more than report. This beginner course deliberately stops at the reporting line anyway. Action schedules have a larger blast radius (more can go wrong, and reach further), and they should wait until you have learned checker design, state, idempotency, and recovery in the later courses. That is a rule this course chooses, not a limit of the product. The four answers (what, touch, reach, when) and the three rules apply here with no translation. Tasks run in the cloud against your account. Reach is granted through the Plugin Directory. Usage draws down your plan's agent allowance, so the metered math is real here too. Confirm the current allowance on the live pages.
One firm caveat: a Scheduled Task created inside a Project that holds uploaded files cannot reach those Project files. So use a supported connector or another source the task can reach, and do not design the scheduled workflow around files uploaded to the Project. This is Concept 3 in practice: the same six-part shape, a different company's buttons.
And the boundary, stated honestly. What you can build with this concept alone is a reporting schedule: read sources, synthesize, produce a brief, land it in the right tier. That is genuinely valuable, most people's first year of value on this surface is exactly that, and it is deliberately the ceiling of this course. What you cannot yet build safely is a schedule that acts: one that sends, files, updates, and decides on a cadence. Acting unattended needs parts you do not have yet, a checker that grades the work, a stopping condition a machine can verify, a state file that remembers between runs. Loop Engineering teaches you to design all of them, and Leaving the Laptop teaches where the proven result should live. This concept opened the door. Those courses are what walks through it.
A scheduled task is a standing instruction: the worker does the job every Monday without being asked, even when your laptop is off. Four things to write down: the job, what it may touch, what it may reach, and when it runs. Three rules: only schedule jobs the worker has already done well while you were away. Count your plan's budget before you hit the limit, and check the Scheduled page rather than trusting silence. And make the job report its own result, because "it ran" and "it worked" are different facts.
Check yourself
Ayesha wants to schedule two things: a Monday-morning summary of her clients' unpaid invoices (read from Drive, brief saved to her account), and an automatic Friday task that emails payment reminders to every late client. Which one belongs in this course, which one must wait, and what is the one-word difference between them?
Show answer
The Monday summary belongs here: it is a reporting schedule, read, synthesize, land in a tier, and a wrong week costs her a rewrite. The Friday reminders must wait: that task acts on the outside world, unattended, on a cadence, a wrong run emails real clients, and nothing in this course checks the work before it goes. The one-word difference: acting (versus reporting). Reporting schedules are this course's ceiling. Acting schedules need the checker, the stopping condition, and the state that Loop Engineering teaches, and even then, the reminder email is exactly what the human gate exists for.
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 questions remain, and they are the honest ones. 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 surface you just learned is one option among several, and the mature habit is choosing per task, not swearing loyalty to one. The rule that sorts every case is short: pick by what the work touches.
| The work needs... | The surface | Where this book teaches it |
|---|---|---|
| Connector-and-document work, continuity across devices, nothing installed | Web | This course |
| Work that must continue with your machine off | Web (for repo work, a cloud Routine — a later topic) | This course; Loop Engineering |
| Your local files, your desktop applications, the browser where you are signed in | Desktop | Cowork & OpenWork — next for knowledge workers |
| Code, repositories, the command line | Coding agents | Agentic Coding — next for engineers |
| Regulated data with custody requirements (PHI, privileged matter, regulated financial data) | None of the above, yet. Get compliance's answer in writing first | The Cowork course carries the full regulated-workloads guidance |
Read the table twice, because it does two jobs. As a task router, it answers today's question: this report, this surface. As a course router, it answers the section's question: which co-worker course you take next. Knowledge workers whose day lives in documents and connectors continue to the Cowork course, which adds everything the web cannot reach. Engineers continue to Agentic Coding. Nobody has to leave this surface behind: the healthy setup mixes surfaces per task, permanently.
One row deserves its own paragraph, because it carries the most risk: regulated data. Remember what Concept 5 taught: tiers 1 and 2 are the vendor's custody by definition. A remote session's working files and your platform storage live on the vendor's machines. That is what makes the surface work. It is also exactly what a compliance regime cares about. So for PHI, privileged client matter, or regulated financial data, the question is not "is this surface careful?" The real question is "is this data allowed to live in this custody, under this plan, with this paperwork?" And only your compliance team, in writing, can answer that. The Cowork course carries the full treatment. Until you have the written answer, regulated data does not touch this surface.
And one rule keeps the multi-surface mix from becoming a mess, and you already know it: know which tier every deliverable landed in. A deliverable in tier 3, your Drive, your repo, your firm's records, does not care which surface produced it. That is the whole point of tier 3.
Different jobs, different workplaces. Documents and connected services, or work that must run while your machine is off: the web. Your own files and desktop programs: the desktop apps, in the next course. Code: the coding agents. Sensitive regulated data: stop, and get a written yes from compliance first. Use several workplaces at once, just make sure every finished document ends up in your own filing cabinet, whichever workplace made it.
Check yourself
Three tasks land on your desk: (a) a weekly summary built from Slack and Notion, wanted even while you travel. (b) cleaning up 200 files in a folder on your laptop. (c) a memo synthesizing privileged client documents. Route each one, and name the deciding fact.
Show answer
(a) Web: it touches connectors only, and it must survive your machine being off, both point the same way. (b) Desktop: the work touches your local filesystem, which a browser-only remote session cannot directly reach on its own. That is the Cowork course. (c) Neither, yet: privileged matter is a custody question, and tiers 1 and 2 are vendor custody by definition, compliance answers in writing before any surface sees that data. Three tasks, three answers, one rule: what the work touches decides.
11. The open path: no vendor cloud
A confession about this course's structure, and then the honesty 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 organization'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 organization 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.
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 is the honest sentence 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 honest sentence: "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 the course at the honest boundary, the way every course in this book ends.
The surface does not improve the work. A remote session makes a weak brief unattended, not better. Every quality lever you have met lives on your side of the screen: the brief (Concept 8), the plan review (your only intercept), the tier decision (Concept 5), the deliberate gate test (Concept 7), the walked-before-scheduled rule (Concept 9). July 2026 moved the agent into the browser. It moved none of your responsibilities anywhere.
The surface is weeks old, metered, staged, and vendor-shaped. Every mechanical fact on this page, plan tiers, run limits, button names, even product names, is the fastest-aging material in this book. The lasting layer is what you should be leaving with: the stop-typing test, the window-not-runtime architecture, the three tiers and their one-line discipline, the six-part reading lens, the four-step loop, the four answers of a schedule. Those survive every rename. And one discipline protects you from all the churn at once, so hear it one last time: nothing that matters lives only on the platform. Tier 3, always, for anything you would mind losing.
And this surface is a beginning, not a destination. Here is the section you are now equipped to walk, and what each course adds to what you just learned:
- Cowork & OpenWork, next for knowledge workers, extends your delegation loop to your real files and desktop, with the full trust model the web never needed: folders as a lever, the autonomy ladder, the regulated-workloads discipline.
- Agentic Coding, next for engineers, the same loop, in the terminal, on code.
- Spec-Driven Development sharpens your step 1 until a brief becomes a spec precise enough to check work against, and it runs on this surface too.
- Loop Engineering builds what Concept 9 fenced off: schedules that act, with the checker, the stopping condition, and the state spine that make acting safe.
- Harness Engineering and Trusting the Checker make the loop safe, then measurable.
- Leaving the Laptop closes the section with the runtime decision, where proven work should live, and the surface you just learned is one of its homes' front doors.
The closing thought, and it is the course in three sentences. The chat box is where you design. The agent surface is where it runs. In July 2026 the two moved into the same address, and the division of labor got sharper, not weaker. Learn the shape. The address will change again.
This surface changes where work runs and when. It does not change how good the work is: that still comes from your brief, your plan review, and your checks. The products on this page will change names and limits many times. The ideas on this page will not. Keep your finished work in your own storage, and carry the ideas to the next course.
Check yourself
A reader finishes this course and says: "Now that agents run on the web, the desktop and terminal courses are legacy." Using Concept 10's rule and this concept's boundary, write the two-sentence correction.
Show answer
The surfaces divide by what the work touches, not by which shipped last. Local files, desktop apps, and repos are real work that a browser-only remote session cannot directly reach on its own. So the desktop and terminal courses teach territory this surface does not cover. And no surface, new or old, improves the work itself: the brief, the plan review, and the checks are the skill, and the rest of the section is where that skill gets its depth.
Where this book uses this surface (dogfooding)
The honest answer, as of mid-July 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 labor 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, notes, plans, drafts, and never regulated data (Concept 10's rule applies to practice too).
📱 Project 1 · 15 min · The closed-lid test. Difficulty: easy · Uses: Concept 2. Do. Start a small multi-step session (summarize three pasted documents into one brief). Mid-run, close the tab. Reopen the session from your phone. Done when you watched the same session continue on a second device, and you can say, in one sentence, where the runtime actually is.
🗂️ Project 2 · 30 min · The three-tier audit. Difficulty: easy · Uses: Concepts 5 and 8. Do. Run one real task that produces a deliverable. Use the full Concept 8 brief, including the closing line that lists every file and its tier. Done when you can name the tier of every file the task created, and the deliverable itself exists in tier 3: your Drive, your inbox, or your records, not only on the platform.
🔔 Project 3 · 20 min · Ring the gate on purpose. Difficulty: easy–medium · Uses: Concept 7. Do. Design a task that will require one approval, then walk away from the computer entirely. Approval behaviour varies by product, connector, and workspace, so use a safe, low-stakes trigger: ask the agent to save a harmless test file to a connected test folder, or to prepare a draft action that needs your confirmation. Do not use sending, deleting, purchasing, or account changes for this drill. If no approval fires, that is itself a finding: check your approval mode and connector settings, and note what it took to make the gate ring. Done when the approval reached your phone, you cleared it from the phone, and the finished work was waiting when you returned. An alarm you have never heard is a rumor. This project makes you hear it once.
⏰ Project 4 · 30 min, plus one week · The first reporting schedule. Difficulty: medium · Uses: Concept 9. Do. Create a Monday-morning brief from one connector plus one file source. Write the four answers first (what, touch, reach, when), include the empty-case line and the success signal in the brief, and do your plan's metered arithmetic in writing. One vendor note: on ChatGPT, a Scheduled Task created inside a Project that holds uploaded files cannot reach those Project files. Use a supported connector or another source the task can reach, and do not build the scheduled workflow around a file uploaded to the Project. Done when it has fired twice with no device of yours online, and each result contained the success signal, not just a completed run.
🔁 Project 5 · 45 min · One task, two vendors. Difficulty: medium · Optional: requires access to both products · Uses: Concept 3. Do. Run the same assignment in Cowork on the web and in ChatGPT's Work mode. This needs a paid plan on each side, and staged rollouts may mean you cannot reach both yet. If so, pair with someone who has the other product and compare your results, or run it on the one you have and predict the other from Concept 3's table. Keep Concept 3's comparison table open beside you and test it: does each row still hold, or has a rollout or rename moved something since mid-July 2026? Done when you have a one-page note, saved to tier 3. It says: which rows of the comparison you confirmed. Which rows had drifted (the mechanical layer aging in real time). And whether all six shared parts showed up in both. That last finding, not the differences, is the point.
🧳 Project 6 · 45 min · The exit drill. Difficulty: capstone · Uses: Concepts 5 and 11. Do. Pretend the platform vanishes this quarter. From tier 3 alone, your Drive, your email, your records, reconstruct your working state: the templates, the standing briefs, the deliverables. Done when the list of what you could not reconstruct is written down. That list is your tier-2 exposure, and next week's saving discipline. (When you reach Leaving the Laptop, you will meet this drill again, with engineering teeth.)
Appendices: the later courses, on the web
The rest of the General Agents section teaches its craft with Claude Code and OpenCode: local tools, run from your terminal, working on files on your own machine. This course taught the web surface: Cowork on the web and ChatGPT Work, both remote, both in a browser tab.
These appendices are the bridge. For each later course, they ask one question: how much of that course can you do from the web surface, with nothing installed? The answer is never "all of it" and never "none of it." Some ideas transfer cleanly, under different names. Some transfer in a weaker form. And some cannot cross at all, because they need a local machine or real code execution that the web surface does not give you. A final appendix then steps back from the course entirely, to map the harness war across the whole industry.
That last group is not a gap in the web surface. It is the exact line where this section tells you to leave the browser. So read these appendices two ways: as a map of what you can already do today, and as a preview of why the next courses exist.
One rule holds across all of them. On the web, you rent a finished harness. In the later courses, you build one. So a topic "transfers" when it is something the vendor's harness already does for you, and it "does not transfer" when it is something you would have to wire yourself. Keep that line in view and every appendix reads the same way.
One more framing note, so the boundaries below stay honest. When an appendix says the web "does not reach your local files" or "has no local repo," it means a browser-only session: a tab, nothing installed. That is the surface this course taught. Two things sit just past it. A desktop bridge (Concept 2) can lend a remote session limited local access while the desktop app is open. And a local agent (the desktop and coding courses) runs on your machine from the start. So read the "does not transfer" rows as browser-only: they mark where the tab ends, which is exactly where the next courses begin.
Appendix A · Agentic Coding, on the web
The Agentic Coding course teaches Claude Code and OpenCode through fifteen concepts. It is also this book's context-engineering course. Most of its ideas are about managing what the model sees and making its work checkable. A surprising amount of that transfers to the web, because the six parts are the same. What does not transfer is everything that assumes a terminal, a local file system, and code you run yourself.
Transfers cleanly:
| That course teaches | On the web, it is |
|---|---|
| Plan mode (read first, act after approval) | The delegation loop you learned in Concept 8. Ask for the plan before the run. Same idea, no keybind. |
| The rules file (CLAUDE.md / AGENTS.md), permanent project instructions | A Project's saved instructions, plus the persistent-workspace idea from Concept 6. Standing rules the agent reads every session. |
| Context management (keep the window lean, start fresh vs continue) | Choosing a fresh session versus continuing one. The state spine from Concept 4 is the same stack, managed for you. |
| Match the model to the task | Thinner on the web: you get the surface's model, not a menu. The habit survives as "know which model this surface runs." |
| MCP, connecting a system of record | Connectors, exactly. Concept 6. Same standard underneath, a different catalog on each side. |
| Skills (packaged, reusable know-how) | On eligible plans, both families let you create a Skill from chat, build one in an editor, or upload a package with instructions, resources, and code. The format transfers. |
| The verification loop (attempt, check, fix, repeat) | A scheduled report that checks a condition and tells you what changed. Concept 9's ceiling. You get the check, run for you. You do not yet get the auto-fix. |
| Prompt injection, context is the door | Concept 6's untrusted-content rule, word for word. The risk and the habit are identical on any surface. |
Transfers in a weaker form:
| That course teaches | On the web, the limited version |
|---|---|
| Slash-commands and the runtime around a Skill | Skills themselves transfer (see above). What stays weaker is the rest of the coding-agent setup: authored slash-commands, and your control over the runtime a Skill runs in, its lifecycle hooks, model routing, filesystem, and enforcement layer. You get the Skill, not the machine it runs on. |
| Subagents (a separate worker with its own context window) | The web surface may fan a big task into sub-steps on its own, but you do not author a subagent with a chosen model and a restricted toolset. You get the vendor's orchestration, not your own. |
| Resume, undo, rewind | Sessions resume. But there is no /rewind to a prior step and no git-backed /undo of the agent's edits, because the work did not happen in your repo. Your undo is "keep the old file in tier 3." |
Does not transfer, and this is the point:
| That course teaches | Why the web cannot do it |
|---|---|
| Hooks and plugins (a rule enforced in code, every time) | A hook is code that runs on your machine to block or check an action. The web surface does not run your code or expose these lifecycle events. This is the single clearest "leave the browser" line in the whole course. When you need a guarantee the model cannot talk itself out of, you need a harness you built. That is Harness Engineering. |
| Working on a local repo, terminal commands | A browser-only session runs on the company's servers, not your disk. On its own it does not open your terminal or edit your local project. A desktop bridge can lend limited local access, but the terminal-and-repo workflow is the local tools' home. This is Concept 2, restated: the runtime is remote. |
| Cost control by routing models (plan on a frontier model, execute on a cheap one) | The plan-with-strong, execute-with-cheap split needs two models you choose and a tool that lets you swap them mid-task. The web surface picks the model for you. |
The honest summary. If your work is documents, connectors, and scheduled reports, the web surface covers most of what the Agentic Coding course would give you, under different names. The moment your work touches your own code, your own files, or a rule that must be enforced in code, you have found the edge of the web surface. That edge is not a flaw. It is the doorway to the next courses, and you now know exactly where it sits.
Appendix B · Cowork and OpenWork, on the web
This one is different from the others. The Cowork & OpenWork course is the closest relative of this course. It teaches the same kind of general-agent co-worker, aimed at the same knowledge workers, built on the same delegation loop. The difference is the runtime. That course teaches the two products on your desktop: Cowork inside Claude Desktop, and OpenWork, its open-source twin. This course taught Cowork on the web. Same family, different home. So the map here is not "how much transfers." Almost all of it transfers. The map is "what the desktop gives you that the web does not, and why."
Transfers cleanly, because it is the same product family:
| That course teaches | On the web, it is |
|---|---|
| Delegate, don't query (a co-worker you assign) | Concept 1 and 8, word for word. The single most important habit, and it is identical on any surface. |
| The task loop (brief, plan, approve, execute, review) | Your delegation loop from Concept 8. Same six steps, same intercept at the plan. |
| The plan is the leverage | Concept 8's core, and the reason the delegation-loop figure highlights the plan step. |
| Connectors as a trust lever (narrowest scope, read is not send) | Concept 6, exactly. Same connectors, same scope discipline, same "read scope is not send scope" rule. |
| Approval modes (ask before acting, act without asking) | Concept 7's phone gate. The web routes the same approval to your phone instead of an inline card. |
| Skills (a saved playbook the agent picks by description) | Cowork on the web carries the same Skills system: the catalog, /skill-creator, and the SKILL.md format are the product's, not the desktop's. This is the one place the web surface is stronger than the appendices above suggest. |
| The autonomy ladder (climb one rung per task type) | Concept 8 and 9's discipline: never schedule what you would not walk away from. The ladder is about trust, not about which surface you are on. |
| Prompt injection, untrusted content | Concept 6's untrusted-content rule. The vendor-PDF-with-a-hidden-instruction story applies identically on the web. |
| Scheduled tasks (Cowork's built-in cadence) | Concept 9. Cowork's /schedule and the Scheduled view work the same from the web. |
| The layered instruction stack (global, folder, session) | Concept 4 and 6: global settings, a Project's instructions, and the session prompt. The "folder" layer becomes the Project layer. |
Transfers, but the web changes the shape:
| That course teaches | On the web, the difference |
|---|---|
| The three trust levers: folders, connectors, approvals | Two of the three are the same. The first one changes. On the desktop you grant access to a local folder. On a browser-only session there is no local folder to grant. Your working area is the task filesystem and platform storage from Concept 5. The scope discipline survives, but "make a dedicated working folder on your disk" becomes "keep work in its own Project." (A desktop bridge can reach local folders, but that is the desktop app's job, not the tab's.) |
| Sub-agents (parallel workers on a batch) | Cowork on the web may still fan a batch into parallel workers on its own. What you lose is the desktop's fuller visibility into each worker, and any control that depends on local files. The pattern survives, the local-file version of it does not. |
Persistent workspaces (a folder plus a CLAUDE.md) | Becomes a Project plus its saved instructions, from Concept 6. Same idea, no folder on your disk. The context file becomes the Project's instruction field. |
| Model routing (strong model to think, cheap to plumb) | Thinner on the web, exactly as in Appendix A. You get the surface's model picker per task, not OpenWork's full provider choice. |
Does not transfer, and this is the desktop's whole reason to exist:
| That course teaches | Why the web cannot do it |
|---|---|
| Local files as the execution surface | This is the heart of the desktop course. The agent reads and writes files in a folder on your machine: your matter folder, your close-cycle folder, your campaign folder. A remote web session runs on the company's servers and does not reach your local drive on its own. This is Concept 2, and it is the single biggest reason the Cowork course exists as a separate, desktop course. |
| OpenWork at all (the open-source, bring-your-own-model twin) | OpenWork is a desktop app you install, pointed at a model provider you choose, with your files staying on your machine. There is no web version of that trade. The open path is a later topic, Concept 11 names it, but it is not a browser surface. |
| "Local-first" privacy (your files never leave your machine) | On the web, the file content the agent reads is on the company's servers by definition. The desktop's core privacy story, your files stay local, cannot exist on a remote surface. For regulated data this is decisive, and Concept 10 already drew that line. |
| Cowork plugins as role bundles (Legal, Finance, Sales) | The desktop course's plugins bundle skills, connectors, slash commands, and sub-agents into a role. Whether the full plugin system is available from the web is exactly the kind of weeks-old detail to check on the live pages, but the desktop is where it was built to run. |
| Backup-based recovery (Time Machine, git, Drive history) | The desktop course's recovery story is "your local backup rolls the file back." On the web there is no local file to roll back. Your recovery is Concept 5's discipline: keep the prior version in tier 3. |
The honest summary. The Cowork course and this course are two doors into the same room. If your work is documents and connectors and you want the lowest-friction start, the web surface gives you most of that course today, including its Skills system. The moment your work must touch files on your own machine, or must keep your data off a vendor's servers, or must run through OpenWork's own-model path, you need the desktop. That is not a limit of the web. It is the reason the desktop course is the next course: it is where you go when the work comes home to your machine.
Appendix C · Loop Engineering, on the web
The Loop Engineering course teaches you to build a system that prompts your agents for you: it starts on its own, does the work, checks the result, remembers what it did, and only calls you for the choices that need a person. It teaches this in Claude Code and OpenCode. It also uses the exact six-part shape this course borrowed as its reading lens: a heartbeat, four working parts, and a spine.
Here is the honest split. That course draws this line itself. It has a whole section titled "where can a loop run?", and its answer is blunt: the plain chat box cannot run a loop, but Claude Code, OpenCode, and Cowork can. So the web surface sits in the middle. It can fire the simple heartbeats. It cannot do the engineering that makes a loop trustworthy when it runs for real.
Transfers, in a simple form:
| That course teaches | On the web, the simple version |
|---|---|
| The scheduled heartbeat (run every morning, laptop off) | Concept 9, your scheduled tasks. This is the one heartbeat the web does well. A report that fires on a clock is exactly what Cowork's /schedule and ChatGPT Work's Scheduled Tasks give you. |
| The event heartbeat (react when something arrives) | Partly. ChatGPT Work's Scheduled Tasks can watch for a change, which is a light form of an event trigger. What you do not get is the course's GitHub-event and API-trigger machinery. |
| The spine (memory between runs, so today builds on yesterday) | A weak form. Your account keeps sessions and Projects, so some memory carries. But you do not get the course's real spine: a progress.md and rules file in a repo that every run reads first and updates last. |
| Skills (knowledge written once, read every run) | Both families carry packaged Skills on eligible plans, as Appendix A noted. So the "no run starts from nothing" part transfers on the web, on either side. |
| The heartbeat menu (does the task end, repeat, or happen once?) | Concept 9's own check-yourself. The discipline of picking the lightest loop is surface-independent. It is a way of thinking, not a command. |
Does not transfer, and this is what the course is really about:
| That course teaches | Why the web cannot do it |
|---|---|
| The maker-checker split (one agent writes, a separate agent grades) | This is the course's single most important idea, and the web cannot do the real version. On the web you get the surface's own run-until-done, where the vendor decides "done." You do not author a separate checker agent with its own model and a written rubric. The verification loop from Appendix A returns here, and hits the same wall. |
| Worktrees (isolation, so parallel agents do not collide) | A worktree is a separate git checkout on your machine. There is no local repo on the web, so there is nothing to isolate. This whole concept assumes the local file system the web does not have. |
The spine in a repo (progress.md and a rules file the loop reads and writes) | The real spine lives as files in your own repository, read at the start of every beat and updated at the end. The web session's memory is the vendor's, in the vendor's format. The course's "no spine, no loop" rule is exactly why serious loops need a tool that owns a repo. |
/goal, /loop, capped shell loops (run-until-done you control) | These are Claude Code commands and OpenCode shell patterns. The web surface gives you the vendor's version of run-until-done, not the course's, where you set the stopping condition, the retry cap, and the no-progress check. |
| Dynamic workflows (write the whole orchestration as a re-runnable script) | This is the deepest form of the loop's body: many subagents, checked and capped, packed into one script. It is Claude Code only even among the local tools. It is far beyond any web surface. |
| Cloud Routines and GitHub Actions (the unattended runtime) | The course's real unattended heartbeat runs on Anthropic's Routines or GitHub's runners, against a repo, with branch rules and run caps. The web's scheduled task is a lighter cousin: it reports, it does not open a reviewed pull request to a claude/ branch. |
The honest summary. The web surface can run the shape of a loop's simplest heartbeat: a scheduled report that fires while you sleep. That is real, and for many people it is enough. But Loop Engineering is not mainly about the heartbeat. It is about the parts that make an unattended loop safe: a separate checker, isolation, a spine you own, and stopping conditions you control. Every one of those needs a tool that owns a repo and runs your code. So this appendix marks the cleanest promotion in the whole section. When your scheduled report needs to become a loop you can trust to change things while you sleep, you have outgrown the web surface, and Loop Engineering is the course that meets you there.
Appendix D · Harness Engineering, on the web
This is the appendix the whole course has been pointing at. Back in Concept 3, and in the harness-war note, this course told you the split. On the web you rent a finished harness. The later courses teach you to build one. The Harness Engineering course is where that building happens. It teaches the layer around the model that turns raw intelligence into an agent you can trust: everything that decides what the agent may do, what it knows, how its work is proven, and what happens when it goes wrong.
So this is the appendix with the sharpest line of all. Almost none of the building transfers to the web. But the course's way of thinking, its five verbs, transfers completely. It is the best lens a web user has for one thing: seeing what the rented harness does for you, and what it does not.
The five verbs, as a lens (this transfers, as thinking):
The course organizes everything a harness does into five verbs. On the web you do not build any of them. But you can see all five, and knowing them tells you what you are trusting the vendor to do.
| The verb | What it means | On the web, who does it |
|---|---|---|
| Constrain (limit what the agent may do) | Permission rules, deny lists, sandboxes | The vendor, for you. Your connector scopes and approval mode (Concept 6 and 7) are the small slice you control. |
| Inform (give it what it needs) | Rules file, skills, tool design | Partly you. A Project's instructions and packaged Skills (on both Cowork and ChatGPT, on eligible plans) are your inform surface. The rest is the vendor's. |
| Verify (prove the work before it counts) | Hooks, tests, typed output | The vendor's built-in run-until-done. You cannot add your own hook or check. |
| Correct (recover, then fix the system) | Checkpoints, the ratchet | The vendor's. Your only "way back" is Concept 5's tier-3 copy. |
| Escalate (send it to a person) | The human gate, loud logs | Shared. The phone gate from Concept 7 is your escalation surface. The logs are the vendor's. |
That table is the honest picture. Two of the five verbs give you a real slice on the web: you inform through Projects and packaged Skills, and you sit at the escalation gate through your phone. The other three, the ones that make an unattended agent safe, are done for you, in ways you cannot see or change.
Does not transfer, because building the harness is the whole course:
| That course teaches | Why the web cannot do it |
|---|---|
| Permission rules (allow, ask, deny, by blast radius) | A deny rule is a line in settings.json or opencode.json that the tool enforces. The web gives you an approval mode, not a rule language. You cannot write "deny reading .env" on a web surface. |
| The core rule: a guardrail lives in the harness, never in the prompt | This is the course's most important sentence, and it is exactly what you cannot act on from the web. To move a rule out of the prompt and into an enforced layer, you need access to that layer. The web surface does not expose it. On the web, your "guardrails" are the vendor's, plus whatever you can say in a Project's instructions, which the course would call a request, not a guardrail. |
| Sandboxes (filesystem, network, and branch fences) | A sandbox is an OS-level wall around what the agent can reach. It assumes a machine you control and a runtime you can fence. The web session runs on the vendor's servers, inside the vendor's sandbox, on terms you cannot set. |
| Hooks (code that runs automatically before or after an action) | A hook is your code, run by the harness at a fixed moment, that can block or check an action. The web surface does not run your code. This is the same wall Appendix A hit, seen from the harness side: the clearest single reason serious control needs a local tool. |
| Typed output (a machine-checkable verdict you validate) | This is you writing a validator that the loop runs before it trusts a result. It needs a runtime you control. The web gives you the vendor's verification, not a place to add your own. |
| The ratchet and the four failure classes (turn every mistake into a permanent fix) | The ratchet writes each lesson into a harness surface you own: a rule, a hook, a fence. On the web there is no such surface to write to. You can learn the habit of classifying failures, but you cannot install the fix where the course installs it. |
| The inner/outer split, observability, harness coupling | These are the disciplines of an engineer building and tuning a harness over time. They assume you own the harness. The web user owns none of it, by design. That is the trade the harness-war note already named: you rent, so you do not tune. |
The honest summary. Harness Engineering is the sharpest "leave the browser" course in the section, and the course this one has been pointing at since Concept 3. Its whole subject is the layer you rent on the web and build on the desktop. You can carry one thing across the line today: the five verbs, as a lens for seeing what your rented harness does for you, and the rule that a real guardrail is enforced, not requested. But the moment you need to set a guardrail, write a deny rule, add a hook, fence a sandbox, or ratchet a fix into place, you have reached the exact edge this whole course has been mapping. On the web you trust the harness. In this course you build it. That is the difference between renting the box and engineering it.
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 "you need a repo and a shell" course in the section. Its whole method is a folder of files, a runner script, and jq. None of that machinery exists on the web. But the course also teaches a way of seeing measurement. That way of seeing changes how you read any agent's output, including a web agent's, and it transfers completely.
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. The web gives you the vendor's checker, and you cannot calibrate it. So you stay the human calibration: spot-check its verdicts yourself, especially early. |
| 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, because building an eval suite needs a repo and a shell:
| That course teaches | Why the web cannot do it |
|---|---|
| The golden set (a version-controlled folder of case files) | Cases are JSON files in a repo, reviewed and dated like code. There is no repo on the web to hold them, and no place to version them. |
The runner (claude -p / opencode run in a shell loop with jq) | The whole runner is headless command-line execution and shell grading. The web surface runs neither your shell nor your scripts. 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. On the web the judge is the vendor's, sealed. You cannot run the protocol against it. |
| The regression suite and CI gate (re-run on every change, fail below baseline) | This is an eval job wired into CI with branch protection and a committed baseline. Every piece of it, CI, branches, baselines, is a repo tool the web does not have. |
| Drift watching on a schedule (nightly runs, alert on a drop) | The course runs the full suite as a scheduled loop against a baseline. The web can schedule a report, but it cannot run a suite against a committed baseline, because there is no suite and no baseline to hold. |
| Goodhart's law defenses (sealed hold-outs the agent never sees) | Hold-outs are cases kept in a folder outside the agent's reach. This assumes a file system you control and can wall off. The web gives you neither the folder nor the wall. |
The honest summary. Trusting the Checker is the least buildable of all these courses from the web, because its entire method is files, a shell, and a repo. You cannot construct an eval suite on a web surface. But it may be the most valuable of them to read early, because its thinking needs no tools. Every time you rely on a web agent, you are trusting a checker you did not test. That course teaches you to feel the weight of that, to grade a rate instead of a run, to read severity before volume, and to stay the human calibration the vendor's checker never gets. You will build the real suite when you reach a repo. Until then, carry the mindset: a track record, honestly watched, is the only thing that earns trust, and on the web the one keeping that record is you.
Appendix F · Leaving the Laptop, on the web
This is the last course-mapping appendix, and it closes the loop with the boundary this whole course has leaned on. From the start, this course called itself the front door and Leaving the Laptop the floor plan. Now you can see why. That course answers the section's final question: not what the agent does, but where it lives and who keeps it alive. It sorts every option into four homes, and the web surface you learned here is not outside that map. It sits inside it, as a specific home with specific limits.
So this appendix is different from the five before it. The others asked one thing: what of that course can you do on the web? This one asks a different thing: where does the web surface sit in that course's map? The answer makes this whole course's place in the section clear.
The web surface, placed in the four homes:
Leaving the Laptop sorts runtimes with one question: who operates the loop, and where does the work run? Here is where the web surface lands.
| That course's home | Where the web surface sits |
|---|---|
| Home 1: your session (you own everything; dies when the lid closes) | This is the closest match for a plain web session you drive by hand. You start it, you watch it, it stops when you are done. The web version even removes the "dies when the lid closes" part, because the session runs on the company's servers, not your laptop. |
| Home 2: the cloud schedule (the clock moves out; laptop can be off) | This is where the web surface reaches its ceiling, and it reaches it well. A Cowork Scheduled Task or a ChatGPT Work Scheduled Task is exactly this home for knowledge work. The course names Cowork Scheduled Tasks as its own home-2 example. Your scheduled report from Concept 9 is a home-2 loop. |
| Home 3: the managed runtime (you send a definition; a vendor operates the loop) | Out of reach from the web as an author. Home 3 means you hand a vendor an agent definition through an API and operate the business around it. That is a builder's move, done with the SDK and platform docs, not from a browser chat. |
| Home 4: your own process (the harness as a library on your servers) | Entirely out of reach. This is Mode 2, where you write and run the runtime yourself. It is the farthest thing from a web surface in the whole book. |
What transfers, as the deciding judgment:
The course's real gift is not its mechanics. It is the four questions that pick a home, and those are pure judgment. They work on any surface, including this one.
| That course teaches | On the web, you still ask it |
|---|---|
| Q1: who is the user? (only you, or other people?) | The most important question, and fully yours to ask. If the answer is only you, a web scheduled task is often the whole answer, and the course says so: home 2 is most people's ceiling. The moment other people depend on the output, you start feeling the web's edges. |
| Q4: what does a bad night cost? (blast radius sets the speed) | This is Concept 9's report-versus-act line and the harness course's budgeting question, asked about runtimes. It is judgment, and it is yours on any surface. |
| Headless is the bridge | You cannot cross this bridge from the web, and that is the tell. Every move out of the web to a stronger home runs through a headless command (claude -p, opencode run) that the web surface does not give you. The bridge is real, and it starts where the browser ends. |
| The suitcase test (discipline travels, mechanics get rebuilt) | Your standing briefs, your Project instructions, your sense of what "done" means: those are the discipline, and they travel when you move to a stronger tool. The web surface's own buttons and settings do not. Keeping your working knowledge portable, in your own notes, is the web-user version of "the repo holds the truth." |
Does not transfer, because leaving the laptop means leaving the browser:
| That course teaches | Why the web cannot do it |
|---|---|
Headless invocation (claude -p, opencode run) | The bridge every move crosses. The web surface has no headless command, which is precisely why it cannot reach homes 3 and 4, and can only partly reach home 2. |
| The managed runtime (agent definitions, environments, sessions over an API) | A builder's runtime you drive with code and platform docs. There is no browser path to it. |
| The minimum unattended kit (idempotency, missed-run detection, concurrency locks) | Six controls you wire around a loop you operate. On the web the vendor operates the loop, so you do not build the kit, you inherit whatever the vendor provides, and you cannot add to it. |
| The arrival protocol and re-baselining (prove the move with your eval suite) | This runs your golden set in the new home, which needs the suite from Appendix E, which needs a repo. No suite, no arrival protocol. |
| Owning the runtime (homes 3 and 4) | The whole back half of the course. Owning any part of the runtime means operating infrastructure, which is the opposite of renting a web surface. |
The honest summary, and the close for the course-mapping appendices. Leaving the Laptop is the course that tells you the web surface has a place, a real one, and also a ceiling. The web is a fine home 1 for work you drive by hand, and a genuine home 2 for knowledge-work reports that run on a schedule. That covers a great deal of real work, and for many people it is the whole story. But the moment your work needs to cross the headless bridge, to run against a repo, to own its own sandbox, or to serve other people from a runtime you control, you have reached the edge this entire course has been mapping from its first page. That is the boundary this course owns with Leaving the Laptop: this course is the front door, and Leaving the Laptop is the floor plan of the whole house. You now know which rooms open from the browser, and which need you to pick up the keys and install a tool. That is the honest shape of the web surface: a real place to start, a clear place it ends, and a map of everything past it.
Appendix G · The harness war, industry-wide
The six appendices above map this course to the later courses, one each. This last one looks outward instead. Concept 3 named the harness war between two companies. By 2026 it is not two companies. It is the whole industry, and almost every serious lab has accepted the same framing: the fight has moved off the raw model and onto the harness around it.
That is the single most useful thing to see here. When you read the news, the headlines are about models: this one scored higher, that one is cheaper. But the products are competing on the wrapper. The schedule, the connectors, the memory, the gate, the runtime. This appendix is a field guide to who is fighting where. The point is not to memorize it. Products age in weeks, as this course keeps saying. The point is that the six-part shape you learned reads every one of them.
Industry snapshot — facts checked: 21 July 2026. This appendix ages faster than the rest of the course and is meant to be refreshed on its own. Many items below are announced, not shipped, and the competitive picture moves monthly. Treat this as a dated snapshot, not durable fact, and verify each row against the sources before you rely on it.
The players sort onto three battlefronts. The same rent-versus-build line from the appendices above runs through the whole industry.
Front 1: the consumer work surface (rent a finished harness). This is the fight this course is about: an agent surface next to the chat box, for everyday knowledge work.
| Player | The surface | Where it stands |
|---|---|---|
| OpenAI · ChatGPT Work | A mode inside ChatGPT | The subject of this course. Shipped July 2026. |
| Anthropic · Claude Cowork | A remote session at claude.ai | The subject of this course. Web and mobile expanded July 2026. |
| Google · Gemini Spark | A 24/7 cloud agent in the Gemini app | Announced at I/O 2026: a personal agent that runs on Google's cloud machines even when your device is off, across Gmail, Docs, and Workspace. Same shape as this course teaches, and the same discipline: its headline guardrail is that it asks before it spends money or sends an email. Early US access only as of mid-2026. The deepest pockets and the widest distribution, through Search, Workspace, and Chrome. |
| Microsoft · Copilot Tasks | A unified tasks surface in Microsoft 365 | Auto, Researcher, and Analyst modes, plus scheduling: the same parts, aimed squarely at enterprise Office work. Microsoft's advantage is distribution. As one analyst put it, the battle is no longer about who has the best chatbot; it is about who owns the work surface. |
| Meta · Meta AI | Agents inside WhatsApp, Messenger, Instagram | Fighting on reach, not capability: its harness lives where billions of people already chat, and its refreshed model line (Muse Spark) signals a serious rebuild. Meta's attempt to buy the agent startup Manus for a reported two billion dollars was unwound after Chinese regulators ordered the deal reversed in 2026, a reminder that this war has a geopolitical front too. |
Read that table with Concept 3's six parts in mind. Every one of these has a heartbeat (schedules), connectors, a run-until-done loop, a state spine, a human gate, and a body. Different names, different owners, the same shape. That is the whole thesis of this course, playing out across five companies at once.
Front 2: the managed runtime (rent the runtime, not the surface). One layer down from the consumer surface is the enterprise platform: you hand a vendor an agent definition, and the vendor operates the loop. This is home 3 from Appendix F, sold as a product.
| Player | The platform | What it is |
|---|---|---|
| Google Cloud · Gemini Enterprise Agent Platform | An evolution of Vertex AI | Build, run, and govern agents, with orchestration, runtime, memory, and governance primitives like Agent Identity and Agent Gateway. Google now routes its whole enterprise agent roadmap through this brand. |
| Microsoft · Copilot / Agent 365 | The enterprise agent layer across Microsoft 365 | The same governance push, tied to Office, Teams, and Windows. |
| Alibaba Cloud · Wukong, Qwen Cloud | An AI-native enterprise platform | Automates business tasks with multiple agents, plus a Skills portal that turns 60-plus cloud products into MCP-compatible skills. |
The through-line on Front 2 is governance, not capability. The hard problem at this layer is not making an agent that works. It is making one an enterprise can trust: identity, policy, audit. One survey found that most firms now run agents in production, but only a small fraction can actually govern them. That gap is exactly what Harness Engineering and Trusting the Checker are about, sold as an enterprise product.
Front 3: the open engine (build your own harness). At the far end from the rented consumer surface is the open-weight model: no surface at all, just an engine you put inside a harness you build and run yourself. This is the build end of the rent-versus-build line.
| Player | The engine | Why it matters here |
|---|---|---|
| DeepSeek · V4 | Open-weight, tool-native, Anthropic-compatible API | Ships pre-tuned to drop into Claude Code, OpenCode, and other coding agents. Adoption is real: within a month of release, its fast model was the majority of DeepSeek's agentic traffic, and Chinese open models passed American ones in overall token share in mid-2026. |
| Alibaba · Qwen 3.6 / 3.7 | Open-weight line (Apache 2.0), plus a proprietary "Agent Frontier" flagship | Native MCP support, a 1-million-token context, and a demonstrated 35-hour autonomous run with over 1,000 tool calls (that run is the proprietary Agent Frontier flagship, not the Apache-licensed open line). The open line is the self-hosting pick. |
| Meta · Llama | Open-weight | Still the best-known open line, though Meta's own strategy is shifting toward buying and shipping agents (Manus) over pure model releases. |
Front 3 is where your book's deepest promise lives. An open-weight engine is the only option that lets you own the entire harness: the model, the runtime, the sandbox, the data. The sources make the reason plain, and it is Concept 10 again: the hosted DeepSeek API runs in China, so for regulated or sensitive data, self-hosting the open weights is the clean path. Own the engine, own the custody. That is the far wall of the house whose front door this course opened.
The honest summary. Three fronts, one war. On the consumer surface, five companies are racing to rent you the best finished harness. On the managed runtime, the same giants are renting the harness to enterprises, and competing on governance. On the open engine, the open-weight labs are handing you the parts to build your own. The models differ. The prices differ. The distribution differs. But the shape does not. Every product on all three fronts is a heartbeat, connectors, a loop, a spine, a gate, and a body. Learn the shape once, in this course, on the gentlest surface there is, and you can read the entire industry, on any front, in any year. That is why this book teaches the shape and not the tool. The tools are at war. The shape is the peace treaty you carry between them.
Sources & further reading
Inside this book
- Skills & Connectors, the two upgrades this course runs from a browser. Foundations Course 5.
- Cowork & OpenWork, the desktop deepening of this course's delegation loop: folders, the trust levers, the autonomy ladder, regulated workloads.
- Loop Engineering, the six parts this course used as a reading lens, taught as things you design. And the safe version of schedules that act.
- Leaving the Laptop, the runtime decision behind this surface. This course is the front door, that course is the floor plan.
The products (live pages, the only current numbers)
ChatGPT Work (OpenAI):
- Launch announcement, availability, and examples: ChatGPT is now a partner for your most ambitious work (July 9, 2026).
- ChatGPT Work and Codex — how Work and Codex relate, usage structure, desktop vs web/mobile.
- Scheduled Tasks in ChatGPT — cadence types (once, schedule, event, monitor), and the Project-file caveat.
- Plugins in ChatGPT and Codex — the connector layer this course calls connectors.
- Skills in ChatGPT — packaged Skills, creation, and eligible plans.
Cowork (Anthropic):
- Use Claude Cowork on web, desktop, and mobile — remote sessions, per-surface features, and the desktop-bridge rules for local files.
- Claude Cowork architecture overview — how remote and local sessions are isolated and what each can reach.
- Schedule recurring tasks in Claude Cowork — cadence and remote execution with no device online.
- Use Claude Cowork safely — the trust model behind Concepts 6 and 7.
- Claude Code (the separate coding surface) and repo-attached cloud runs: code.claude.com/docs.
OpenWork (open-source Cowork twin):
- OpenWork — the open-source Cowork alternative (powered by OpenCode), and its documentation.
The wider industry (Appendix G), primary and launch sources:
- Google: Gemini Enterprise Agent Platform (Google Cloud, I/O 2026); the consumer agent shipped at I/O 2026 is Gemini Spark, a 24/7 cloud agent (early US access as of mid-2026).
- Microsoft: Copilot Tasks with Auto, Researcher, and Analyst modes (Microsoft 365 Copilot); the Researcher agent for the "sees only what you can" permission model.
- Meta: the Manus acquisition was ordered unwound by Chinese regulators and Meta moved to reverse it in 2026; treat any Manus-based strategy claim as unsettled.
- DeepSeek: V4 agentic adoption (OpenRouter) and V4 coding-agent integration guides.
- Alibaba: Qwen3.7, the Agent Frontier and the Qwen-Agent framework (open, MCP-native).
Verify against these pages before you rely on any number. This is the fastest-aging page in the book: both web work surfaces were launched or substantially expanded in July 2026 (Cowork's web and mobile surface expanded an existing product, and ChatGPT Work shipped as a new mode), rollouts are staged by plan, allowances are metered, and names change. Everything here was checked on 21 July 2026. Volatile facts (rollout tiers, allowances, connector actions, the Project-file caveat) also carry a source marker at the point they appear.
The one-line summary
The chat box waits and always will. What changed is the surface next to it: work that runs on the company's servers after you leave, and comes to your phone when it needs you.
The habits, in one place
Brief in full. Catch problems at the plan, not after. Send finished work to the exit (Tier 3). Schedule only work that reports, and only work you have already walked away from. Read every new product through the six parts. And take the runtime question to Leaving the Laptop before you lean on any of this.