My Architect, part 6: the human side — WBS, Building Blocks and the User Story Map

Five parts of the series about My Architect were about the agent: memory, storage, the model, the working loop, distribution. A fair question from the reader: what is this tool for a human, other than watching the agent? I'll answer it in the first person, because I didn't start this project for an agent. I started it for myself.

The habit of thinking in blocks

I'm an architect with a TOGAF background, and I have a professional deformation: I first see any system as a set of building blocks. Not a "task list", but blocks: the payment pipeline, authorization, reporting, the provider integration. Blocks have boundaries, responsibilities and connections, and only after that comes the work that has to be done.

The WBS in My Architect maps onto this habit one to one. The upper levels of the tree are the building blocks themselves: the large parts of the system, named as entities. One level down — features inside a block; in the leaves — concrete stories. The title linter I wrote about in part 3 is not cosmetics here but that very discipline: a tree whose nodes are named "Payment pipeline" and "Session storage" reads like an architecture diagram, not like meeting minutes.

WBS as a mirror

For me, the main value of the WBS isn't even planning — it's reflection. Lay your project out as a tree and you see it whole, with all its holes. Here's a block with three levels of detail, because it has been thought through. And here's a block that is a single node with no children: I haven't looked there yet, and the tree honestly shows it. No methodology — just a picture where the emptiness is visible to the naked eye.

No staging here: the screenshot is My Architect itself, planned inside itself.

Requirements go into the same tree the moment you think of them. I look at the authorization block, remember the response time limit — and hang an NFR right on the block, without leaving the canvas. Then inheritance does its job: every story inside the block will see that requirement, including the agent when it picks the story up. A thought that used to live in a note on my phone became part of the model in ten seconds.

USM for prioritization

The WBS answers the question "what does the system consist of" but says nothing about what to do first. For that there's a second projection of the same model — the User Story Map: the backbone, the product's main activities, runs horizontally; release bands run vertically.

A demo project's USM: backbone across, releases MVP → V1.1 → V2.0 down. The cards even show the agent currently working and one task blocked.

Prioritization here is physical: grab a card, drag it from R2 to R1 — done. Not "set the priority field in a ticket", but literally move the work closer. The unplanned bucket at the bottom is an honest list of everything that hasn't been scheduled at all, and its size sobers you up better than any report. When I plan the next release, I spend about twenty minutes in the USM: I move cards, watch the bands fill up, and walk away with a plan that doesn't need to be transferred anywhere — it's already in the model.

A picture that works

Now the main thing, the reason it all started. I was drawing WBS trees and story maps long before this project — in Miro, in draw.io, on whiteboards. All those pictures share one fate: the workshop ends, and the diagram starts going stale. A month later it lies; three months later you're embarrassed to show it.

In My Architect the diagram is the model the agent executes. The same nodes I was moving around on the canvas are the backlog: the agent takes the leaves via get_next_task, moves statuses, closes blocks in a cascade. Drag a story into another release — and in its next session the agent will pick up different work. The agent closes a task — and the node on my canvas turns gray, right during its session.

A diagram nobody executes is a wish. A diagram an agent works against is a plan.

That's why it doesn't go stale: it has nowhere to. Any divergence between the picture and the code is a divergence between the agent's backlog and the code, and for that there's reconcile from part 4.

My actual loop

Here's what it looks like. In the morning — /my-architect:progress: percentages per release, what's in progress, what's next. If ideas have piled up — ten minutes on the canvas: new nodes into the right blocks, a couple of requirements, something moved between releases. Then the agent works while I go about my own business, occasionally glancing at the tree turning green. In the evening — a look at the USM: what got closed, what got blocked and why.

I stopped being a dispatcher who retells context to the agent. I stayed an architect: I think in blocks, set priorities, capture requirements. Execution is not my job — and for the first time, that's actually true.

Try it and tell me

My Architect is open at my-architect.app: an account, a token, two commands in Claude Code — the setup is described in part 5. Right now the feedback I value most comes from two kinds of people: architects with their own decomposition habits, and those who run agents on long projects. What's awkward, what's missing, where the model argues with your practice — write to me, it shapes the roadmap directly.