A friend of mine is dealing with cancer. When I started building CureCancerMagic - a care coordination app for exactly this situation - I noticed something about how information flows during treatment. Doctors send referrals. Friends text you articles. Your cousin emails a link to a specialist in another city. All of it is valuable. Almost all of it gets lost.

Sunday I built a feature called the Treasure Trove to fix that, made CompanyOS work for more than one company, and fixed an email pipeline bug that taught me something about the difference between users and contacts in care coordination software.

Things We Learned Today

CureCancerMagic’s email pipeline has a quarantine system. Each case gets a unique email address. When an email arrives, the system checks whether the sender is authorized before letting it through. Unauthorized senders go to quarantine. Sounds straightforward.

Two bugs hit on Sunday that were really the same conceptual mistake. First: emails from a patient’s oncologist were landing in quarantine. The authorization check only looked at care_team_members - platform users who had signed up and been invited to the case. An oncologist who’s been treating the patient for months isn’t a platform user. They’re a contact - someone the care team has recorded but who never created an account. The system was conflating “authorized to send email” with “has an account.” The fix was adding a second check: if the sender’s email matches a confirmed contact for that case, let the email through.

Next, when someone approved a quarantined email, it appeared in the inbox but with no AI summary, no contact extraction, and no categorization. The approval path created the communication record and stopped. It skipped the AI processing step entirely. The quarantine approval was a bypass path that re-entered the pipeline too late - at the “save to inbox” stage instead of the “process and then save” stage.

Both bugs come from the same place. A care coordination app has two distinct populations: users (people with accounts who log in) and contacts (doctors, nurses, family members, insurance reps - people who are part of the care network but will never use the app). Most SaaS apps only have users. When your system has both, every authentication and processing path needs to account for the distinction. I expect this pattern to keep recurring as CureCancerMagic grows.

Things We Did Today

CureCancerMagic is now a full application. The dashboard is organized around a case - one patient, one diagnosis - because multiple care team members need to see the same data. Inside a case: contacts with auto-extracted info from emails, an email inbox with quarantine and rejection, a communications log, tasks, a timeline, documents, reports with appointment summaries, team management, and settings.

The Treasure Trove was Sunday’s new feature. While building the email pipeline, I realized the emails contained something I hadn’t designed for: suggestions. A doctor to call. A treatment to research. A clinical trial to look into. These are the most actionable pieces of information in the email stream, and the system was burying them in the general communications inbox. The Treasure Trove pulls suggestions out automatically - the AI reads incoming emails, identifies anything that looks like a recommendation or referral, and surfaces it as a trackable item with a source contact, category, and status. Nobody has to manually enter “Dr. Smith recommended we call Dr. Jones.” The email already says that.

The other half of Sunday was CompanyOS. I wrote about the system itself yesterday. Sunday was about making it portable.

Every skill had IntensityMagic - my company - hardcoded. Help Scout inbox IDs, Linear workspaces, brand voices. Seth Levine - one of my partners at Foundry - is the first external user, and he needs it to work for a different company with different services. The architecture: each company gets its own CompanyOS clone in a separate directory, pointing to a private config repo with that company’s context. Core skills are shared via git. The reason this works is that Claude Code sessions are inherently directory-scoped. Open a terminal in ~/Code/companyos-foundry and Claude loads Foundry’s MCP servers, reads Foundry’s context, and has no awareness of IntensityMagic’s data. The isolation comes from the directory boundary, not from any access control system I had to build. Fifteen commits: parameterized 8 skills, added external config repo support, built a quick-switch command, and tightened RLS policies for open-source readiness.

Fun Things to Try

The Treasure Trove extracts suggestions from emails. The next step is meeting transcripts. Granola - the meeting recorder I use - produces full transcripts that CompanyOS already knows how to pull. “You should really talk to Dr. Jones” said in a meeting is just as valuable as the same sentence in an email.

Subscribe via RSS to follow along. The source is always on GitHub .