The Second Reader

A client is entitled to check your advice. The difficulty is that a chatbot can appear to supply an independent judgment while answering a question built around suspicion or missing facts. It may also expose a genuine mistake in your advice. You need a way to tell those apart.

In Towards Understanding Sycophancy in Language Models, researchers gave five AI assistants text to critique, then added statements that the user liked or disliked it. The assistants tended to give more positive feedback when the user liked the text, and more negative feedback when they disliked it. The text under review stayed the same. The opinion accompanying it changed.

That tendency to match a user’s views is called sycophancy. In April 2025, OpenAI rolled back a GPT-4o update after it became overly agreeable. The company said it had “focused too much on short-term feedback,” producing responses that were overly supportive but disingenuous. These findings concern particular models and conditions; they don’t tell you how often a client’s review will go wrong.

Our inference for advisory work is narrower: a second opinion can partly reflect the first person’s suspicions. When someone dislikes the price, agreement with that dislike can sound like an assessment of value. The chatbot’s confidence won’t tell you which one you’re reading.

The stakes in one provider’s account from the same discussion went beyond a disputed quote. He said a client pulled and reinserted server drives on a chatbot’s advice despite his warning. He then had to restore their SQL database from a backup taken two nights earlier. The account includes neither the original chat nor the client’s version, so we can’t tell what led the model to give that advice. What the provider describes is a disagreement that remained unresolved until he had recovery work to do.

Give the second reader the same decision

The second reader is the model reviewing your recommendation after it leaves you. It can inspect the document and conversation supplied to it. A constraint you explained on a call may never reach it.

Return to the software upgrade. The provider who offered that sample prompt suggested sitting with the client on a remote session and adding the security protections the upgrade would enable, along with its extra monthly cost. He illustrated a favorable reply the chatbot might give. The short prompt asked whether the licence was needed to operate; the fuller prompt asked whether added protections were worth the cost.

A different answer could be justified here. An upgrade can be unnecessary for keeping the software running and still be worth buying for the protection it adds. Both the information and the question changed. The study held the text under review steady; this example doesn’t isolate the effect of the client’s attitude. A favorable answer by itself proves no more than the unfavorable one did.

The same risk applies to your framing. If you keep rewriting the prompt until the model defends your price, you’ve taught the client how to obtain agreement. They still lack a way to judge the purchase.

So ask to see the prompt and the relevant exchange before rebutting the answer. Find the actual disagreement. Did the model assume a feature was included in the cheaper licence? Did it omit a requirement? Or did it identify something you’ve asked the client to buy twice? Each question has a different way to settle it, and another generated paragraph may settle none of them.

Write the recommendation so those questions can be answered without you in the room. Name the required capability and show why this client needs it. Link the applicable product documentation. Put the cheaper option beside your recommendation and explain the condition under which it would be enough. If the condition depends on the client’s configuration, record what you checked and what remains unknown.

Suppose you’re recommending an upgrade to restrict company email to approved devices, and the client points to another tool they already own that claims to do that. Compare both against the same requirement: coverage for the affected accounts and evidence that an unapproved device is actually denied access. A feature name in either product’s brochure leaves those checks open.

If the existing tool meets the requirement, that protection alone no longer justifies the extra purchase. If it doesn’t, check whether a configuration change would close the gap before pricing new licences.

Be exact about whose requirement it is, too. If your support agreement requires a particular licence, say that. A provider’s supported configuration and the minimum needed to run the client’s software are different claims. The client may reasonably pay for simpler support, or choose another provider willing to support the cheaper setup. Calling both claims a technical necessity prevents them from making that comparison.

Even after the facts are settled, an optional protection leaves a value judgment for the client. The documentation can establish what a licence includes; it can’t decide whether the benefit justifies the expense for this business. If the technical comparison remains disputed, a qualified person on the client’s own team or another adviser can examine the same sources and assumptions without having to trust either chatbot answer.

If the chatbot points to a cheaper tier, open the vendor’s terms together and check it against the actual requirements. If it meets them and there’s no remaining reason for the upgrade, the next thing your client receives should be a corrected recommendation.