Understanding Customer Needs

A customer walks into a design conversation and names the system they want. The architecture is already drawn in their head. When that happens, there are two easy replies. 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. The answers to that question decide which design fits, so a response that skips it is guessing.

Think of a design conversation as a sequence of states. The conversation starts with a surface request, which is the system the customer has already described. Next comes a question-driven state, where the candidate learns the conditions under which the design has worked for this customer or for others. Then comes a naming state, where the candidate states the job the system has to do. Only after that can several designs be compared against the job. Each state changes what the candidate knows, and the proposal should come last, not first.

The first move in a strong response is a question, not a counterproposal. Asking what worked and what was hard in a previous deployment is useful because it reveals the conditions under which a multi-agent design has succeeded or struggled. The candidate does not yet know whether the design fits, and the question is how that gets learned.

The customer's proposal is a surface request. Beneath it is a job the system has to do. The job is what the design must accomplish. The surface request is one proposed way to accomplish it. Separating the two lets the candidate judge several designs against the job rather than defending or attacking the one design that was drawn first.

Once the job is clear, the candidate can describe two versions that both aim at the same boundary. In the first, the review is a separate process with its own agent, its own logs, and its own sign-off. In the second, the intake and draft work happen in a single workflow driven by one prompt that returns structured output. Both versions can be described in terms of the same requirement, which is what makes them comparable.

The source names the tradeoffs of the simpler version directly: it is easier to debug, easier to evaluate, and easier to explain to auditors. Its drawback is that it does not match the picture the customer came in with. The multi-agent version matches that picture, but it adds separate agents, logs, and sign-offs that must be managed. Neither version is automatically correct. The comparison depends on the job and on whether the separation between agents does real work.

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. The multi-agent design is not justified by its existence. It is justified when the separation between agents does real work.

The flowchart above is a generated teaching aid built on the source's test. The first check asks whether each agent really needs its own context and tools. The checkpoint asks whether agents are mostly passing the same context back and forth, since the source says that makes the shape harder to manage. If the answer to the checkpoint changes, the candidate should revisit the split rather than defend it.

After naming the job and comparing designs, the candidate can propose a simpler alternative. The source's guidance has three parts: the proposal should carry honest tradeoffs and a validation plan, it should respect the customer's authority to accept or reject it, and it should let the results decide between designs. The candidate offers a path to test, not a verdict on the customer's choice.