CHAPTER 10

DESIGN YOUR COUNCIL

Daniel began with five headings.

Investigator. Analyst. Challenger. Verifier. Synthesiser.

He placed them in a new document, one beneath the other, then added instructions beneath each role. The Investigator would gather information. The Analyst would examine the structure of a problem. The Challenger would attack the preferred conclusion. The Verifier would check the evidence. The Synthesiser would bring the findings together.

It looked orderly.

For a moment, Daniel felt he had made progress simply because the page looked like a system.

Then Marcus called.

“I need you to look at something,” Marcus said. “I have a decision to make about the business.”

Daniel opened his notebook. “What decision?”

“Whether to increase the number of customers we serve next month.”

“Why?”

“Because the test is working. People are paying. Some are coming back. I think we can handle more.”

Daniel paused at the word think.

“How many more?”

“That's what I'm trying to work out.”

“And what happens if you increase the number and discover the service costs more to deliver than you expected?”

“We adjust.”

“What if the extra customers don't return?”

“We learn.”

“What if the demand is there, but the process breaks when the number increases?”

Marcus sighed.

“Daniel, I called because I need help deciding what to do. I didn't call to be interrogated.”

Daniel laughed. “Fair enough.”

He looked at the five headings on his screen.

His carefully designed council was about to examine a real decision. Yet before he had even asked an AI a question, he had begun making the same mistake he had warned himself against: he was preparing to run the entire machine simply because he had built it.

“Let me try again,” Daniel said. “What is the smallest increase you could make without putting the whole operation under pressure?”

Marcus thought for a moment.

“We could take on ten more customers instead of opening it up completely.”

“What would you need to know before doing that?”

“Whether we can serve them properly. Whether the cost makes sense. And whether enough of them are likely to return.”

“Good. Let's start there.”

Daniel closed the five-role document and opened a fresh page.

This time, he wrote the decision first.

Should Marcus expand the service to ten additional customers next month, and what conditions should be met before he commits?

The question changed the shape of the work.

They were not trying to prove that Marcus had a good business. They were not trying to predict the entire future of the company. They were examining one decision, with a defined scale, a defined period, and consequences they could investigate.

Daniel entered the question into his AI assistant, along with the available information about customer numbers, prices, delivery costs, and repeat usage. He asked it to identify what was known, what remained uncertain, and what additional evidence would matter most.

The response was useful.

It was also too long.

The assistant proposed a market analysis, a competitor review, a customer segmentation study, a financial forecast, a marketing plan, an operational audit, and a risk assessment. Each section contained sensible questions. Together, they created a mountain of work that could consume the month Marcus needed to run the test.

Daniel read the list twice.

Then he deleted most of it.

A system that demanded more effort than the decision justified was not necessarily a sophisticated system. It could simply be an inefficient one.

He turned back to Marcus.

“We need to design the council around the decision, not force every decision through the whole council.”

Marcus nodded. “That sounds better.”

“It also means knowing when not to use it.”

Daniel began drawing three boxes.

The First Design: Match the Council to the Decision

The first box was small.

For an ordinary, reversible decision with limited consequences, Daniel would use a quick check. He might ask an AI to compare two approaches, identify an overlooked consideration, or help him organise a plan.

He would still use his judgment. He would not need five separate roles to decide whether to rearrange his work schedule or which of two familiar methods was more convenient.

The second box was larger.

For a decision involving meaningful cost, uncertainty, or consequences that would be inconvenient to reverse, he would use a structured review. The AI would examine assumptions, compare options, and identify weaknesses. Daniel would seek additional evidence where the answer depended on facts that could be checked.

Marcus's proposed expansion belonged here.

The third box was larger still.

For a high-stakes commitment, a difficult-to-reverse decision, or a matter where a serious error could cause substantial harm, Daniel would use the full council architecture. He would separate the roles, examine important claims independently, and seek qualified human expertise when the subject required it.

A decision involving a major financial commitment, a binding legal obligation, or a safety-critical system could not be made reliable simply by asking several AI assistants to agree. The appropriate evidence and expertise mattered more than the appearance of a thorough review.

Daniel wrote one sentence beneath the boxes:

The depth of the review must reflect the consequences of being wrong.

He looked at it for a moment.

That sentence did not mean small decisions never deserved careful thought. A seemingly minor choice could have serious consequences in the right circumstances. Nor did a large decision always require endless analysis.

It meant that the process should be proportionate to the actual risk.

The council was not a ceremony. It was an instrument.

And instruments had to fit the work.

The Second Design: Give Each Role a Job

Daniel returned to the five roles.

This time, he did not treat them as five personalities sitting around a table. He treated them as responsibilities that had to be fulfilled.

The Investigator would establish what was being claimed and locate relevant evidence.

The Analyst would examine the mechanics of the proposal: costs, dependencies, incentives, assumptions, and possible outcomes.

The Challenger would ask what might make the preferred plan fail and whether another explanation fitted the available evidence.

The Verifier would check important factual claims against suitable evidence, paying attention to the original source and whether apparently separate sources were genuinely independent.

The Synthesiser would organise the results only after the other work had been completed.

The distinction mattered because one AI assistant could perform several roles, provided Daniel kept the tasks separate. He could also use different tools or different conversations when separation would reduce the risk of one response influencing another.

Five roles did not require five subscriptions, five devices, or five intelligent machines.

The architecture existed in the discipline of the process.

Daniel tested it on Marcus's expansion.

First, the Investigator received the available customer records, with identifying details removed. It was asked to distinguish actual customer behaviour from expectations and to identify what evidence was missing.

The response found that several customers had paid for the service, and some had returned. It also noticed that the available feedback came largely from customers who had chosen to respond.

That was useful. It did not establish that the wider market would behave in the same way.

Next, the Analyst examined the operating numbers. Daniel supplied the current price, the known costs of delivering the service, the estimated time required per customer, and the proposed increase in volume.

The analysis revealed a question Marcus had not fully considered: the business could receive more revenue and still become harder to operate if each additional customer required more time or support than expected.

Then Daniel gave the Challenger a narrower task.

“Assume Marcus expands and the experiment performs poorly. What are the most plausible reasons? Use the available information. Do not invent facts to make the criticism sound stronger.”

The answer identified several possibilities. New customers might behave differently from the first group. Delivery time could rise with volume. Some customers might not return. The current method of acquiring customers might become more expensive as Marcus reached beyond his existing network.

None of these possibilities was proof that expansion would fail.

They were risks worth testing.

The Verifier then examined the claims that could be checked. It looked at the calculations, the definitions used in the customer records, and the evidence supporting the proposed assumptions. Daniel did not accept an AI's declaration that a calculation was correct without checking the underlying numbers when the calculation mattered.

Finally, the Synthesiser received the findings.

It produced a concise summary: what the records established, which assumptions remained untested, what the different analyses agreed on, where uncertainty remained, and which next actions were available.

Daniel read it carefully.

The answer did not tell Marcus that the business would succeed. It did not need to.

It helped them see what the next decision actually required.

Marcus could expand immediately, maintain the current scale, or run a controlled test with ten additional customers while tracking delivery time, total cost, repeat usage, and customer feedback.

The third option did not eliminate risk. It made the risk more observable.

Marcus leaned back in his chair.

“So the council hasn't decided for me.”

“No,” Daniel said.

“But it has shown me what to measure.”

“That's closer to the job.”

Marcus looked at the figures again.

“I'll run the smaller test. If the numbers show that we're growing revenue but losing control of delivery costs, I want to know before I take on more people.”

Daniel recorded the decision, including the conditions that would lead Marcus to continue, adjust, or stop the expansion.

For the first time, the council had not merely produced an answer. It had helped structure an experiment whose results could challenge the answer.

That was the kind of system Daniel wanted.

The Third Design: Control What Enters the Council

Later that evening, Daniel reviewed the information he had supplied to the assistants.

He noticed that one draft contained more customer detail than the analysis required. Names were unnecessary. Personal contact information was unnecessary. Individual conversations could be summarised without exposing the people who had taken part.

He removed the details.

This was not just a matter of keeping a document tidy. Every additional piece of information created another responsibility. If the task could be completed with anonymised figures or a general description, there was little reason to provide identifying details.

Daniel added a new rule to his design:

Give the council enough information to reason well, but no more than the task requires.

He also realised that information quality began before the AI received a prompt.

If he supplied a selective account of the situation, the council might carefully analyse a distorted picture. If he omitted a constraint, the system could recommend an option that was impossible in practice. If he presented an estimate as a confirmed fact, later stages might build an entire argument on that mistake.

The council could not reliably repair every defect in the information it was given.

So Daniel began separating the input into four parts.

First, the objective: what decision needed to be made and what outcome mattered.

Second, the established information: records, observations, verified figures, and other evidence relevant to the question.

Third, the assumptions: estimates, expectations, interpretations, and claims that had not yet been demonstrated.

Fourth, the constraints: budget, time, available skills, obligations, privacy requirements, and the limits of what could reasonably be changed.

These categories did not make the information automatically accurate. They made it easier to see where accuracy still needed to be examined.

Daniel tested the structure with a hypothetical question: should he take on a project that promised a larger income but demanded most of his available time?

He could ask an AI to compare the financial and practical options. It could estimate workload, expose hidden dependencies, and help him consider alternatives.

But it could not decide how much peace of mind he should trade for income, how much uncertainty he was willing to accept, or which personal commitments mattered most.

Those were not missing calculations.

They were his values.

The council could help him understand the consequences of different priorities. It could not legitimately choose his priorities and then present the result as an objective answer.

Daniel wrote another rule:

The human supplies the purpose, constraints, and authority to decide. The council examines the path.

He knew that people often supplied goals without examining them. Someone might ask how to maximise revenue when the real objective was to build a sustainable business. Someone might ask how to win an argument when the more important goal was to resolve a disagreement. Someone might ask how to work faster when the real problem was that the work should not be done at all.

A useful council should sometimes challenge the stated objective.

But challenging a goal was not the same as secretly replacing it.

The system could ask whether the goal was consistent with the person's stated priorities. It could reveal trade-offs. It could offer a different way to frame the problem.

The human still had to decide what mattered.

The Fourth Design: Demand a Useful Output

Daniel had learned that a polished answer could conceal uncertainty. He now wanted an output that made uncertainty difficult to overlook.

He designed a standard report for consequential decisions.

It would begin with the decision being examined, not a grand conclusion about the future. It would then separate established facts from assumptions and unresolved claims.

Next would come the competing interpretations: what supported the preferred option, what argued against it, and what other explanations deserved consideration.

The report would identify which claims had actually been verified, which sources depended on the same underlying information, and which important questions remained open.

It would then present the available actions, the likely trade-offs, and the evidence that could change the recommendation.

Finally, it would state what the system could not establish.

Daniel did not demand that every report contain exactly the same number of sections or the same length. The format was a safeguard, not a ritual. A simple decision might need only a few sentences. A major commitment could require a detailed record.

What mattered was that the output did not merge facts, estimates, and confidence into one smooth paragraph.

He tested the format on Marcus's expansion.

The first draft began:

The business is well positioned for growth, and expanding to ten additional customers is a reasonable next step.

Daniel stopped reading.

The sentence sounded confident, but what did well positioned mean? Which evidence established it? Did a few paying customers demonstrate that the business could operate at a larger scale?

He asked for a revised conclusion that distinguished the evidence from the recommendation.

The next version was more precise:

The current test provides evidence that some customers are willing to pay for the service, and the return of some customers suggests there may be repeat demand. The available evidence does not establish that the service can be expanded profitably. A controlled test with ten additional customers could help assess delivery capacity, cost per customer, and repeat usage before a larger commitment is made.

Marcus read it.

“That sounds less exciting,” he said.

“It also says what we actually know.”

“And what we don't.”

“Exactly.”

Marcus approved the second version.

Not because it was cautious for the sake of caution, but because it gave him a decision he could act on without pretending the future had already been settled.

When the Design Becomes the Problem

For several days, Daniel felt satisfied with the new architecture.

Then he tried to use it on a much smaller decision.

He was preparing a short explanation of his project and wanted to choose between two opening paragraphs. Instead of reading them and making a choice, he opened the council document.

He assigned the Investigator to examine the audience. The Analyst compared the structure. The Challenger criticised both versions. The Verifier searched for factual problems. The Synthesiser prepared a recommendation.

By the time the responses arrived, Daniel had spent more time organising the review than the decision deserved.

Worse, the answers disagreed over small matters of style. One preferred the direct opening. Another preferred a more descriptive one. A third suggested a different opening entirely.

Daniel began revising all three.

He was no longer improving the paragraph. He was serving the architecture.

He stopped, looked at the clock, and laughed at himself.

The system had been designed to protect his judgment from careless conclusions. Now he was allowing it to interrupt a judgment he was perfectly capable of making.

He closed the council document.

He read the two paragraphs aloud. One explained the purpose immediately. The other took longer to reach the point. He chose the first and moved on.

Nothing important had been lost.

That evening, he changed the design again.

The council would have three operating modes, but they would not be compulsory stages.

A quick check would be used when a decision was familiar, reversible, and low in consequence.

A structured review would be used when meaningful uncertainty justified more examination.

A full council would be used when the stakes, complexity, or irreversibility made additional verification worthwhile.

Even then, the human could decide that a particular role was unnecessary. A simple arithmetic question did not need a philosophical challenge. A question about a current legal requirement needed authoritative legal sources, not five imaginative interpretations. A decision requiring specialist medical, engineering, or legal judgment could benefit from AI assistance, but the council was not a substitute for a qualified professional.

Daniel also added a condition that he had initially overlooked: the review needed a stopping point.

Without one, every disagreement could generate another question, and every answer could produce another layer of doubt. The council might continue long after the decision had enough support for the next reasonable step.

He would define the decision, identify the evidence that mattered, and decide in advance what level of confidence was sufficient for the consequences involved.

If a critical uncertainty remained, he would not conceal it beneath a confident recommendation. He could seek more evidence, reduce the size of the commitment, consult an expert, or decline to proceed.

But he would not keep asking simply because another answer was possible.

The goal was not to reach a state in which no uncertainty existed.

The goal was to make a decision whose risks were understood well enough to accept, manage, or reject.

A Council That Can Learn

Several weeks later, Marcus returned with the results of his expanded test.

The additional customers had not produced a single, simple verdict.

Some had used the service once and stopped. Others had returned. Delivery time had increased for certain types of customer, while other cases were easier to handle than Marcus had expected. A cost he had treated as minor became more significant when measured across the larger group.

The experiment had produced progress, but not a universal answer.

Marcus wanted to know whether to expand again.

Daniel suggested they first compare the results with the conditions they had set before the test. Otherwise, they risked changing the definition of success after seeing the outcome.

They examined the records.

The evidence supported a narrower conclusion than Marcus had originally hoped for: some customer groups appeared more promising than others, and repeat usage depended partly on how the service was delivered. The operation could handle a modest increase, but the cost and workload of serving every type of customer had not been settled.

Marcus considered the options.

He could pursue every customer and attempt to improve the process later. He could stop expanding until the operation was more efficient. Or he could concentrate on the customer group showing stronger repeat usage while investigating the costs that were making delivery difficult.

The council helped examine the implications of each path. It could not guarantee which would succeed.

Marcus chose the third option.

He narrowed the next test, set a limit on the number of customers he would accept, and began tracking the cost and time associated with each service category. He also decided what evidence would justify increasing the limit.

“I'm not ready to say we've found the final model,” he told Daniel. “But I know more about what needs to work before I make it bigger.”

“That is a real result,” Daniel said.

Marcus smiled. “You sound like the council.”

“No. The council might have given you that sentence. I am telling you why I believe it.”

They both laughed.

The distinction mattered to Daniel. He was not trying to become a spokesperson for the system he had built. He wanted to understand its findings well enough to explain them in his own words, including the reasons he might disagree.

An architecture that produced answers its owner could not understand was not yet serving its owner well.

And an architecture that could not be questioned would eventually turn its own procedures into authority.

Daniel returned to his document and added a final section.

Review the decision after reality responds.

The council was not finished when it delivered a recommendation. The decision would enter the world, where customers, costs, people, and circumstances could expose errors in the original analysis.

Those results could become new evidence.

The next council review would not begin with the assumption that the previous answer had been correct. It would begin by examining what happened, what had changed, and which assumptions had survived contact with reality.

This did not mean that every disappointing outcome proved the decision had been foolish. A reasonable decision could produce an unfavourable result. Nor did a fortunate outcome prove that the reasoning had been sound.

Daniel had to distinguish the quality of a decision from the luck of its outcome.

The point of reviewing results was not to rewrite history. It was to improve the next decision.

He looked at the document from the beginning.

It no longer resembled a complicated machine designed to produce certainty. It was a practical arrangement of responsibilities, evidence, constraints, and decision rules.

Its roles could change. Its tools could change. Its methods could improve as better capabilities became available.

But the central arrangement would remain.

The human defined the decision and the stakes. The council examined the problem from distinct angles. Evidence was checked according to the consequences of error. Uncertainty was made visible rather than hidden. The human then chose what to do, accepted responsibility, and returned to the world to discover what the decision had revealed.

Daniel saved the document.

He knew the design still had a weakness.

Even with separate roles, careful inputs, and a disciplined report, the quality of the council depended heavily on the questions it was asked. A badly framed question could direct every role toward the wrong problem. A leading question could make the Challenger perform a weak imitation of disagreement. A request for reassurance could produce a comforting answer dressed as analysis.

The structure was ready for use.

But structure alone could not guarantee that the inquiry would begin in the right place.

Daniel opened a new page and typed the next heading:

The Architecture of Questions.

He remembered the early days, when he had treated a prompt as a command and a response as a result. He now understood that the question was more than the entrance to the process. It helped determine which parts of reality the process would examine, which assumptions would remain hidden, and which answers might never be considered.

He had designed the council.

Now he had to learn how to question without quietly instructing the council what he wanted it to find.