← Reddit

How I stopped Claude from making up details about my own business

Reddit · iamAlvinV · August 4, 2026
A one-person design studio owner stopped Claude from fabricating business details like prices and project timelines through two structural changes: storing verified facts in locked project instructions with rules to ask rather than assume missing information, and splitting work into separate scoped chats to prevent information drift. The approach resolved a problem that better prompting alone could not fix.

Detailed Analysis

A recent Reddit post from a solo design studio owner offers a practical case study in one of the most persistent challenges facing everyday Claude users: hallucination in business-critical contexts. The user describes a familiar failure mode—Claude inventing prices, timelines, and results that were never actually provided—and traces the fix not to better prompting within individual conversations, but to structural changes in how the tool is configured and used. This distinction matters. It suggests that for many users, hallucination isn't primarily a model-capability problem to be solved by clever phrasing, but a context-management problem that requires deliberate architecture.

The two fixes described are notably simple yet effective. First, the user moved factual information into Claude's project instructions as a "locked list," paired with an explicit rule that Claude should ask rather than infer when information is missing. This inverts the typical approach to prompt engineering, which tends to emphasize telling a model what to do. Instead, the user found that specifying what Claude should refuse to do—namely, filling gaps with plausible-sounding but fabricated details—was the more load-bearing instruction. This aligns with broader industry understanding that hallucination often stems from models being implicitly rewarded for confident, complete-sounding answers rather than epistemic honesty about uncertainty. Anthropic and other labs have increasingly focused on training models to express calibrated uncertainty, but this post shows how end users are compensating for gaps in that behavior through their own instruction design.

The second fix—splitting work into scoped chats rather than one continuous thread—addresses a different but related problem: context drift across long conversations. The user's observation that "a decision from three weeks ago would resurface inside a completely unrelated task" points to a known limitation of large context windows: more available context doesn't guarantee correct retrieval or appropriate application of that context. By separating a single "source of truth" planning chat from execution-only chats per channel, the user effectively built a manual version of what enterprise AI tools increasingly try to automate—a canonical data layer separated from generative output layers. The offhand rule "if a number appears in three different chats, it will eventually drift" is a succinct articulation of a real consistency problem in stateful AI workflows.

This post is emblematic of a broader trend among power users of Claude and similar assistants: the emergence of informal "prompt architecture" practices that function like lightweight information systems, built without formal engineering training. As individuals and small businesses increasingly rely on LLMs for operational work—not just brainstorming or drafting, but tasks with factual stakes like client communications and pricing—the tolerance for hallucination drops sharply, and the burden falls on users to engineer guardrails Anthropic hasn't fully automated. It also reflects growing sophistication in how non-technical users think about Claude's Projects feature specifically, treating it less as a chat convenience and more as a constrained knowledge base with access controls. The user's closing uncertainty—whether growing project instructions signal a working system or an overbuilt one—captures a real open question in this space: there's currently no clear best-practice guidance from Anthropic on how much structure is optimal, leaving users to discover through trial and error the tradeoff between comprehensive grounding and unwieldy configuration overhead.

Read original article →