Handling Customer Disagreements
Ask questions about the customer's needs before you propose or reject a solution, because the answers decide which design fits.
A Customer Who Already Drew the Architecture
A customer walks into a design conversation and names the system they want. The architecture is already drawn in their head. There are two easy responses. The first is to nod, say it sounds good, and start building. The second is to say the design is wrong and offer something else. Both replies skip the same step: finding out what the customer actually needs.
This article is about that missing step. It also covers how to offer a different design without fighting the customer for it. The skill matters because the answers to a few good questions usually decide which design fits, and a design chosen before those answers arrive is often chosen for the wrong reasons.
Why Questions Come Before Proposals
The first move in a strong response is a question, not a counterproposal. Before a candidate can judge whether a design fits, they need to know the conditions under which that design has worked for this customer or for others. A question such as asking what part of a previous multi-agent deployment worked, and what part was hard, gathers that context without challenging the customer's choice head-on.
The order matters. Asking first gives the customer's answers a chance to change the candidate's view. Judging first means the answers only serve to defend a conclusion that was already reached. The flowchart below shows the order a strong candidate follows: listen to the proposal, ask about needs, name the job, evaluate options against that job, and only then decide whether to accept, adapt, or reject.
Naming the Job Behind the Request
The customer's proposal is a surface request. Beneath it is a job the system has to do. In the source scenario, the customer's team favors the multi-agent shape because they want clear ownership of the compliance review step. The candidate restates this as the real requirement: the review needs a clear boundary.
Once the job is named, the candidate can evaluate several designs against it, instead of arguing over the one design that was drawn first. The job is the yardstick. Any design is judged by whether it does that job, not by whether it matches the picture the customer arrived with.
The diagram shows the reasoning in the source scenario. The review step is inside the boundary the customer cares about, and it needs clear ownership. Intake and draft work sit outside the review step, which is why the simpler version can handle them in a single workflow without weakening the boundary around review.
Two Versions of the Same Review
Once the job is clear, the candidate can describe two versions that both aim at it. In the first, the review is a separate process with its own agent, its own logs, and its own sign-off. This matches the picture the customer brought in. In the second, the intake and draft work happen in a single workflow driven by one prompt that returns structured output.
Scoring the Two Versions Against the Job
The job is a clear boundary around the compliance review step. Judge the separate-agent version and the single-workflow version against that job and against the customer's picture.
- 1Check the job
The separate review process has its own agent, logs, and sign-off, so the review step has a visible boundary and a visible owner.
- 2Check the simpler version
The single workflow keeps intake and draft work together under one prompt. The review boundary is still a question of whether the design makes review distinguishable, so the candidate has to say so explicitly rather than assume it.
- 3Check the tradeoffs
The source says the simpler version is easier to debug, easier to evaluate, and easier to explain to auditors. Its drawback is that it does not match the customer's picture.
- 4Decide what to offer
The candidate has evidence for both sides. The honest next step is to propose the simpler version and a plan to test it, not to declare the customer's design wrong.
Both versions are judged against the same job. The simpler version wins on debuggability, evaluation, and auditability, but the customer's version wins on matching their mental picture. That tradeoff is what the conversation should surface.
Proposing a Simpler Option Without Fighting
The source describes the candidate's move as a path that respects the customer's authority while testing a simpler architecture. The candidate does not force the simpler design. They propose it with its honest tradeoffs and a validation plan, and they let the results decide between the designs.
This framing changes the conversation. The customer is still the decision maker. The candidate provides a comparison the customer can check, and the validation step produces evidence. When the evidence favors one design, the choice comes from the results rather than from a contest of opinions. If the customer's design performs as well on the job, the customer has a reason to keep it, and the candidate has learned something about the actual requirement.
When a Four-Agent Design Earns Its Place
A candidate who rejects multi-agent systems outright makes the opposite error from one who accepts them blindly. The source gives a usable test: the four-agent shape works when each agent has a genuinely different context window and tool set. A multi-agent system fits when the separation does real work, not automatically.
When agents mostly pass the same context back and forth, the shape gets harder to manage. Coordination between agents costs effort, and if the agents share the same context and tools, that effort buys little. The comparison below sorts the conditions the source identifies on each side.
Strong and Weak Responses Compared
The source includes a strong response and a weak one to the same customer. Setting them side by side makes the difference concrete.
| Dimension | Weak response | Strong response |
|---|---|---|
| Opening move | Opens with a verdict | Opens with questions |
| Source of authority | Cites an outside source | Uses the customer's situation |
| Treatment of customer reasoning | Set aside as wrong | Treated as information |
| Handling of the surface request | Argued against directly | Restated as an underlying job |
| Proposed path | Replacement design | Simpler option with tradeoffs and a validation plan |
Weak and strong responses to the same customer design conversation, as described in the source.
Mistakes in Design Conversations
Common mistake Nodding along and starting to build
Why it failsThe customer's architecture is treated as settled before anyone has learned what the system must do.
Do this insteadAsk what the design needs to accomplish and what has worked before.
Common mistake Calling the customer's design wrong at the start
Why it failsA verdict skips the question step and makes the customer defend their choice instead of explaining their need.
Do this insteadTreat the customer's reasoning as information and ask about it first.
Common mistake Arguing against the surface request
Why it failsDebating the one design that was drawn first keeps the conversation at the level of the picture rather than the job.
Do this insteadName the underlying job, such as a clear boundary around the review step, and evaluate several designs against it.
Common mistake Choosing multi-agent by default
Why it failsThe source says the shape fits when each agent has a genuinely different context window and tool set, not automatically.
Do this insteadCheck whether the separation between agents does real work before accepting or rejecting the shape.
Common mistake Forcing the simpler design through
Why it failsThis overrides the customer's authority and leaves no evidence for the choice.
Do this insteadPropose the simpler option with honest tradeoffs and a validation plan, and let the results decide.
Practice: Reading a Design Conversation
What do you think happens?
A customer says they want four agents because they want clear ownership of the compliance review. What is the strongest first response?
Reveal answer
Ask what part of a previous multi-agent deployment worked and what part was hard
The source says the first move in a strong response is a question. Asking what worked and what was hard gathers context without challenging the customer's choice head-on.
Imagine a customer who wants one agent per step of a loan document check because they want clear ownership of each step. Write three questions you would ask before judging the design. Then restate the underlying job in one sentence, and name one simpler option you could propose along with a validation plan that would let the results decide.
Hints
- Start with a question about what has worked or been hard in past deployments.
- The underlying job might be a clear boundary or a clear owner, not the number of agents.
- Your validation plan should compare both designs against the same job.
Key Takeaways
- Ask questions about the customer's needs before proposing or rejecting a solution, because the answers decide which design fits.
- Name the underlying job behind a surface request, such as a clear boundary around a compliance review step, and evaluate designs against that job.
- Propose a simpler alternative with honest tradeoffs and a validation plan, and let the results decide between designs while the customer keeps authority.
- A multi-agent system fits when each agent has a genuinely different context window and tool set, not automatically.