From PDA to Co-Operating System

Module 5: From PDA to Co-Operating System

PDA is a useful frame for thinking about three kinds of work: the prompting you do to establish context and handle decisions, the delegation you do to hand off repeatable work to agents, and the automation you put in place so the right things happen without your involvement. That frame is practical and it maps cleanly onto the tools available in Claude Code.

But there’s a larger pattern that PDA sits inside, and it’s worth naming it explicitly.

The AI Co-Operating System

The phrase “co-operating system” comes from how I think about what I’m actually building when I work this way. Not an AI assistant that responds to requests. A system that runs alongside me, knows how I work, handles what it can handle, and surfaces what genuinely needs my attention.

The components of that system are:

The Obsidian vault — the knowledge base. Daily notes, project notes, research, decisions, reference material. Not just a place to write things down, but a searchable, interconnected record of how you think and what you’ve learned. The vault is where context lives that’s too detailed to put in CLAUDE.md but too important to lose.

The CLAUDE.md system — the configuration layer. Instructions, references, rules, pointers to the right files. This is what makes every Claude Code session start with the right understanding of who you are and how you work.

Skills and agents — the execution layer. The things that actually get done: drafts reviewed, emails triaged, briefings compiled, content processed. Each skill is a codified process that runs consistently.

Automation — the rhythm layer. The things that happen on schedule or trigger, without requiring your attention to start them.

Daily notes — the connective tissue. Where everything gets logged: what you worked on, what the agents produced, what needs follow-up, what you decided. The daily note is the interface between all the other components and your memory of what actually happened.

How the Daily Note Ties It Together

I want to spend a moment on daily notes because they’re genuinely the thing that makes the system coherent rather than a collection of separate tools.

Every morning, the morning-brief skill writes a summary to my daily note: calendar, pending tasks, anything flagged from email. I add my own intentions for the day. As I work, the log-to-daily skill (or just manual notes) captures what I’m doing, what decisions I made, what I learned. When the mail-triage runs, its output goes in the daily note. When I finish a piece of work, I log a summary.

At the end of the day, the daily note is a record of what actually happened — not what I planned, but what I did. Over time, those records compound into something useful: a searchable history of decisions, a way to understand where time actually goes, the raw material for weekly reviews.

The weekly review, in turn, feeds back into the CLAUDE.md system. If I notice something isn’t working — a skill that’s producing mediocre output, a workflow I keep doing manually that should be a skill, a context file that’s out of date — that gets addressed during the weekly review. The system improves.

The Compound Effect

Here’s what I’ve found to be true: the value of this approach isn’t in any individual component. It’s in the accumulation.

A single useful skill saves you time once. But a skill that’s been running for six months, refined across dozens of runs, integrated into your workflow, consistent in its output — that’s different. It’s not saving you the time of one task; it’s maintaining a quality floor across everything it touches.

A context file written once is helpful. A context file that’s been updated every time you notice Claude making a wrong assumption, every time you add a new project or tool, every time your voice or approach shifts — that becomes something Claude Code can actually rely on to work with you rather than for you.

Daily notes from last week are useful for memory. Daily notes from the last two years are a different kind of asset: a searchable record of your intellectual development, your decisions under pressure, how your thinking has changed. The vault becomes a second brain in the actual sense — not just a place to store things, but a source of context that informs how you work now.

What You’re Actually Building

There’s a version of this approach where you build a clever setup and then treat it as done. That version doesn’t compound. The tools run, they save some time, and that’s it.

The version that compounds is the one where you treat the system as something you’re continuously developing. Each week, something gets a little better. A skill gets refined. A context file gets updated. A new pattern gets codified. A piece of automation that was theoretical becomes real because you finally hit the threshold where it’s worth building.

Over a year, the difference between these two versions is significant. The first has a set of tools that mostly work and mostly haven’t changed. The second has a system that reflects how you think, how you work, and what matters to you now — not what mattered when you first set it up.

Where to Start From Here

If you’ve read this far, you probably have a sense of where the gaps are in your own setup. A few places to begin:

If you don’t have CLAUDE.md set up: that’s the highest-leverage first step. It doesn’t have to be comprehensive on day one — start with your name, what you do, your core preferences, and a reference to one or two other files. Build from there.

If you have CLAUDE.md but nothing else: pick one thing you do manually at least three times a week and build a skill for it. Run it, refine it, and see how it changes your relationship with that task.

If you have skills but no automation: look at what you invoke every single day without fail. That’s your first automation candidate. Build the launchd or cron trigger and remove yourself from the invocation.

If you have automation but no daily notes: start there. Even five minutes of end-of-day logging produces something worth having after a month. The vault, the log, the record — that’s the part of this system that grows in value the longest.

The goal isn’t to build something that’s done. It’s to build something that gets better.

---

That’s the end of PDA 2.0. If you’ve got questions or want to share what you’ve built, hit reply on any Signal Over Noise issue. I read everything.