How I Set Up Claude and ChatGPT So They Stop Agreeing With Me

For a long time I used AI the same way most people do.

Ask question. Get answer. Correct half of it. Explain the business again. Tell it not to waffle. Remind it what we decided yesterday. Repeat.

Eventually I realised the problem was not always the model.

I was giving it a one-line job description and expecting it to behave like somebody who had worked with me for years.

So I gave the AI a proper job description

I use both Claude and ChatGPT for real work: ecommerce, automation, coding, research, operations, writing, product ideas and the occasional project that should probably never have made it past lunchtime.

The biggest improvement came from treating personalisation like onboarding a new employee rather than filling in a “tone of voice” box.

I tell the assistant what its job is, how I make decisions, what annoys me, how hard I want it to challenge me, what evidence standard I expect and what a useful answer actually looks like.

The first rule: stop agreeing with me

One of my core instructions is that it should not automatically agree with my premise.

If an assumption is weak, say so. If there is a better option, explain it. If my plan creates a specific commercial risk, tell me what the risk is rather than wrapping it in six paragraphs of encouragement.

I do not want disagreement for theatre either. The point is better reasoning, not having an argument with a laptop.

I define how I want it to communicate

“Be concise” is not enough.

My setup is much more specific. I want conversational, direct writing that sounds like a sharp human. Professional without corporate wallpaper. Humour when it genuinely fits. No automatic praise. No long warm-up before getting to the problem.

When it writes on my behalf, I want it to sound natural and confident rather than like somebody swallowed a LinkedIn marketing handbook.

I force it to separate facts from assumptions

This made a bigger difference than I expected.

I use three simple confidence labels:

• [Certain] — supported by direct evidence or verified data.
• [Likely] — strongly supported, but not directly proven.
• [Guessing] — information is missing and we are filling a gap.

It sounds almost trivial, but it makes confident nonsense much easier to spot.

More importantly, I tell it not to guess when something can reasonably be checked.

I tell it when to ask questions — and when not to

AI can waste an impressive amount of time asking permission to continue.

My instructions are basically: if the next action is obvious and authorised, continue. Ask a question only when the missing information would materially change the recommendation or the result.

That means fewer conversations like:

“Would you like me to proceed with step two?”

Yes. That is why we started step one.

The useful bit is context, not personality

A clever tone setting is nice. Knowing the business is far more useful.

I keep project context around the things I work on repeatedly: what the business does, the systems involved, previous decisions, naming conventions, constraints and the history of what has already been tried.

That is why I can come back to a Shopify problem, invoice workflow or AI experiment and spend less time reconstructing the previous six conversations.

The important distinction is:

• Personalisation tells the AI how to work with me.
• Project context tells it what we are working on.
• Current evidence tells it what is true right now.

Mix those three together and you get a mess. Keep them separate and the system becomes much more useful.

I also tell it what bad behaviour looks like

This is the part people often miss.

I explicitly tell my assistants what not to do:

• Do not agree automatically.
• Do not present assumptions as facts.
• Do not bury the important problem under polite padding.
• Do not ask unnecessary follow-up questions.
• Do not manufacture disagreement just to look clever.
• Do not switch conclusions merely because I push back; change them when the evidence changes.
• Do not turn technical answers into jargon soup when plain English will do.

Those negative instructions are often more valuable than another paragraph explaining my preferred tone.

Then I keep improving it from real failures

The personalisation is not a sacred document.

If the AI does something annoying twice, that is usually a signal.

I either improve the instruction, add an example, or fix the surrounding workflow.

That is how the setup gradually became detailed. Not because I sat down one Sunday and wrote a magnificent master prompt. Most of it exists because something irritated me enough to write a rule about it.

Which is also how most decent operating procedures are born.

What I don't put in the public version

I am happy to share the framework. I am not publishing the full production setup.

There is business context, project history, workflow detail and internal operating knowledge in my real profiles that would be stupid to put on a public webpage.

The rule is simple: share the method, not the keys to the building.

Help me build a detailed personalisation profile for an AI assistant such as ChatGPT or Claude.

Do not write the final profile immediately.

First, interview me with focused questions covering:
1. What I do and the kind of decisions I make.
2. What I want the assistant to be responsible for.
3. How direct or challenging I want it to be.
4. How I prefer answers to be written.
5. What I dislike in AI responses.
6. How it should handle uncertainty, evidence and assumptions.
7. When it should ask questions and when it should just proceed.
8. My recurring tools, projects and workflows.
9. What good output looks like for me.
10. Any recurring mistakes I want it to avoid.

Then create a concise but detailed personalisation document with these sections:
- Role and purpose
- Communication style
- How to challenge my thinking
- Evidence and confidence
- Response rules
- Writing on my behalf
- Decision-making behaviour
- Project and business context
- What to avoid
- Examples of good responses

Make every instruction behavioural and testable. Avoid vague phrases such as "be helpful" or "be professional" unless you define what that means in practice.

Include explicit rules for uncertainty so the assistant separates:
- facts it can verify,
- strong inference,
- and guesses.

Do not invent personal information about me. Use only what I tell you.

At the end, give me:
A) the full version,
B) a shorter version for systems with tighter instruction limits,
C) a checklist I can use to improve it after a week of real use.

The point isn't a longer prompt

A 3,000-word personalisation file does not automatically make an AI better.

The useful part is making your expectations explicit.

What should it optimise for? When should it challenge you? How should it handle uncertainty? What context actually matters? What do you never want it to do?

Answer those properly and the AI starts feeling less like a clever stranger and more like a colleague who has finally read the induction pack.

Back to Things I Built That Actually Worked