The PDA Stack

Module 4: The PDA Stack

Prompt, delegate, and automate aren’t separate practices you switch between. They’re layers in a stack, and most real workflows use all three.

Here’s how they interact in practice:

You prompt to establish context and handle one-off tasks that require your judgement. You delegate by handing repeatable multi-step work to skills and agents so you’re reviewing outputs rather than producing them from scratch. You automate the things that don’t need you at all — moving them off your attention entirely and into scheduled or triggered processes.

A piece of writing, for example, might move through all three: you write a brief and context notes (prompt), the content pipeline drafts and reviews it (delegate), the review output lands in a folder you check each morning (automate the delivery, not the content itself). Your involvement is bookended at the beginning and end, with the middle handled by the stack.

Reading Your Own Workflows

Most people, when they first look carefully at how they work, find a strange mix: some things are genuinely manual because they need to be, some things are manual because they were never set up otherwise, and some things are half-automated in ways that create more friction than they save.

A useful exercise is to pick your ten most time-consuming recurring tasks and map each one to where it currently sits and where it could sit.

Fully manual, done by hand each time. This is fine for tasks that genuinely require your judgement, expertise, or specific relationships. It’s worth questioning for tasks that are mostly mechanical with a small judgement component — those are candidates for delegation where you review the output rather than produce it.

Manual but with AI assistance. You invoke Claude for each instance but haven’t turned it into a reusable skill. This is the right place to be while you’re still learning what good output looks like. Once you’ve done it enough times to know, turn it into a skill.

Skill-based, invoked when needed. You’ve got a skill that handles the task reliably. You run it when you need it. This is the right permanent state for many tasks — not everything needs to be autonomous.

Automated, runs on a schedule or trigger. Fires without your involvement. Right for tasks that need to happen on a rhythm regardless of what you’re focused on — briefings, health checks, routine processing.

Automated but broken or ignored. Runs but produces output nobody looks at, or produces unreliable output that requires constant manual fixing. This is the danger zone — automation that looks like it’s working but isn’t. Worth finding and either fixing or removing.

Matching Workflow to Pillar

Some tasks have a natural home in the stack. Others can sit at different levels depending on how much you’ve invested in building them up.

Writing and content work typically starts fully manual, moves to AI-assisted as you find prompting patterns that work, then to skill-based once those patterns are stable enough to codify. Full automation usually doesn’t apply to original writing — the judgement and voice requirements are too high — but the adjacent tasks (research, structure review, editing pass, social reformatting) often can be automated.

Communication processing — email triage, message summaries, flagging things that need action — is a natural fit for delegation and automation. The mail-triage skill I use runs in about ninety seconds and replaces twenty minutes of inbox management. The judgement calls it surfaces (what’s genuinely urgent, what needs a thoughtful response) stay with me; the mechanical sorting doesn’t.

Information gathering — pulling together calendar data, checking in on project status, monitoring things you care about — is ideal for automation. You care about the information, but you don’t need to be the one who fetches it. The morning-brief is the clearest example: I want to know what’s on my calendar and what needs attention before I start work, but I don’t need to be the one opening apps and copying information together.

Code and technical work sits in an interesting position. Claude Code is excellent at well-defined technical tasks — writing a specific function, debugging a clear error, generating boilerplate. For those, delegation with review is the right model. For architecture decisions, security-sensitive changes, or anything where the implications aren’t fully specified, staying manual is the right call.

Administrative and logistical tasks — scheduling, invoicing, file organisation — vary widely. Some can be fully automated (scheduled backups, regular reports), some are good skill candidates (processing a specific type of document, reformatting data), and some genuinely need you (anything involving negotiation or relationship context).

The Progression Pattern

Here’s the honest version of how things move through the stack. It’s not a clean linear progression.

Something starts fully manual. You do it by hand a few times and notice the pattern. You try AI assistance — typing a prompt each time — and the output gets better but you’re still investing in the prompting each session. You write a skill when you’ve done it enough times that the instructions feel stable. You run the skill for a while and refine it based on what it gets wrong. Once it’s reliable, you consider whether to automate the invocation or leave it manual.

Most things stop at “skill-based, invoked when needed” and that’s fine. Full automation is only worth it when the task genuinely needs to happen on a rhythm, when the setup cost is justified by the frequency, and when you trust the skill enough to not review every output.

The mistake most people make is trying to leap directly from manual to fully automated without the intermediate steps. That produces brittle automation you don’t trust, which you either ignore (wasted work) or check obsessively (no time saved).

What the Stack Feels Like When It’s Working

When the PDA stack is properly built, a working day feels different.

The things that used to take attention but don’t actually require your specific judgement — they’ve largely disappeared from view. You’re not triaging email, you’re reviewing a pre-sorted summary. You’re not pulling together your daily context, it’s waiting for you when you sit down. You’re not reformatting the same document for a different platform, the skill handles it when you invoke it.

What remains is the work that actually needs you: the decisions with real stakes, the creative work that requires your particular voice and perspective, the conversations that are genuinely about relationship rather than information exchange.

That’s the goal. Not to replace what you do, but to make sure you’re spending your time on the things only you can do.

---

The final module zooms out: how PDA fits into the bigger picture, and what you’re actually building when you build this properly.