Becoming an AI Power User

One durable idea runs through this: when the cost of steps changes, the optimal sequence tends to change with it. AI changes which steps should exist, which can be parallelized, which should happen earlier, and which decision goes to whichever intelligence, yours or the model's, gets the better aligned result. Redesign is not only cost-driven optimization. Some of the best new sequences start from a playful 'wouldn't it be cool if this workflow could do something it never could before,' not from a complaint about a slow step. Speeding up a broken sequence rarely helps as much as redesigning it, and the deeper move is to keep climbing a level: once a sequence works, encode it as a reusable workflow and let the system itself improve it. The first redesigned cycle may be slower. Workflow redesign often follows a J-curve: early friction, then structural gains that compound across every future cycle.

The unit of AI work is growing from one conversation to a whole workflow

The earlier chapters taught you to collaborate with AI in conversation: load context, iterate through dialogue, calibrate through testing, save the prompts and standards that work, set up agents, and sharpen your judgment. Those capacities remain essential. What is changing is the unit of work they operate on. For the first two years of widespread AI use, the unit of work was a single conversation. You briefed the model, iterated, and produced an output. The shift now underway operates on a larger unit: an entire workflow with multiple steps, handoffs, and decision points.

Nathaniel Whittemore, host of The AI Daily Brief, frames this as a phase transition: the move from 'AI helps me do my work' to 'my job is setting up conditions for agents to work.' This shift is more disruptive than the original ChatGPT moment, because it changes what 'doing your work' means. In the chat paradigm, you are a collaborator who improves output through conversation. In the workflow paradigm, you are a director who designs the workflow, defines the decision points, and evaluates the results.^[1]

The four capacities you have built so far prepare you for this shift. Context loading becomes workflow briefing: defining inputs, constraints, and success criteria for each step. Dialogue becomes review: evaluating and refining agent output at checkpoints. Calibration becomes delegation judgment: knowing which steps an agent handles reliably and which your judgment still handles better, with both improvable over time. Infrastructure becomes the durable artifacts behind the workflow: specs, standards, skills, and evaluation rubrics that persist across runs. The first question in any workflow redesign is 'what counts as done?': defining the evaluation criteria for the workflow's output before designing the sequence of steps that produces it. Once those criteria exist, you can have the model score its own run against them and report where the output fell short, so the system flags its own weak points instead of leaving you to catch every one by hand. The first redesigned cycle is a probe, not a final system. Run it once, let the evaluation surface where it creates value and where it creates risk, and revise before committing to the new sequence.

Making one email 10% faster is not the same as redesigning communication

The most common way to use AI is to speed up individual tasks: draft this email faster, summarize this meeting faster, format this report faster. Those gains are measurable and real: Microsoft reports that power users save more than 30 minutes per day this way.

Power users who gain hours, not minutes, redesign the workflow itself instead of only speeding up its existing steps. They are asking: now that AI can draft, summarize, analyze, research, and structure, what is the optimal sequence of steps for this recurring process? That question often produces a fundamentally different workflow, rather than a faster version of the old one.

Economists Erik Brynjolfsson, Daniel Rock, and Chad Syverson identified the pattern that explains why early adopters often look unproductive. Their 'Productivity J-Curve' (American Economic Journal: Macroeconomics, 2021) shows that organizations must invest in intangible complements, such as process redesign, training, and reorganization, before productivity rises. During this investment period, measured productivity falls. The same shape tends to show up at the scale of a single workflow: the first redesigned cycles often feel slower than the old sequence. In my experience the structural gains tend to appear after a few cycles, once you have solved the friction points that the redesign revealed. The paper measures this at the level of firms over years, so treat the per-cycle timing as a working analogy rather than a finding from the study.^{[2] [3] [4]}

Demirer and colleagues' chaining theory produces two additional insights worth applying to your own workflow redesign. First, dispersion lowers automation pressure: roles whose AI-amenable steps are scattered throughout the workflow (with judgment steps interleaved) face less pressure to automate end to end than roles where automatable steps cluster together. When you redesign a workflow, interleaving your judgment at the points where it currently produces the better aligned result keeps that judgment in play and improving rather than letting it atrophy. Second, comparative advantage can fail under chaining: a task you do better than the model may still be worth automating if it sits between two AI-executed steps, because chain continuity yields compounding coordination savings. The question for each step is not only 'whose judgment gets the better result here?' but also 'does keeping this step human break the chain?'

Three examples of workflow redesign versus task automation

How to map and redesign a workflow

Workflow redesign follows a simple process:

1. Map the current workflow. List every step in the recurring process: what happens, in what order, and how long each step takes. Include the steps you do manually, the steps you delegate, and the steps you skip or do poorly.
2. Identify which steps AI changes. For each step, ask: can AI do this entirely? Can AI do a first pass? Can AI make the inputs for this step available earlier? Can AI eliminate this step by producing the output differently?
3. Redesign the sequence. Now that some steps are faster, cheaper, or possible in a different order, what is the optimal sequence? Steps that were sequential may become parallel across focused conversations. Steps that required human effort throughout can be done in a single review pass. Steps that were skipped (because they were too expensive) become feasible. Use the hub-and-spoke pattern for running focused conversations in parallel to coordinate any steps that can run simultaneously.
4. Test the redesigned workflow on one real cycle. Run through the new sequence once. Have the model score its output against your done criteria and report the time, the quality gaps, and the points of friction, so the run diagnoses itself. Refine.
5. Evolve the system, not just this run. Once a cycle runs cleanly, encode the redesigned sequence as a reusable workflow with its prompts, boundaries, and done criteria, then climb a level: turn the steps you keep repeating into a standard, a rule, or a skill the agent can apply on its own. Each later run improves that workflow instead of rebuilding it from scratch, and the workflow keeps handing more off as it earns trust.

Sequential workflows often become parallel workflows

AI changes workflows in three ways. It accelerates individual steps (a draft that took an hour takes ten minutes). It changes the sequence (research and drafting can happen closer together when AI produces structured summaries). And it allows formerly sequential work to happen in parallel.

The third change, moving sequential work into parallel, often produces the deepest structural gain because it removes a bottleneck rather than shaving time off one step. Consider the proposal workflow again. Before AI, research had to finish before outlining could start, outlining had to finish before drafting, and drafting had to finish before editing. After AI, research, audience analysis, objection mapping, and source gathering can happen in parallel across focused conversations. You synthesize the outputs yourself or have a model draft the synthesis for you to check, choosing whichever gets the better aligned result, then drafting and editing happen in separate passes. The workflow is shorter because the sequential bottleneck was removed.

When you map a workflow for redesign, look for steps that are sequential only because a human could not do them simultaneously. If AI can handle each step in a separate conversation, those steps can move in parallel. The hub-and-spoke pattern for parallel conversations, taught when you gave each AI conversation one focused job, coordinates this.

Workflow redesign usually takes several imperfect cycles

The before-and-after comparison in the proposal example looks clean on paper. In practice, the first redesigned cycle will have friction. The AI research summary may surface claims its own source check flags as thin, so they still need your verification. The voice-memo-to-draft step may require two iterations instead of one. The second-model edit may catch issues that send the draft back to the drafting step.

This is normal. Workflow redesign is itself an iterative process. The first cycle reveals where the new sequence is stronger and where it still needs adjustment. The second cycle is faster because you have already solved the friction points from the first. By the third cycle, the redesigned workflow starts producing the structural gains that justify the effort of changing your process. The same repair-while-it-converges skill you used inside a single conversation applies to the whole workflow: stay with the redesign through its early imperfections instead of reverting to the old sequence at the first sign of friction.

Every decision point needs an owner before the agent starts

Before delegating a workflow to an agent, write down four things: which decisions the model gets to make, which steps stay human, where the handoffs are, and what counts as done. This pre-flight definition takes five minutes and prevents the most common failure mode in agent delegation: confident wrong output that followed no one's definition of success.

In practice, most people skip this step entirely. They attach a model to a tool without defining the workflow behind it, so the model runs, produces plausible-looking output, and moves on. Whether it meets anyone's actual standard is unknowable because no standard was written down. The implementation layer around the model (workflow design, data access, authority, evaluation criteria, and recovery procedures) tends to determine results as much as raw model capability does.

Before the detailed checklist, define three boundaries: what data the agent may see, what tools it may use, and what actions it may take without your approval. These boundaries protect you from the most common agentic failure: a capable agent that does exactly what it was told in a scope you never intended. A coding agent that can read your project files should not also be reading your credentials directory. A workflow that drafts client emails should not be able to send them. If you cannot define these boundaries clearly, the workflow is not ready for delegation.

A simple pre-flight checklist for agent delegation:

1. What does the agent decide? List the specific judgments you are delegating. 'Write the first draft' is a delegation. 'Decide what to include' is a different delegation with a different risk profile.
2. What stays with you? List the decisions where your judgment currently gets the better aligned result, or where you stay accountable for the call. These are your review checkpoints, and you can hand more to the agent as its judgment earns it.
3. Where are the handoffs? Define the format and location where the agent delivers intermediate or final output for your review.
4. What counts as done? Write down the criteria you will use to evaluate the agent's output. If you cannot articulate 'done,' the agent cannot hit a target that does not exist.

This checklist connects directly to the collaboration modes from the Mode Selection chapter. The pre-flight definition makes your mode choice explicit: which steps are Self-Automator (fully delegated), which are Centaur (human and AI on separate steps), and which are Cyborg (interleaved within a step). When you write down the decision points, the mode for each step becomes obvious.

Redesign one workflow this week