Tag: Agentic AI

[Chapter 6 from Deliberate Alignment by Walter Reid, written in spring 2026]

AI does not fix unclear thinking. It amplifies it.

Somewhere in your organization, right now, thirty conversations are happening in parallel.

Each person, with their AI tool open in a separate tab, is asking a version of the same question the organization is supposedly aligned on. Each is receiving an answer shaped by the specific way they framed the question, the context they brought to it, the assumptions they did not know they were making. Each answer is locally coherent. Each one makes sense given the conversation that produced it.

Collectively, they are pointing in slightly different directions.

This has always been true. Organizations have always been collections of parallel, partially overlapping mental models of what the organization is doing and why. The watercooler conversation that produced a different understanding than the all-hands. The email thread that resolved something the official process had not gotten around to resolving. The tribal knowledge that lived in the heads of the people who had been there longest and evaporated when they left.

What is new is the speed at which each conversation now produces artifacts.

Before, unclear thinking moved slowly. A misaligned understanding of what the product was for would take weeks to materialize as a feature nobody wanted. There were checkpoints — reviews, handoffs, the moment where someone would say, wait, that is not what we meant. The friction was expensive in time and morale, but it was also a correction mechanism. Slowness caught errors that speed would have shipped.

Now the artifact follows the conversation almost immediately. The unclear thinking is instantiated — made real, built, sometimes shipped — before anyone has had a chance to ask whether it was right.

In the Zansei project, this dynamic became visible on a specific Thursday. One person had spent the week building a research report — seventeen pages analyzing the site’s copy, with the second half promised for the following week. Another person had been running ads at a thousand dollars a week. Zero people had completed the funnel in the previous seven days. A third person had been exploring a new feature direction that the founder had mentioned in passing on Monday. Each of these efforts was internally coherent. Each person could explain what they were doing and why. Together, they were spending money to drive traffic to copy that was being researched rather than fixed, while the product’s scope expanded in a direction nobody had agreed on. The backlog was no longer a prioritization tool. It was an anxiety archive accumulating in three different directions simultaneously.

That is the thousand conversations problem. And it is not a coordination problem.

It is a meaning problem wearing coordination’s clothes.

Why the Distinction Matters

Coordination problems have known solutions. You establish a process, a single source of truth, a set of handoffs with clear ownership. You standardize the input and the output converges. Organizational design has been solving coordination problems for a century.

Meaning problems are different. They are not about who does what or when. They are about whether the people doing the work share a sufficient understanding of why — of what the work is actually for, what success would feel like from the outside, what they would sacrifice and what they would not.

Meaning cannot be standardized. You can issue a directive that creates the appearance of resolution while the actual divergence continues underneath, now invisible because everyone has learned the right vocabulary.

The reason AI amplifies this specific problem is that the tools are exceptionally good at producing outputs that feel coherent. A person with an unclear understanding of the product vision, working with an AI assistant, will produce work that is internally consistent, well-structured, and legible — and pointed in the wrong direction. The professional surface has never been easier to achieve. The gap between professional surface and genuine alignment has never been harder to detect.

The Zansei researcher’s seventeen-page report was well-structured. It had sections and findings and recommendations. It was also answering a question nobody had agreed on, produced by someone who had no way to know the question was wrong because the question was never made explicit. The report was a coordination success — the researcher coordinated with the tools beautifully — and a meaning failure. The meaning of what the research was supposed to accomplish had never been established clearly enough to guide it.

Another team member was building something genuinely impressive in parallel — a video generation tool using Runway, Veo3, and a custom renderer. Marketing briefs that turned into thirty-second videos. High production quality. The kind of output that would have required a studio and a team five years ago. But he was working in a silo, disconnected from clients and product direction, solving a problem no one had validated. He had heard people mention wanting video content and started building. His lived experience on real production sets made him feel powerful with the AI tools, and the power was real — but it was not connected to the room.

The last ten percent is ninety percent of the effort, and while the work felt productive at first, the problem was that his solution was looking for a problem. He was not a developer or a product person or close to the client. He was building things he had heard people needed but with no validation, because there was no structure connecting his capability to the team’s direction. The thousand conversations problem embodied in one person: locally brilliant, collectively disconnected.

The Temptation of Standardization

The instinctive organizational response is standardization. One prompt template. One AI tool. One system of record that everyone queries. One voice that speaks for the organization’s intent so that everyone’s parallel conversations start from the same place.

This is not wrong. It is incomplete. And the part it misses is the part that matters.

The parallel conversations are not a problem to be eliminated. They are a resource to be synthesized. Each person who approaches a question from a different angle — the one who treats nuance as a feature, the analytical mind, the contrarian who sees what consensus is missing — each of these people is producing signal. Signal that a standard template would suppress before it could be captured.

Standardize the input and you get consistent output. You also get sterile output. An organization that has optimized its parallel conversations for convergence has also optimized them for the elimination of the unexpected. And in a world where judgment is the scarce resource, the unexpected is where the value lives.

The solution to the thousand conversations is not to make them all the same conversation. It is to build the infrastructure that lets them remain different while still being synthesizable.

What That Infrastructure Looks Like

The OpenAI harness engineering team — introduced in Chapter One — encoded their direction in a repository document that any agent — human or AI — could read before beginning work. Not documentation for its own sake. A living encoding of direction, specific enough that every agent working from it would produce consistent results without continuous re-alignment. Their early approach — one large instruction file containing everything the agent needed to know — failed. When everything is marked important, nothing is. They replaced it with a structured directory: a short entry point that served as a map, with pointers to deeper sources of truth. Design decisions documented not just as outcomes but as reasoning. Architecture described not just as what exists but as the principle behind what exists, so that the next decision made by a different person in a different context would be consistent without being identical. That is progressive disclosure applied to organizational intent — the same principle that applies to human teams.

The insight underneath that example applies to human teams with at least as much force as it applies to AI agents: anything that is not encoded explicitly enough to be read by someone who was not in the room effectively does not exist.

This is not metaphorical. During the RouteForge development described in Chapter Nine, I built a new client portal — designed it, coded it, integrated it. When I was finished, Claude Opus informed me that a client portal already existed in the codebase. It was just not documented and not connected to anything. Something that literally existed in the codebase did not functionally exist because no one had encoded it legibly enough for anyone — including the AI — to know it was there. The organizational legibility argument applies to code as much as it applies to teams. What is not encoded does not exist, even when it does.

The Slack thread that aligned the team on a decision but was never written down — it does not exist for the person who joined three months later. The whiteboard session that resolved the ambiguity in the product brief — it does not exist for the team member who was traveling that week. The institutional knowledge that lives in the head of the person who has been there longest — it does not exist for anyone the moment that person walks out the door.

Organizations have always known this. The practice of knowledge management is decades old. But the urgency was manageable when execution was slow, because the gap between losing the knowledge and feeling the consequence was wide enough to catch and correct.

When execution is fast, that gap closes. The undocumented decision becomes a shipped feature before anyone realized the decision had been made implicitly. The divergent understanding becomes a launched campaign before the synthesis that would have caught it has had a chance to happen.

What this requires in practice starts with presence. I have been in Click to Pay meetings with twenty people in person, and sometimes there is a legitimate dialog. But I don’t often hear from people on the conference line — not because they don’t have ideas, but because they aren’t present. Both literally and figuratively. They would need to shout on the phone just to make their presence felt, and if they had that type of will to be heard on the phone, they would have been in the room anyway. Presence is self-selecting. Remote participation in alignment work is observation with the appearance of inclusion. The infrastructure that makes the thousand conversations synthesizable starts with the people who are doing the synthesizing actually being in the room where the synthesis happens.

Beyond presence, the infrastructure requires legibility — not comprehensiveness. The instinct when asked to make something explicit is to make everything explicit — the complete knowledge base, the exhaustive style guide, the documentation that covers every edge case. That instinct fails for the same reason the OpenAI team’s single instruction file failed. When everything is marked important, nothing is. The file became a graveyard of rules that may or may not still reflect reality, and nobody could tell which was which.

The solution is structural: a short entry point that serves as a map, with pointers to deeper sources of truth. That is organizational legibility. Not transparency — everyone can see everything. Not documentation — there is a record of what was decided. Legibility: the organization’s intent encoded in a form that survives the people who hold it.

The Person Who Reads the Conversations

There is a person this chapter has been describing without naming.

In the previous era, they existed in the translation layers between roles. The senior developer who understood what the business actually needed. The product manager who held the tension between what users said they wanted and what the data showed they did. The account director who maintained a relationship sophisticated enough to know what the client had not yet said.

These people were synthesizing — reading the parallel conversations, finding the signal in the divergence, surfacing the question that everyone was dancing around without asking, and converting the resulting clarity into a direction the rest of the organization could move in.

As the translation layers dissolve — as the designer and the developer and the account executive converge toward a shared capability — this work does not disappear. It becomes more important, more visible, and more load-bearing. Because the parallel conversations are happening faster, the artifacts are materializing sooner, and the cost of letting the divergence compound is higher.

The skill is not technical. It is closer to curatorial, or editorial — something that has not quite found its vocabulary because it has only recently become urgent enough to require one. It requires the ability to hold contradictory inputs without prematurely resolving them. To distinguish between productive tension — divergence that is generating signal — and destructive divergence that is consuming energy without producing meaning. To know when the conversations have generated enough to act on and when they are still processing something important that premature synthesis would foreclose.

This is not a new kind of person. They have always been in your organization. What is new is that their work, which was previously invisible because it happened in the gaps between the legible processes, is now the work that everything else depends on.

In film production, the person who holds this function has a title: second assistant director. Not the creative lead. Not the one whose name goes on the poster. The one who holds the entire production’s logistics in her head — who knows that tomorrow’s call sheet conflicts with a location change the director mentioned in passing, who reads across every department’s needs simultaneously and surfaces the collision before it becomes a cost. The function is synthesis. The title undersells it. It always has.

The version of this person in your organization may be the one who is most skeptical of the AI tools — not because they don’t understand them, but because they understand what gets flattened. The people best suited for this work are not always the ones who embrace the tools that accelerate it.

Find them. Give them the room.

Or, if you are that person: you already know. The question is whether the organization around you knows yet.

Before Anyone Opens a Laptop

This is where the chapter connects to Deliberate Alignment as a practice rather than a philosophy.

The thousand conversations problem cannot be solved in the meeting where the work gets reviewed. It cannot be solved in the retrospective where the misalignment becomes visible. It cannot be solved in the integration moment where the separately-built artifacts collide and the distance between them becomes apparent.

It can only be solved before it starts. Before the conversations diverge past the point of easy synthesis. Before the artifacts begin to accumulate in directions that will cost weeks to unwind.

And here is the part that is uncomfortable to say plainly: most organizations do not currently do that work. They approximate it. They hold the meeting that is supposed to produce alignment and leave with the feeling of having achieved it without checking whether what everyone took out of the room was actually the same thing. They produce the strategy document and assume that reading it produces the understanding it was meant to convey. They rely on the accumulated shared context of people who have worked together long enough to develop a kind of shorthand — and discover the limits of that shorthand the moment the team changes, or the pace accelerates, or the AI agents begin executing on the shorthand as if it were explicit when it never was.

Coordination problems have known solutions. Meaning problems might not. That is not a comfortable thing to write in a methodology book. But the honest version of what this chapter is saying is that the thousand conversations are already happening, the artifacts are already accumulating, and the infrastructure that would make them synthesizable rather than incoherent is, in most organizations, not built yet and not being built.

The conversations are not waiting for the organization to be ready.

And the synthesis problem does not stop at the organizational level. The person running multiple AI conversations in parallel — each producing coherent artifacts, each pointed in a slightly different direction — is the thousand conversations problem at the scale of a single mind.

The question is whether what they produce, when they converge, will be the thing the organization meant.

Coordination problems have known solutions. Meaning problems require something the field has not yet fully described. The conversations are not waiting for the description to arrive.

← Previous: Chapter 5: The Client in the Room · Contents · Next: Chapter 7: Relief or Panic — How to Know Which You Are →

Copyright Walter Reid, 2026. All rights reserved.

[Chapter 4 from Deliberate Alignment by Walter Reid, written in spring 2026]

The room is not where the work gets reported. It is where the work begins.

There is a name for what happens in the best two and a half hours of the Thursday meeting.

Not a new name. The thing it describes has been happening in good rooms for as long as there have been good rooms. What is new is the urgency of naming it — the specific pressure that arrives when execution becomes fast enough that the thing which was always most important can no longer be deferred past the first conversation.

Deliberate Alignment is a methodology organized around the quality of the decision before execution begins, rather than the management of execution itself. The unit of work is not the sprint. It is the room — the specific convergence of the right people, with visible work, making real decisions that an agent can act on before anyone leaves.

That definition is precise. It is also incomplete without understanding what it is not.

It is not better meetings. Meetings, as they exist in most organizations, are designed either to communicate decisions already made elsewhere or to create the appearance of collective ownership for decisions that will be made elsewhere anyway. The calendar entry and the agenda and the agreed-upon next steps are theater when the real decision has already happened in a hallway or a direct message. Deliberate Alignment is not about running that process more efficiently. It is a different process.

It is not a workshop methodology. Design sprints, war rooms, hackathons — these are relatives of the same instinct, and the iHeart story shows where that instinct comes from. The hackathon changed what was being decided on. A tangible prototype reduces decision latency by changing what the process has to evaluate. Deliberate Alignment takes that instinct and makes it the entire methodology rather than a periodic intervention.

And it is not a framework for eliminating disagreement. The room that produces genuine alignment is not a room where everyone agrees. It is a room where the disagreement is legible — where the tension between perspectives is visible to everyone, where it can be evaluated rather than avoided, and where someone with the authority to commit can make the call and have it mean something. Alignment is not consensus. It is shared understanding of a direction, including an understanding of what was decided against and why.

The Three Functions

Every room that has ever produced genuine alignment has contained three functions. Sometimes three people, sometimes fewer. The number of people is not the point. The functions are.

The first is the function of depth. Someone in the room has to understand what the client, the user, the stakeholder needs beneath what they say. Not the stated requirement. The actual pressure. The competitive anxiety that didn’t make it into the brief. The internal politics that will determine whether the right solution gets adopted or quietly shelved.

In the Zansei project, this function belongs to the person who understands that Zan’s requests for new features are not really product requests. They are expressions of a founder’s anxiety about whether the thing he has built will matter. When he says “now let’s add e-commerce,” he is not describing a product roadmap. He is describing fear that the current product is not enough. The person who hears that and responds to the fear rather than the feature request is doing the depth function. The person who adds e-commerce to the backlog is not.

This function has been systematically undervalued because it is invisible when it is working. The meeting goes smoothly. The client leaves satisfied. The direction is clear. Nobody sees the specific quality of listening that produced those outcomes because the outcomes look like they just happened.

The second is the function of taste. Someone in the room has to be willing to say when the answer is defaulting to mediocrity. Not the obvious wrong answer — that is easy to catch. The answer that is technically correct, defensible, and insufficient. The direction that will satisfy the sprint review and disappoint the user.

This function is the most politically exposed of the three because it requires pushing back against the path of least resistance in a room where the path of least resistance is what everyone wants to take. It requires a specific kind of standing — not authority, exactly, but credibility. The person who says “that’s not good enough” has to have earned the right to say it. Which means the function cannot be assigned. It can only be recognized.

In the Zansei project, this function is currently vacant. Not because the people in the room lack taste — several of them have excellent taste. But nobody has been given, or taken, the explicit role of maintaining the product’s integrity against the gravity of scope expansion. When Zan expands the scope, there is no voice in the room whose designated function is to say “that’s a different product and building it will cost us the product we have.” That absence is structural, not personal.

The third is the function of authority. Someone in the room has to be able to say yes and have it mean yes. Not yes pending approval. Not yes subject to review. Yes, this is the direction, and the execution can begin.

This function sounds simple. It is the most complicated of the three in practice, because authority without understanding is not authority — it is permission for the wrong thing. The person who can commit must be present in the room where the alignment is being built, not receiving a summary afterward. The summary degrades the alignment. It removes the context that made the direction legible and replaces it with a conclusion that looks like the same thing but isn’t.

Zan is the authority function in the Zansei project. The Thursday meeting works, when it works, partly because he is there — present, engaged, making calls in real time. The meetings where he is absent or distracted produce decisions that look like decisions until he encounters them later and reframes them from a different context. The alignment wasn’t built with him. It was built around him. Those are not the same thing.

Understanding Zan requires accepting something the framework does not make obvious: authority without depth is not always a vacancy to be filled. Sometimes it is the permanent operating condition of the person who holds the authority function. Zan is the type of person who tells you to go take pictures in Central Park. And when someone asks which part — the geese, the lake, the people, the trees — he says “Central Park.” Or worse: “I told you Central Park, what don’t you understand.” He does not know what he wants until he sees options. He has never known. He is not going to start.

This type of person thrives with AI, assuming there are people who can translate those words to actions. Before, you had to go photograph everything in Central Park and return like an episode of Mad Men, lay the options on his desk, and have him select. Now the options can be generated in minutes. The translation layer — the people who hear “Central Park” and understand what questions to ask before anyone starts shooting — is more important, not less. The framework’s job is not to fix the founder. It is to build the translation layer that lets the founder’s instinct become actionable without requiring the founder to articulate what he cannot articulate.

The danger is what happens when Zan sees the speed. If you can provide a full prototype in a week that would have taken months before, he will expect the mobile app or the multi-tenant system done by next Monday. Expectation inflation — the authority function seeing AI-enabled speed on one task and generalizing it to everything — is a failure mode the framework has to absorb. The translation layer has to manage not just the founder’s direction but the founder’s sense of what is possible.

Why One Person Can Hold Two Functions

The three functions are not job descriptions. They are capacities that need to be present in the room. The same person can hold more than one.

The person who understands what the client needs beneath what they say often also has the taste to recognize when the answer is insufficient. Those two functions travel together in people who have spent significant time close to users — who have developed their taste through repeated exposure to the gap between what was built and what was needed.

The person with authority to commit sometimes also holds the depth function — the founder who has been closest to the problem, who understands the user’s anxiety because they shared it before they built the solution. That combination is powerful when the authority is paired with genuine understanding and dangerous when it isn’t. Zan at his best is both. Zan on a day when he is running on pattern-matching from a single data point is the authority function operating without the depth function, and the direction that emerges will be confident and wrong.

What the framework requires is not that three distinct people occupy three distinct boxes. It requires that when any significant decision is being made, all three functions are present and active. The check is simple: is someone listening at depth, is someone willing to say when it isn’t good enough, and is someone able to commit with genuine understanding of what they are committing to? If any of those questions has no answer, the room is not ready to produce alignment.

The framework requires that the functions be present. It does not require that they remain distributed across multiple people indefinitely.

The New Prioritization Question

The old prioritization question — given scarce execution capacity, what should we build first? — dissolved in the previous chapter when the denominator disappeared. The new question is: given that we can build almost anything, what should we decide to build at all?

That is not a ranking problem. It is a decision problem. And it requires the three functions to be present. The depth function to understand what building this will actually mean for the person it is built for. The taste function to assess whether this is the direction that will matter or merely the direction that is available. The authority function to commit to one direction and foreclose the others.

The decision that resolves ambiguity for every execution that follows it is worth more than the decision that resolves one task cleanly. The decision that lets the room disperse with shared understanding of what the next month looks like is worth more than the decision that produces one feature quickly.

This is what the Zansei team is missing. Not execution capacity — the team can build almost anything in hours. What it is missing is the decision that would let every member build confidently in the same direction without requiring constant re-alignment. The Thursday meeting produces that decision, sometimes, for a few days. The methodology is the attempt to produce it reliably.

What the Room Requires

A room that produces genuine alignment requires that the work is visible. Not described — visible. The prototype, the draft, the live system, the actual artifact that the decision is being made about. The client who is reacting to a description is imagining something. The client who is reacting to a prototype is evaluating something. These produce different quality decisions.

It requires that the people in the room can make the decision. Not advise on it. Make it, with authority that holds outside the room. A room full of people who are present to inform a decision that will be made by someone who is not present is not an alignment session. It is a research process that will produce a summary that will degrade the alignment before it reaches the person who can commit.

It requires that the decision survives the room. The output of a Deliberate Alignment session is not minutes. It is a shared understanding explicit enough to be acted on independently — specific enough that two people who were in the room can make separate decisions the following day that point in the same direction without checking with each other first.

And it requires that the people in the room trust each other enough to say what they actually think. Psychological safety — the condition where people believe they will not be punished for speaking up — is not a soft organizational concern in this context. It is load-bearing. The room that cannot hold genuine disagreement cannot produce genuine alignment. What it produces instead is the appearance of alignment, which is more dangerous than acknowledged disagreement because it is invisible until the execution is already underway in the wrong direction.

The Framework Applied to Zansei

The Zansei project is not a success story. It is a work in progress, and the framework is being tested on it in real time.

What the Thursday meeting gets right: it assembles most of the functions. The depth is present. The authority is present when Zan engages rather than absorbs. The work is visible on the screen at the end of the table. For two and a half hours, the room functions as the methodology describes.

There was a Thursday in March where it worked. The business consultant, who held the client relationship, asked the developer to produce a brand document and a white-label overview — something a new partner could use to get up to speed quickly. The request was reasonable. The timeline she was imagining was a week. The UX lead, who could have built it with her eyes closed, sat quietly. The developer nodded.

I was annoyed before I understood why I was annoyed. The business consultant had been in every meeting — she was the person closest to the partner’s needs. The UX lead was sitting right next to her, the person who could articulate the brand’s voice in her sleep. And both of them had deferred the ask to the developer. Not because he knew the brand better. Because producing a deliverable still felt like a technical act, even when the deliverable was pure judgment. The knowledge to produce those documents was in the room. It had been in the room for months. The taste and the depth were present. They just didn’t recognize themselves as sufficient.

So I did it while the conversation continued. Opened Claude, shared screenshots of the product flow, attached two media briefs as examples, and asked for both deliverables. Before the meeting moved to the next topic, both documents were in Slack. Not perfect. Good enough to use, good enough to improve, produced in five minutes from the understanding that was already present in the room.

The room went quiet for a moment. Not because the documents were impressive — they were functional, not beautiful. Because the speed made visible something the team had not confronted directly: the gap between what they knew collectively and what they were producing was not a capacity problem. It was a willingness problem. The understanding was there. The encoding was not.

And then the thing I did not say out loud, because it was not the moment: I could produce those documents because I held all three functions simultaneously — I understood what the partner needed, I could judge whether the output was sufficient, and I had the authority to ship it without asking. The business consultant had the depth. The UX lead had the taste. Both were in the room. Neither acted. So I held all three, and for five minutes the framework worked perfectly — and the question I could not stop thinking afterward was why I had needed anyone else in the room at all. That question is not one this chapter can answer. But it is one the book will return to.

What it gets wrong: the taste function is not held consistently. The decision that the meeting produces is not always encoded explicitly enough to survive the week. The authority that commits on Thursday sometimes re-opens what was committed on the following Monday, having encountered a new piece of information that was not in the room. The alignment is real but fragile — produced by proximity and presence, not by a system designed to sustain it. Initially, the Thursdays were demos without direction — work shown, reactions given, nothing decided that would hold past the weekend.

The fix is not to have longer meetings or more meetings. It is to be more deliberate about what the meeting is for. The first fifteen minutes of ritual — what did you do, what will you do, any blockers — is not alignment work. It is status reporting that could be asynchronous. The two and a half hours in the middle is the alignment work.

The more fundamental fix is to name the vacancy. The taste function is not held. Nobody in the room has the explicit standing to say “that is a different product” when the scope expands, and have the authority function hear it as information rather than resistance. Without that voice, the backlog of features and client requests becomes what the previous chapter called an anxiety archive — not a prioritization tool but a growing list of things that might matter, maintained by a team that cannot say no. Naming that vacancy is not a personnel problem. It requires a conversation about what the room needs that it does not currently have, and who is willing to hold it.

That conversation is itself a Deliberate Alignment session. The methodology is recursive. The room that designs the room is the same kind of room as the room it is designing.

The Zansei project will continue after this book is written. Some Thursdays will produce the two and a half hours of real alignment. Some will produce demos without direction.

What the framework offers is not a guarantee that every room will work. It is a description of what a room that works requires, specific enough that you can look at your own room and ask which of those things are present and which are absent. The three functions. The visible work. The decision that survives the room. The trust that makes genuine disagreement possible.

If all of those are present, something will happen in the room that is difficult to describe from the outside and immediately recognizable from the inside. The options become real. The direction becomes clear. The people leave knowing what they are building and why, and the knowledge is specific enough to act on without checking back.

That is what the Thursday meeting feels like in its best two and a half hours. Not efficient. Not optimized. Alive.

It is not a meeting. It is the work.

The room that produces alignment is not the room where everyone agrees. It is the room where the decision is made by the people who have to live with it, in the presence of everything they need to make it well.

← Previous: Chapter 3: What Agile Got Right (And Why It’s No Longer Enough) · Contents · Next: Chapter 5: The Client in the Room →

Copyright Walter Reid, 2026. All rights reserved.