Recommend, don't only respond

Traditional software waits. It waits for the person to find the right feature, ask the right question, or notice the problem. A meal planner waits until the household discovers Tuesday's meal is too long, then maybe offers a search box. Intelligent software can recognise opportunity. After CritiquePlan flags Tuesday's stir-fry as impractical for a busy evening, RecommendMealSubstitution proposes a patch with trade-offs before the household asks. That shift from respond to recommend is how co-planner tone replaces support-bot tone.

Helpful context: Cognitive posture bounds when initiative is appropriate. Point and fix and low-cognitive first draft are neighbouring patterns recommendation serves.

The difference between respond and recommend

Respond-only products ask "anything else I can help with?" after a flaw is visible. The flaw is material, critique already ran, and the system has enough information to propose a fix. Recommend-first products say "Tuesday's meal exceeds your busy-evening budget, here are two swaps under twenty-five minutes." The distinction is not about chattiness. Respond-only answers "what is FODMAP?" when asked. Recommend-first notices a spinach deadline conflict and proposes moving the spinach meal to Monday before the household discovers the clash at shopping time.

Respond-only	Recommend
Anything else I can help with?	Tuesday's meal exceeds busy-evening budget, here are two swaps
Answers what is FODMAP?	Spinach deadline conflicts, move spinach meal to Monday?
Lists ten recipes on request	Ranks candidates with reasons after critique

The distinction becomes visible in how the product feels over multiple sessions. Respond-only feels like a tool that waits. Recommend-first feels like a collaborator that notices. The architectural difference is that recommendation requires critique to have already identified a gap, and a cognitive unit that can generate ranked alternatives with grounds. Without both, recommendation degrades into random suggestion.

Recommendation as conduct, not interruption

Unexplained recommendations cannot be evaluated. A suggestion without evidence is an interruption, and recommendation fatigue erodes trust faster than being occasionally wrong. The relationship between confidence and behaviour matters here: high confidence terrain may support proactive recommendation, medium confidence may offer alternatives for the person to choose among, low confidence may ask a clarifying question, and very low confidence should stay silent until the person invites engagement.

This means the product generates several candidates, ranks them against constraints and preferences, and surfaces the best with a reason. The reason attaches enough evidence or trade-off for the person to accept, reject, or revise. Recommendation without accept and reject instrumentation cannot improve, because the system never learns which proposals fit the household and which waste attention.

Authority still bounds the act

Recommendation sits inside authority that is granted and the Collaboration Contract. A system may recognise a useful grocery bundle and still lack permission to purchase. Silence beats poor advice when stakes exceed supported terrain. The same applies in the other direction: recommendation about medical diets exceeds granted authority even when the model feels confident about the suggestion.

Instead of waiting to be instructed, it can increasingly recognize opportunities to help before users ask.

Thoughtware: Designing in the Intelligence Age · Ch. 11

Authority bounds apply even when the recommendation itself is correct. A system that auto-applies a recommendation it should have offered for approval has violated the collaboration contract regardless of outcome quality. The co-planner tone depends on the household retaining ownership at the points that matter to them.

Timing, posture, and cadence

Cognitive posture sets when recommendation is welcome. After critique surfaces a gap, recommendation feels helpful because it addresses a known problem. Mid-utterance, it feels interrupting. After refusal, repeated identical recommendation feels stubborn. Posture parameters should include backoff after reject because refusal is signal, not noise.

Recommendation cadence is a designed parameter with metrics, not an emergent property of model temperature. Cap suggestions per session. Cap per surface. Tie cadence to posture scores from offline eval. Sales demos often crank initiative to impress. Production posture matches contracted collaboration modes, not demo theatre. Three unprompted recommends per planning session is a reasonable budget unless the user invites more.

Learning from accept and reject

Accept rates alone mislead. A household may accept to end interruption rather than because the recommendation fit. Track reject with reason when possible. Track whether accepted recommendations reduced later correction, the true signal that the recommendation added value. Offline eval should include recommendation suites tied to specific terrain scenarios like busy-week and spinach-deadline cases, not generic helpfulness labels that miss product-fit.

The instrumentation schema matters: recommendation_id, weakness_type, options_shown, accept, reject, reject_reason. That schema enables posture tuning and offline eval improvement. Recommendation without instrumentation cannot improve because there is no feedback path from household behaviour to system adjustment.

The critique to substitution chain

In the Meal Companion, CritiquePlan returns material weaknesses in the complete plan. RecommendMealSubstitution consumes those weaknesses plus accepted work and constraints, then returns ranked patches with reasons. The household accepts one patch via point and fix. JudgeLocalRepairQuality grades the repair offline. That chain is recommendation as architecture, not as a friendly sentence appended to chat.

Products that skip CritiquePlan and recommend from raw generation hide weaknesses until the household discovers them at dinner time. The critique step provides the evidence that makes recommendation grounded rather than random. Without it, recommendation degrades from "here is a fix for a known problem" to "here is something the model thought of," which is precisely the support-bot tone this pattern replaces.

When to stay silent

Very low confidence terrain, missing authority, or repeated refusal should suppress recommendation. Silence is conduct. Unexplained silence feels like neglect, but explained deferral feels like honesty: "no swap suggested, current meal already meets busy rule." The distinction between silence-with-grounds and silence-without-explanation is the difference between a system that knows its limits and one that appears broken. See refuse and defer for the broader pattern.

Recommendation and visible thinking

Each recommendation should carry enough rationale for visible thinking without chain-of-thought theatre. "Busy evening rule plus recipe active time" beats an internal token dump. Ranked alternatives with trade-offs between them let the household choose with understanding rather than accept on faith. When two options are close, showing both with reasons teaches the household what the system considers, which builds trust even when the household overrides.

The connection to visible thinking is structural: recommendation without rationale is a black-box suggestion, and black-box suggestions erode trust on the first wrong answer. Grounded recommendation with visible reasons survives occasional mistakes because the household can see where the reasoning went wrong and correct that layer specifically.

Idle chat as anti-pattern

"Anything else I can help with?" after a visible plan flaw is support-bot tone. The flaw is material. Critique already ran. Recommendation should follow. Idle chat wastes the critique investment and trains the household to expect passivity. The architectural alternative is clear: when critique identifies a gap and terrain supports initiative, the system proposes a fix with grounds. When no gap exists and no opportunity is visible, silence or a status confirmation is honest.

Replace idle prompts with grounded next actions or honest silence. The household learns that when the system speaks, it has something to say, and that when it is quiet, the current state is sound. That contract between initiative and silence is how recommendation cadence builds trust rather than fatigue.

Common failures

The most frequent failure is recommendation without critique: proposing substitutions without CritiquePlan evidence risks random change that erodes trust faster than passive responding. A close second is auto-acting on recommendations that exceed granted authority, where the system buys groceries because it recommended a bundle the household did not explicitly approve. Recommendation fatigue from uncapped initiative produces households that ignore all suggestions including the valuable ones. And recommendation without instrumentation means the system cannot learn from accept and reject signals, making every session equally naive.

What to do next

The shift from respond to recommend begins with identifying moments where critique has already surfaced a gap and the system has enough information to propose a fix with evidence. Each recommendation needs a reason shown, an accept path, a reject path, and instrumentation that feeds back into posture tuning. The critique step provides the grounds that distinguish grounded recommendation from random suggestion. Without critique, recommendation is interruption. Without instrumentation, recommendation cannot improve.

See what a summary leaves out, memory is part of UX, and point and fix.

Read next: What a summary leaves out.