How Claude Co-work Projects Fix the Context Problem

Everyone is celebrating the wrong thing about Claude Co-work. The headlines all point at autonomy, at an agent that can reach into your folders, drive your browser, and fire off tools without you hovering over it. I want to argue the opposite case. The feature that actually matters in this release is not the extra power. It is Projects, a quiet addition that finally admits something the whole industry has been dancing around: the bottleneck was never what the agent could do. It was what the agent could remember about you.

Autonomy was never the real bottleneck

For two years the pitch for every AI assistant has been capability. Look, it can write code. Look, it can browse. Look, it can now click buttons in your browser. And every time, the same disappointment followed. The tool was genuinely capable, and yet using it felt like onboarding a brilliant new hire who has amnesia every single morning. You explain your business, you get one good answer, and tomorrow you explain the whole thing again.

I have watched owners give up on AI for exactly this reason. Not because it could not do the task, but because the cost of getting it ready to do the task, every single time, was higher than just doing the task themselves. That is the honest reason adoption stalls. When the setup tax is paid on every interaction, a powerful tool becomes a slow one. So no, the frontier was not autonomy. Co-work already does things. The frontier was memory that survives from one session to the next, and that is precisely what Projects deliver.

The mess is the actual product problem

Here is the part nobody wants to say out loud. The more an agent can do, the messier it gets. A chatbot that only answers questions stays tidy because it forgets everything anyway. An agent that opens files, controls a browser, and runs scheduled work accumulates state, and state without structure turns into chaos fast. One giant undifferentiated Claude folder where your work notes, your side hustle, and your personal errands all pile together is not organization. It is a junk drawer with a search box.

Projects treat that mess as the real problem to solve, and I think that is the correct instinct. Instead of one shared space, creating a project builds a fresh folder on your device dedicated to that slice of your life. Your work context sits apart from your side project, which sits apart from your personal life. That separation is not cosmetic. When the agent is not fishing through three unrelated domains to answer one question, the answers get sharper, because the context it draws on is relevant instead of tangled.

Durable context beats clever prompting every time

The prompt-engineering crowd has spent years teaching people to phrase requests better. I will say the unpopular thing: prompt phrasing is the least durable lever you have. A clever prompt helps for one message. Durable context helps forever. The single biggest factor in getting good output from any model is feeding it the right context, and the hard part was never writing a snappy sentence. It was managing what the model knows before you type anything at all.

Projects push you toward the durable lever. You seed each one with plain markdown files describing who you are, what you value, and what you are trying to do. Markdown is the right format here, easier to work with than a PDF and more consistent for a model to read. And the rule that makes this pay off is deceptively simple: only add information that is true now and will still be true a month from now. Durable facts, not this-week noise. That is what turns a project from a one-off setup into an asset that keeps working. This is the same discipline I bring to a client's CRM and website stack, where the value is not any single clever automation but the clean, structured record that every future automation gets to build on.

Why a folder per project is the right unit

I want to defend the specific design choice, because it is easy to dismiss as just folders. A folder per project matters because it makes memory local instead of global. Each project accumulates its own custom memories, so that folder gets smarter about that one category of work over time, and your whole account does not have to absorb it. That is a real distinction. Global memory sounds appealing until you realize it means your personal preferences start leaking into your client work and your client quirks start coloring your personal answers.

Local memory keeps the learning where it belongs. The marketing project learns your brand voice. The operations project learns your weekly rhythm. Neither pollutes the other. You can also start from scratch or import a project you already use, and its markdown and memories carry over, so you are not punished for having organized your context somewhere else first. The unit of organization matching the unit of work is the whole reason this feels less like a chatbot and more like a set of specialized colleagues who each stay in their lane.

Where the skeptics have a point, and why they are still wrong

Let me steelman the objection, because there is a real one. A skeptic says this is just projects, the same feature the regular chat tools already had, rebranded inside a fancier app. Fair. The concept is not new. And a second objection lands too: setting up projects and writing context files is work, and busy owners avoid setup work, which is exactly why they never used AI well in the first place.

Both are true, and both miss the point. The concept being old does not matter when the context it lives on top of is new. Projects inside a chatbot organize conversations. Projects inside an agent organize actions, memories, scheduled tasks, and real files on your device. Same word, far bigger stakes. As for the setup tax, that is the whole argument in a single sentence. Yes, seeding a project costs you thirty minutes. But you pay it once, and it replaces the setup tax you were paying on every single session forever. Trading a recurring cost for a one-time cost is not busywork. It is the best trade in the entire workflow.

Scheduling is where the context finally pays rent

A feature that only saves you setup time is nice. A feature that then goes and does the work on its own is a different category. The reason Projects matter more than the projects in a chat tool is that they connect durable context to scheduled action. Once a task works inside a project, you turn it into a recurring one. Click schedule, pick every weekday at eight in the morning, and the task runs itself with its outputs saved back into the project. The context does not just sit there being remembered. It gets spent, on your behalf, on a clock you set.

This is the part I would underline for any owner still on the fence. Most AI wins evaporate because they depend on a human remembering to open the tool and paste the right thing. Scheduling removes the human from the loop for the tasks that have already proven themselves. A personalized news brief that pulls only what you care about, a Monday content draft, a weekly reorder check, each one runs whether or not you remember it exists. And because Claude rewrites the scheduled prompt with more detail the first time, you review it once, add your preferred sources, and it shapes every future run without you touching it again. Context that remembers is useful. Context that remembers and then acts on a schedule is the whole reason this release deserves attention.

A bakery proves the argument

Let me ground all of this in one concrete example, because the abstraction only convinces so far. Picture a neighborhood bakery where the owner does everything: baking, ordering, marketing, and staff scheduling. This is the exact person the amnesia problem punishes hardest, because they context-switch a dozen times before noon and have no time to re-explain anything.

I would set up three projects. One for daily operations, seeded with markdown on the hours, the standing menu, the staff roles, and the weekly rhythm. One for marketing, seeded with the brand voice, the best sellers, and the promotions that have actually worked. One for ordering, seeded with the supplier list and the standing par levels for flour, butter, and packaging. That seeding is maybe ninety minutes of writing down things the owner already knows by heart.

Now watch the numbers move. Before Projects, drafting a week of social captions from a blank prompt, correcting the voice, and fixing the details ran the owner close to an hour every week, and it still came out generic. With a seeded marketing project, the prompt draft this week's posts returns captions already in the bakery's voice, because the context lives in the folder, and the cleanup drops to a few minutes. Say that is fifty minutes saved on marketing alone. Add the operations project turning out tomorrow's prep list from the standing menu in seconds, and the ordering project flagging low par levels, and the weekly repeat-explaining that used to eat the owner's evenings starts shrinking. The illustrative time reclaimed climbs from roughly one hour a week early on toward five hours by week four and eleven by week twelve, as each folder accumulates its own memory.

Then the compounding step: scheduling. I would take the marketing draft that worked and set it to run every Monday morning, outputs saved inside the project, and schedule a supplier reorder reminder at the top of each week. The bakery keeps doing exactly what it did before. The only thing that changes is that the owner stops paying the setup tax every morning. That is not a productivity hack. That is the amnesia problem being solved.

The objection about lock-in, answered honestly

One more worry deserves a straight answer, because thoughtful owners raise it. If I pour my whole business context into one vendor's project system, am I not handcuffing myself to that vendor forever? It is a fair fear, and I would not wave it away. But look at what the context actually is. It is plain markdown files describing who you are, what you sell, and how you work. That is not proprietary anything. It is your own knowledge, written down in the most portable format there is, sitting in a folder on your device. If you ever moved to a different tool, those same files would carry the same value, because the asset was never the app. The asset was the discipline of writing your business down once, clearly, in a form any system can read.

That reframing is the whole reason I keep pushing owners toward this. The exercise of seeding a project forces you to articulate things you have only ever carried in your head, and that articulation outlives whichever tool is fashionable this year. You end up with a written description of your own operation that is useful far beyond any single agent. The project system is just the first place it pays off.

The move I would make this week

If you take one thing from my argument, make it this: stop chasing more autonomy and start investing in durable context. Do not try to project-ify your whole business at once. Pick the single area that drains the most of your time, create one project for it, and spend thirty focused minutes writing plain markdown about who you are, what you sell, and how you work. Run one real task by hand, confirm the output is genuinely good, then schedule it so it runs on its own and saves its results inside the project. Review the rewritten prompt once to lock in your preferences, and you are done with that area for good.

That single project will teach you more than any think-piece, mine included. The reason this connects to the rest of a business is that the same durable-context discipline is what makes every other system work. It is why a well-fed CRM and website stack follows up better, why organized customer records sharpen Facebook and Instagram ad campaigns, and why the content you write once can quietly feed SEO and organic search for years. Context, structured and durable, is the quiet asset under all of it.

You can absolutely build these projects yourself, and I would push any owner to seed their first one this week. If you would rather have someone map your specific business, write the context files, and stand up the scheduled tasks so they work from the first run, that is exactly the kind of build I do for clients, and you can bring me in to handle it.