PSA for anyone using Claude projects to compartmentalize their work: check your project settings right now.

Anthropic quietly introduced a “Use account memory” toggle inside each project. When I discovered it tonight, it was already enabled on every existing project in my account. It bridges your project’s memory with your account-level memory — the pool that loads into every regular conversation you have.

If you set up a project specifically for isolation — client work, sensitive research, creative work you don’t want bleeding into your professional conversations — that wall has a hole in it, and you were never told.

And this wasn’t a theoretical concern. I already had cross-contamination in my account memory and spent about an hour cleaning it up. I run two projects: one for serious documentation work and another for creative writing. I also use Claude for job-search work, including checking resume updates for errors or inconsistencies, reviewing professional writing, and strategy planning. Material from those contexts had ended up mixed together in account memory. Character names from stories were sitting alongside my real career history. Serious research was adjacent to parody.

Here’s what makes this worse:

Anthropic’s own help center documentation, as of tonight, still describes project memory as isolated: “Each project has its own separate memory space and dedicated project summary, so the context within each of your projects is focused, relevant, and separate from other projects or non-project chats.”

That is no longer true by default.

The toggle appears to have arrived with the September 16-17 platform unification — when Cowork merged into Chat and Projects were redesigned. There was no announcement. No migration notice. No email. No banner. The documentation wasn’t updated. It was just switched on.

(paragraph with use cases removed because it was clearly a distraction from the point)

This needed to be opt-in. Defaulting it to on, silently, on existing projects, while the documentation still promises isolation, is not a minor UX oversight. It’s a breach of the contract the feature was sold on.

I’ve submitted formal feedback. I’d encourage anyone affected to do the same (link in the comments).

edit: relates to WebUI/Chat.

Sometimes the biggest improvement isn’t optimizing the process. It’s eliminating the thing everyone assumed was permanent.

In late 1996, a temp agency placed me at CampusMCI, a college-focused ISP division of MCI Communications, as a call center support operator. I’d spent two years translating print to web for a gaming magazine I co-founded.

On my first day, I learned that each shift started with a photocopied hot list of known problems. I sat down at a VT terminal and started taking calls.

On my first break, I asked the floor supervisor, “Have you considered doing this paperless? You’d save paper and have something you can edit in real time.” She said they hadn’t. I asked if I could demonstrate something on my workstation.

She said: “Sure, go ahead.”

And that’s how the daily floor notices went digital.

It proved popular enough that a spare PC was allocated to host the pages. I started building call scripts for Tier-1 issues: winsock.dll failures, PPP authentication, modem negotiation. Step-by-step visual guides with branching logic that showed the CSR exactly what the caller was seeing… on an Intranet webpage in 1996.

Before the guides, certain calls could only go to a few people on the floor who had the settings panels memorized. After the guides, anyone could take them.

Requests for improvements started coming in. I moved the tools onto OS/2 Warp, using REXX, Java applets, and IBM’s native web server. That stack was deliberate: the applications could migrate to AIX, giving enterprise IT a straightforward code handoff if they wanted to formally adopt the system. I soon had a team assisting me in my work.

I added a shared support mailbox so CSRs could answer emails without stepping on each other. Account lookup tools. Then a call disposition form where CSRs clicked a few buttons after each call, feeding a Java applet that gave floor management real-time visibility.

Suddenly three calls about a modem not answering in Georgia weren’t just three calls. Together, they signaled that someone needed to contact the onsite team before the problem spread.

Those efficiencies helped protect our location through successive call center closures. At least three times while I was there, equipment from closed locations was consolidated into ours. That continued after I left.

I went from temp to the end of the Tier-3 escalation chain leading a team of five in about eighteen months, and it started with a question on my first coffee break.

The instinct in any operation is to optimize what’s already there. Better photocopies. Faster distribution. Neater binders. But sometimes the thing you’re optimizing around is the thing that needs to go. And the person who sees it might be the one who just walked in the door, because they haven’t learned to accept it yet.

A hundred people making the same mistake isn’t a compliance problem. It’s a systems problem.

At one global enterprise I worked with, the branding was having a crisis. Every department, operating group, and regional team had their own version of the company logo. Some had their department name under it. Some had their operating group. Some had their team. The typography was inconsistent across all of them, and no single PR agency globally was in alignment with another.

And the colors were everywhere. The same logo ranged from fire engine red to pink depending on who made it and when.

The instinct was to treat this as a compliance problem. People aren’t following the brand guidelines. Send another memo. But when I dug into it, the root cause was technical, not behavioral. There was no approved RGB color specification and no digital master artwork. The brand guidelines had been built for print. When people needed the logo for a website or a presentation, they recreated it themselves and eyeballed the color. They weren’t being sloppy. They were working without a standard that fit the medium they were working in.

As part of a global SEO and brand realignment I was leading, I brought in a designer experienced in corporate brand guidelines at this scale and commissioned a streamlined set of standards built around the company’s identity priorities. We reduced the logo sprawl down to one master logo, two operating group variants, and a handful of controlled carve-outs for specific use cases like environmental branding, and a couple of regionally required variants that I recall.

Then my team built out a digital version of the brand guidelines with downloadable master artwork for every medium: web, letterhead, presentations. For web logos specifically, we created pre-sized assets at every standard dimension with a clear rule: if you need a size we haven’t provided, you contact Corporate Communications. You don’t make it yourself.

After rollout, I’d routinely spot-check logos across the company with an image editor’s color picker. Trust the process, but verify the pixels.

The lesson is the same one that shows up everywhere in operations: when a lot of people are doing the same thing wrong, the problem usually isn’t the people. It’s the system they’re working in. Make the right thing the easy thing, and you’ll spend a lot less time chasing the wrong thing.

Listening is one of the more critical diagnostic skills you can practice.

At one company I worked with, the support team kept getting tickets for their fax modem banks… busy signals, dropped connections, intermittent failures across the document ingestion system. The issue could last for hours if not longer at times.

And every time it happened, the team would review the hardware. They would check the intake software that controlled the modems, restarting the software controllers. They would pull logs and look for errors. Even testing equipment by running extensive self-checks. They usually found nothing wrong.

Then the problem would go away on its own, and apparently this had been going on for months.

One day it happened while I was in the room. I listened to the troubleshooting for a few minutes and asked one question:

“Has anyone called the number to hear what it’s doing?”

Blank looks.

I picked up a phone and dialed the line. Fast busy tone. Beep beep beep.

“The problem isn’t here. It’s at the exchange. Call the telco.”

An hour later the carrier opened a service investigation and found intermittent hardware failures on their end.

Months of tickets. Hours of internal troubleshooting per incident, and the final fix was simply getting it to the right people. Granted one of the guys asked me later how I knew what that kind of beep meant. I referenced past work at an ISP (oh, the skills you pick up over a career).

The instinct when something breaks is to look inward. Check your code, check your hardware, check your config. But sometimes the problem isn’t in your domain at all. And no amount of expertise applied to the wrong layer will get you there.

The diagnostic that matters most is often the simplest one nobody thought to run.

There’s a difference between managing a problem and solving it.

On a recent gig, I watched a support team chase the same category of ticket for weeks, drive space alerts on machines with 128–256GB system drives. The standard fix was to log in, clean temp files, move user data to network shares, and close the ticket. Rinse repeat. Daily ticket volume drove a quick resolution then move on.

At the management level where only the ticket class was seen there were comments of better education to the users on how to manage their data or to tell them not to keep so much work on their devices. There were also talks about larger drives or increased VM allocations. All of these are reasonable options to consider.

I looked at a handful of these systems myself and found an incorrect page file configuration in the standard deployment image. It was consuming up to 40% of the drive before the user even started working. On one system with a 128GB drive, the page file allocation alone was 96GB. Three quarters of the drive, before accounting for Windows, applications, or user data. Every machine deployed from that image inherited the problem.

In this case, one configuration fix addressed the source of the recurring tickets and freed up support time. No new hardware. No budget request.

The team handling this was working hard to help. Their cleanup work gave users enough room to get back to work. But every ticket treated as an isolated incident was another opportunity for the underlying problem to keep going. When the queue stays full, making room to investigate a pattern can be difficult. Yet that’s often where the biggest return is: asking why the same work keeps needing to be done.

A drive space alert that seemed like a generic user problem turned into a higher level technical problem, and when repeated across a fleet, it suddenly becomes a problem where you can calculate lost employee time, support overhead, and potentially an unnecessary hardware expense if resolved incorrectly.

That’s the connection I look for when I’m helping someone, and it’s been the pattern across my career. Get close enough to the systems (technical and human) to understand what’s actually happening, then connect the finding to what it’s costing the business and help deliver a solution to close the loop.

A career of work in infrastructure and technology leadership, and I still look under the hood.