Next Gen Zap Workflows: Building Automation in Code
Zapier’s Next Gen Zap Workflows move automation from drag-and-drop builders into TypeScript. Here’s what code-first workflows unlock, and what the learning curve looks like.
TABLE OF CONTENTS
Claude's New Memory System, Explained
Claude unified memory across Chat and Cowork with a new hierarchical architecture built on progressive disclosure. Here's what changed, why it matters, and how to get more out of it.
For months, I've been running two Claude lives.
In Claude Chat, I had a memory file that Claude maintained automatically: a single summary document with my preferences, ongoing projects, and recurring context. It worked, within its limits.
Claude Cowork had a different memory system entirely: structured files organised by project, person, and topic, maintained by the agent itself, and only stored locally on my computer. I wrote about how memory worked in Cowork back in April, calling it "an index, not a scratchpad."
The biggest problem was that the two memory systems never talked to each other. And because Cowork couldn't see Chat's memory, I had to do a round of initial setup every time I kicked off a new project: briefing the agent on who I am, what the client does, and how I like things done.
Anthropic has now unified memory across both surfaces. The architecture that made Cowork's memory so powerful (hierarchical files with progressive disclosure) is now the foundation for both products, and works across desktop, web, and mobile. The unification comes quickly on the back of Cowork's expansion to web and mobile, with some sessions still running locally on your machine if they require access to a local folder. It's the right move; users shouldn't have to think of Chat and Cowork as separate products. That friction of figuring out where to start every time you kick off a new session is gone.
So what's changed under the hood?
In Chat, Claude used to maintain memory as a single summary file that you could view and tweak in settings. It would automatically refresh this summary every day or so, drawing from the context of your recent sessions.
A single memory document wasn't ideal, though. It meant Claude had to read the entire thing even when most of the contents weren't relevant to the work or discussion at hand. The document couldn't be that long, or else it would eat up a lot of Claude's context window with irrelevant content, increasing the risk of “forgetting” or hallucination.
How it works now reminds me a lot of how Cowork used to manage project memory files on your local machine. Rather than stuffing everything into a single file, memory has an architecture now. Multiple files are organised by topic, area, and person, so Claude can review the index (like a table of contents) and then selectively read the more detailed reference files only when they're deemed relevant.
These files can also cross-reference each other. For example, an "Areas" file might cover a particular client, and it includes linked references to People files for the people involved in the project. This allows important context to live in a single file, with other files linked to it when relevant. Not having the same information duplicated in multiple files is more efficient for memory management and mitigates the risk of conflicting memories when files fall out of sync.
The new system brings the best of Cowork's memory system (the hierarchical architecture and progressive disclosure) to a cloud-first environment.
Progressive disclosure vs lazy loading
These terms come up together in AI memory discussions, and they're related but distinct.
Progressive disclosure is a design pattern borrowed from UX. It describes how you structure information into tiers of detail: a table of contents first, then chapter summaries, then full chapters. Anthropic uses this in Agent Skills, where each skill has a name and description always loaded (tier 1), a full instruction file loaded on demand (tier 2), and additional bundled files loaded only when needed (tier 3 and beyond). The agent always knows what exists without loading everything.
Lazy loading is a software engineering technique. It describes when data is fetched into memory. In web development, it means not loading images until the user scrolls to them. In AI memory, it means not loading all memory files into the context window at session start, but fetching them only when the model determines they're relevant.
Progressive disclosure is the architecture (how you organise information into tiers). Lazy loading is the retrieval mechanism (when you fetch the data). Progressive disclosure enables efficient lazy loading: the index tells the model what's available, and lazy loading is the act of only pulling in the detailed files when needed.
In Claude's new memory system, the progressive disclosure part is the architecture: topic files organised by area, person, and topic, with an index and cross-references. The lazy loading part is the behaviour: Claude reads the index first, then selectively loads only the relevant detailed files.
How to get more out of it
First, I find that I don't need to use Projects as much in Claude. Previously, I would set them up because I wanted Claude to have deep context on particular areas of work or clients that wasn't possible with the flat, single-file memory system. But that meant when working in a given project, Claude knew virtually nothing else about me or my other work if it hadn't been surfaced in that project before. With progressive disclosure, Claude can handle much more layered memory outside of projects, and projects are mostly unnecessary for my day-to-day work.
Second, I've set up a weekly Scheduled Task in Cowork to have it automatically scan important knowledge sources (Gmail, Slack, and Notion) for context that we haven't discussed explicitly but might be worth capturing in memory for future reference.
The downside of all this is that it makes Claude stickier. The more complex memory architecture makes it more cumbersome (but not impossible) to migrate to a different LLM tool while bringing along all your important context. With a single flat memory file, it was mostly a copy-and-paste job. I'm ok with this sort of lock-in, at least for now. When a change makes a product genuinely more useful, I can accept higher future switching costs as part of the trade-off.
If you're thinking about rolling out Claude across your team, or you've started but aren't sure you're getting the most out of memory, Projects, or Cowork, that's exactly the kind of setup work we do at workFlowers. It's the same approach we take with Notion and Zapier: the tool is only as good as the system around it.
Related Posts
How Claude Cowork Does My Job While I Walk the Kids to School
Five layers — files, plugins, sub-agents, memory, and scheduled tasks — that turn Claude Cowork from a chatbot into the coworker running ops before you've had coffee.
Why I Switched from ChatGPT to Claude (and Haven't Looked Back)
Skills that invoke themselves, integrations that write back to your tools, and code that works on the first attempt. Why I haven't looked back since switching to Claude.