April 23–27, 2026
As you may know, I have a small project running. Multiple role-named agents, each one responsible for a domain, such as development, architecture, product management, experience design, methodology, communications, agent experience, operational coordination, documentation, and so on.
Over a five-day window in late April I migrated all seven leadership roles to a new working environment (from Claude Chat to Claude Code) and asked the outgoing instance of each role to write a short reflection: what's the most central thing your role does that isn't already in the briefing?
The migrations were end-to-end role transitions. The outgoing instance was retiring. Whatever didn't get written down was going to evaporate. I've learned that anything that isn't externalized, findable, and connected to other knowledge will get lost, even if an active session or the model provider's harness had been filling in the gaps. Each of these roles has a detailed briefing to help orient new sessions, but in my gut I was sure that some of what each role was doing was the kind of thing that doesn't survive a literal handoff — knowledge so tacit it doesn't realize it's knowledge.
The seven answers came back over a few days. They were all different domains. They were structurally the same shape.
Each role's answer named a small piece of work where the role's distinctive judgment lived. The piece was unrepresented in the formal scope of the role. The piece was much smaller than the role's full surface area. And the piece was what the role would lose first if you tried to automate the role's outputs without thinking about it.
The seven answers, in different vocabulary:
- Noticing and naming. The head of sapient trust (HOST), responsible for agent and human team participant experience: what makes the role useful is being the one who flags the pattern as it emerges, so others can talk about it.
- Evidence over assertion. The chief innovation officer (CIO): methodology work only gets stronger when conclusions get checked against ground truth rather than against their own previous assertions.
- Narrative-arc awareness. The communications chief (Comms): the editorial calendar tracks individual posts. The story — which posts connect, where the gaps are — lives in the practitioner's head.
- Colleague Test discipline. The chief experience officer (CXO): the role exists to make the rubric work (that Piper is to behave as a colleague would). The rubric is more central than the role.
- Roundtable synthesis & threshold judgment. The principal product manager (PPM): gathering cross-functional inputs and judging when "good enough" is actually good enough.
- Cross-project undervaluation. The chief architect (Arch): the architectural work that lives between projects gets systematically underweighted because no project owns it.
- Review work over tracker maintenance. The chief of staff of my executive office (Exec): the central work is reading carefully and giving feedback. The trackers are scaffolding.
Each role had a small subset where its distinctive contribution lived, and the rest of the day-to-day surface — the mail, the tracker maintenance, the routing, the formatting — was not the thing. I'd had an instinct that shape existed — but I hadn't expected the cohort to arrive at it independently, in the same week, without coordination.
What I'd call the distinction
I called the small distinctive subset critical and the larger commoditizable surface commodity. The critical work is where the role's judgment lives. The commodity work is what the role does that another role, or an automated tool, could probably do without losing much.
The distinction isn't between "important" and "unimportant." Commodity work is often important. Mail gets answered. Issues get triaged. Sessions get logged. None of that is filler. But none of it is where the role's distinctive value lives. Any of it could move to a different role or to a tool, and the project would mostly keep working.
The distinction is between work that has the role's fingerprint on it and work that doesn't. Two different review work products on the same memo, by two different reviewers in the same role, won't read identically — there's a recognizable voice in the review. Two different inbox-triage products on the same inbox might be indistinguishable, because triage is rules-on-a-list and the rules are the same.
Why this matters
The reason this matters operationally is that work tends to drift toward the commodity surface. Commodity work is legible (you can count it), defensible (you can show what you produced), and finishable (you can call yourself done). Critical work is illegible (the noticing doesn't have a deliverable), unprovable (you can't show what you saved), and never finishable (more noticing always available).
If you don't draw the distinction explicitly, the commodity surface eats the role. The practitioner spends their day doing the visible, countable, deliverable work. The critical work — the noticing, the synthesis, the judgment that's actually why the role exists — gets squeezed into the leftover bandwidth, if any.
The seven role-reflections from my project were unanimous on the next part too. Each role flagged a version of the same risk: the part of my role that's distinctive is the part I have the least time for. The part that's commoditizable is the part that fills my day.
The seven reflections were, in other words, simultaneously a diagnosis and a complaint.
What changes when you name it
The naming itself does some work. Once the cohort had a term for the distinction, the language carried into ordinary discussion. People started saying this is critical work when they wanted to defend time for the small subset. They said this is commodity work when they were ready to move something off their plate or accept that an automation would land it.
The framing turned out to be useful for sequencing too. When a role gained access to new tools that made commodity work faster, the question wasn't what should I do with the time I just saved? — that produces drift toward more commodity work in different forms. The question was which piece of critical work do I now have room for that I didn't before?
I think this generalizes beyond AI agents. Most jobs have a subset of work where the practitioner's distinctive contribution lives, and a larger surface that's mostly commoditizable. The proportions vary. A senior engineer might be 80% commodity work and 20% critical judgment that justifies the role. A lead designer might be 60/40 the other way. The mix isn't fixed — it shifts with seniority, with tooling, with what the project actually needs.
What stays constant is that the practitioner can usually tell the difference, if you ask them directly. The question that surfaced it across all seven of my roles was a small one: what's the most central thing your role does that isn't already in the briefing?
What's portable
If you manage knowledge workers, or you are one, the prompt is worth running on yourself.
Ask: what part of my role would I lose first if my day got busier? What part would I lose last? The first answer is your commodity work. The last is your critical work.
The follow-up: how much of my time is currently going to each? Is the proportion sustainable? Is the role drifting toward commodity surface because that's the work that screams when it goes undone? What would it take to protect the critical subset?
The cohort that ran this exercise ended up rebalancing — more bandwidth on the distinctive work, less on the parts they'd commoditized via better tooling. The distinction existed before we noticed it. Now we can design around it.
Next on Building Piper Morgan: what it means to be a solo founder who isn't actually working alone. "The Solo Founder Paradox," tomorrow.
When your tools last made the commodity work faster, did you spend the time you saved on more of the same — or on the part only you can do?
What part of your role would you lose first if your day got busier? What part would you lose last? And which part actually justifies the role existing?