Designing the Work.
The previous chapter designed the system — information flows, roles, the Hybrid Accountability Chart, governance. This chapter designs the work itself. Work Deconstruction classifies every task in the constraint workflow. The Design Brief captures the full specification. A prototype proves the design works before Build begins. Nothing enters Build until the Design Gate is locked — five items, all checked.
The previous chapter gave you the system: the information flow, the accountability structure, the governance framework, the Human Orchestrator. This chapter is where you design the actual work — decomposing the constraint workflow task by task, populating the chart with real entries, building a Design Brief, prototyping, and locking the gate that separates Design from Build.
Work Deconstruction.
Work Deconstruction is the method. Pull the actual accountability list for a role — not the job description, which is always cleaner than reality, but the real list of things that person touches every week. Then go task by task and classify each one using four categories. For every task, also document the source inputs (where the data comes from — which system, which person, which document) and the outputs (where the result goes next). If you have done the Source work properly, you already know these. Writing them into the deconstruction makes the information flow from the previous chapter concrete at the task level.
For every task, ask one sorting question: “If I gave a well-briefed agent this task with the right data, would the output need human review every time, or only when something goes wrong?” If every time: agent-assisted. If only on exceptions: fully automatable. If the agent adds no value and it’s just a handoff: workflow automation only. If the answer depends on who the client is, what happened last week, or a judgment call with no clear rule: human judgment required.
“Agent-assisted” is where most things start. “Fully automatable” is where they move after the agent has proved itself over multiple sprints. Autonomy is earned, not assigned.
The classification is the work. Most accountabilities, when deconstructed this way, have a different shape than the leader assumed. The “judgment-heavy role” turns out to be 70% routing and documentation, while the “low-skill operational task” depends on a relationship the agent can’t replicate — and you won’t know which is which until you decompose the role honestly, task by task.
List every task in the constraint workflow. Sort each one into the four categories. Count the tasks in each bucket. If more than half land in “Human judgment required,” challenge each one: is this genuinely judgment, or is it judgment because nobody has written down the rules? The exercise takes sixty to ninety minutes for a real role. Do it on paper or in a shared doc.
Once the deconstruction is done, the results flow directly into the Hybrid Accountability Chart you built in the previous chapter. Each classified task maps to a chart entry — the function, the agent team, the supervisor, the autonomy level. Work Deconstruction is the thinking. The chart entries are what makes the thinking durable and actionable for Build.
The role, deconstructed.
The project coordinator story from the opening of the previous chapter is also the clearest illustration of what Work Deconstruction produces — because we ran it in real time, on a real role, with a pending hiring decision on the table.
We pulled her accountability list. Not her job description — those are always cleaner than reality. Her actual list: the items she owned, the work she touched every week. Start there with your own role: write down every accountability, not the aspirational version, but the actual weekly work. Then run every item through the four-category classification. Every item gets a label. Does this require judgment — the kind that depends on knowing the client, knowing the history, reading a room? Does it benefit from agent assistance, with a human reviewing every output? Or is it fully automatable — high-volume, well-defined, clean inputs, predictable outputs?
The classification took ninety minutes. What it revealed: a substantial fraction of her work was routing and documentation. Scheduling client check-ins. Updating the project tracker after calls. Generating the weekly status reports from data that already lived in the CRM. That work looked like operations because it happened inside the operations function — but it wasn’t operations judgment. It was operations administration. The kind of work that eats a skilled person’s hours and leaves them with no time for the parts of the role that actually require them.
When you do this on your own role, look for the same pattern: what percentage of your weekly hours go to tasks that are well-defined, data-driven, and repeatable? That percentage is your design opportunity.
That work became a designed agent team. It landed in the Hybrid Accountability Chart as an AI-assisted entry — she reviewed every output to start, the right call when the team is new and trust hasn’t been established. The remaining accountability — the client relationships, the judgment calls, the situations that required someone who knew the history — stayed with her. Her role became more strategic, not because we gave her a new title, but because we gave her back the hours that the low-judgment work had been consuming.
The junior coordinator listing was never posted. One row in the chart replaced a $24K hire.
Populated example: Meridian Manufacturing quoting
Here’s what a completed Work Deconstruction looks like for the Meridian quoting constraint — where Elena Ruiz, the VP of Operations, was the sole bottleneck for every quote. She spent fifteen hours a week building quotes from scratch because she was the only person who held the customer-specific pricing, material lead-time knowledge, and historical job context. The estimated annual cost of the bottleneck was $558K in lost revenue, misallocated time, and floor underutilization.
| Task | Category | Source / Input | Output / Destination | Rationale |
|---|---|---|---|---|
| Receive RFQ, log in CRM | Workflow automation only | Inbound RFQ email from client | CRM record in HubSpot, triggers quoting workflow | Routing problem. Standardized intake form auto-creates the CRM record. No agent needed. |
| Pull customer history from HubSpot | Fully automatable | HubSpot CRM (customer records, win/loss data) → Quote Research Agent | Customer profile, past jobs, pricing terms → Quote Pricing Agent | Structured lookup. Agent queries CRM and returns customer context. Elena audits weekly. |
| Look up material pricing in JobBOSS | Fully automatable | JobBOSS ERP (materials database, supplier pricing) → Quote Pricing Agent | Material costs, lead times, out-of-stock flags → Quote Pricing Agent | Structured lookup against known tables. Agent retrieves current pricing and flags anything unavailable or above threshold. |
| Cross-reference Customer Notes.xlsx for pricing exceptions | Agent-assisted | Customer Notes.xlsx (112 validated rules) → Quote Pricing Agent | Applicable exception rules with confidence flags → Elena for review | 112 customer-specific pricing rules — some simple discounts, others complex terms with context the spreadsheet doesn’t fully capture. Agent applies documented rules. Elena reviews every output until the exception set is fully validated. |
| Calculate final price and assemble quote | Agent-assisted | All upstream agent outputs + Dave’s labor hour estimate + rate card → Quote Assembly Agent | Draft PDF quote in Meridian’s standard format → Elena’s review queue in HubSpot | Agent assembles the complete quote from research, pricing, and labor inputs. Elena reviews every draft — fifteen to twenty minutes instead of building from scratch in three hours. |
| Review and approve quote | Human judgment required | Agent-assembled draft quote → Elena | Approved quote → Ty for delivery | The design decision that makes everything else work. Elena holds final authority on every number. Her judgment catches what the exception rules miss — strategic account considerations, spec ambiguities, margin calls on edge cases. |
| Deliver quote to customer | Human judgment required | Approved quote PDF → Ty via HubSpot sales queue | Quote delivered to customer, follow-up tracked in CRM | Customer relationship. Ty reads the negotiation, knows the account history, decides timing and positioning. The handoff from Elena to Ty is structured — the approved quote lands in his CRM queue with context notes. |
Task count: Human judgment required — 2. Agent-assisted — 2. Fully automatable — 2. Workflow automation only — 1. The role that felt like “Elena’s judgment” was roughly 65% data retrieval and document assembly — work that required her access, not her judgment. The remaining 35% stayed with her because the deconstruction made clear that the judgment was irreducible.
The Hybrid Accountability Chart entries that came out of this deconstruction:
| Role / Function | Agent Team | Human Supervisor | Level |
|---|---|---|---|
| RFQ intake and CRM logging | None (workflow automation) | Ty Banfield (Sales Lead) | N/A |
| Customer data retrieval and history matching | Quote Research Agent | Elena Ruiz (VP Ops) | AI-Assisted |
| Material and labor pricing assembly | Quote Pricing Agent | Elena Ruiz (VP Ops) + Dave Kowalski (labor estimates) | AI-Assisted |
| Draft quote generation and review | Quote Assembly Agent | Elena Ruiz (VP Ops) | AI-Assisted |
| Quote delivery and customer follow-up | None | Ty Banfield (Sales Lead) | N/A |
Every row has a name. Every agent team has a supervisor. All agent outputs start AI-Assisted — Elena reviews every quote. The accountability that stays human stays human — not because they couldn’t try to automate it, but because the deconstruction made clear that the judgment is irreducible.
The difference between AI-Assisted and Automated is the human’s role, not the review frequency. AI-Assisted: the human reviews every output and holds final authority. Automated: outputs ship, and the human’s role shifts to handling exceptions, monitoring aggregate quality, and making final decisions on edge cases. If you’re not sure which to pick, start AI-Assisted. Moving toward Automated is a promotion the agent earns — it happens when the human is rubber-stamping more often than correcting. Moving the other direction means something already went wrong.
Seeing the design.
A good workflow design is legible — you can look at it and trace the path from input to output, see where humans decide and where agents execute, and spot the gaps before Build discovers them for you.
The right visualization depends on what you’re designing. You don’t need every tool for every sprint, but you should know what’s available and reach for the right one.
Swim lane diagrams are for mapping information flows between humans and agents. Draw two lanes — one for human work, one for agent work. Walk the workflow from trigger to output and draw each step in the lane where it happens. Every time the work crosses from one lane to the other, that’s a handoff. Every handoff is a design decision: what format does the output need to be in? Who reviews it? What happens when the handoff fails? Swim lanes force you to answer those questions because the crossing points are visible. If your swim lane diagram has fifteen crossings for a six-step workflow, you’ve designed something that will be fragile in production. Simplify before you build.
Flowcharts are for mapping decision logic. When the workflow has branching paths — if the quote is above a dollar threshold, route to VP; if the customer segment is new, flag for manual review — a flowchart makes the logic inspectable. You can build these in any diagramming tool — Lucidchart, Miro, or even a whiteboard photo. Mermaid is also worth knowing about: it’s a text-based diagramming format where you describe the logic in plain language and the tool draws the diagram. Every major AI assistant can generate Mermaid from a description, and it renders in most documentation tools. You can describe your workflow to an AI assistant and get a Mermaid diagram back in the same conversation. That’s useful because the diagram becomes a checkpoint — if the flowchart doesn’t match what you intended, the design has a gap you can fix now instead of in Build.
Visual design tools — Figma, Claude’s artifact system, Excalidraw — are for when the workflow produces something a stakeholder needs to see. If the agent team is generating customer-facing quotes, draft what the quote looks like. If it’s producing reports, mock up the report format. The visual artifact gives the stakeholder something concrete to react to, which is faster and more honest than asking them to imagine the output from a written spec.
Pick the workflow you’re designing. Draw a swim lane diagram with two lanes — human and agent. Map every step. Count the handoff crossings. If the count is higher than the number of steps, redesign the handoffs before moving to Build.
The Design Brief.
Before you prototype, you need a document that captures everything the design has decided. The Design Brief is that document. It is the artifact that comes out of the Design stage — a comprehensive specification that reflects the design decisions, the stakeholders, the systems, and the constraints that Build will execute against.
A Design Brief includes:
- Workflow summary. The information flow from trigger to output, with each step, handoff, and decision point named. This is the swim lane or flowchart from the previous chapter, translated into written specification.
- Stakeholders. The Human Orchestrator, the team members whose roles change, the downstream consumers of the agent team’s output, and anyone with approval authority.
- Systems. Every system the workflow touches — CRM, ERP, project management tool, communication platforms — with the specific data each system provides or receives.
- Data requirements. What data the agent team needs, where it lives, what format it arrives in, and what happens when it is missing or malformed.
- Success criteria. The measurable outcomes from Signal that this design is intended to move. Not vague improvement — specific targets the sprint will be measured against.
- Constraints and guardrails. The governance decisions from the previous chapter: data access boundaries, action permissions, escalation paths, quality monitoring cadence, kill switch conditions.
- V1 artifact description. What will the first working version of this workflow actually produce? Is the output an interface? A formatted document? An automated pipeline? A dashboard? Name the artifact. If you cannot describe what the first version looks like, the design is not finished.
The Design Brief connects directly to the Build Spec in the next chapter. Where the Design Brief says what the system should do and why, the Build Spec says how — at the level of detail a developer can execute against. A gap in the Design Brief becomes a question in Build. Close the gaps here.
Prototype before you build.
Design is not finished when the workflow looks right on paper. It’s finished when you’ve confirmed that the people who’ll use the output understand what they’re getting and agree it solves the constraint.
Run the agent workflow on one real input. Take an actual bid request from last week and run it through the designed quoting workflow. Show the Human Orchestrator the draft quote the agent produced. Show the team members who will use it the handoff format. Ask two questions: Does this output look right? Does this workflow match how you’d actually use it?
The answers will surprise you. The quote format makes sense to you but confuses the sales team. The handoff between the agent and the human reviewer doesn’t include a field the reviewer needs. The escalation trigger fires on cases that don’t actually need escalation. Every one of those findings is a design fix that costs minutes now and would cost hours in Build.
Stakeholder surveys work here too — especially when the agent team’s output reaches people outside the immediate workflow. If the quoting agent produces something a customer will see, ask three customers what they’d think of the new format. Five responses are enough to catch the design gaps that internal review misses.
Constant prototyping is the discipline. Not one big reveal at the end of Design, but a steady loop: design a piece, prototype it, get feedback, adjust. The Compound Sprint is short enough — two weeks for most teams — that this loop runs naturally if you start prototyping early. Teams that wait until the design feels “complete” before testing it are the teams that discover in Build that the design doesn’t match reality. Test early. Adjust while adjusting is cheap.
Design is the gate.
Nothing past Design begins until Design is locked. That’s not bureaucracy. It’s the structural reason Build moves fast when other approaches stall.
Teams that find Build slow or complicated are almost always teams that moved through Design too quickly — they discovered mid-build that there were decisions nobody had made, handoffs nobody had specified, supervision arrangements nobody had named. Every one of those discoveries is a piece of Design surfacing where it doesn’t belong, where it costs five times as much to resolve. The gate exists to prevent that.
A locked Design has five things. Before you move to Build, check your own Design against this list:
That fifth item deserves emphasis. Before the design is locked, define what the agents are not allowed to do. What data is off-limits. What actions require human sign-off. What happens when the agent encounters something outside its designed scope. What error rate triggers a shutdown. These are governance decisions, and they belong in Design — not discovered in Build after something goes wrong.
Run the five-item Design Gate checklist against your current sprint’s design. If any item has a gap, that gap is your next working session — not your next Build discovery. Fix it now.
When those five are in place, Build can begin. Until they are, it can’t. Holding that line is what separates the operators who run the Sequence from the operators who buy AI tools and hope.
The next chapter is Build — the phase where the designed workflow becomes a deployable system, specified at the level of detail a developer can execute against, with the guardrails and oversight decisions Design locked already set.
Reflection Questions
- Run Work Deconstruction on one real role in your company — not the job description, the actual weekly work. What percentage of tasks land in “Human judgment required” versus the other three categories? If more than half land in “Human judgment required,” challenge each one: is it genuinely judgment, or is it judgment because no one has written the rules down?
- Draw a swim lane diagram for your constraint workflow — one lane for human work, one for agent work. How many handoff crossings does the diagram show? If the crossing count is higher than the number of steps, what two handoffs could you eliminate to make the design more reliable in production?
- Run the five-item Design Gate checklist against your current sprint’s design. Which item is hardest to check off — and what would have to happen in the next working session to clear it?
- The chapter says prototyping before building catches gaps that cost minutes now and hours in Build. Have you shown the designed output to the stakeholder who will live with it daily? What surprised them?