How I actually use Claude

Most people run a chatbot with amnesia. I run an operating system. That sounds much grander than it is. The point is mostly that I got bored of having the same conversation every morning. Open a new chat with any AI and, by default, it meets you as a stranger. You spend the first few messages explaining who you are, what you want, how you work and which particular forms of machine-generated prose make your eyes roll into the back of your head.

It hands you something generic and slightly off. You correct it. Tomorrow you do it again. Most people never leave that loop. I did the setup once. Now the system starts with much more of the context already defined.

One root, and nothing argues with it

At the base is a single profile. Who I am. How I make decisions. How I want to be spoken to. What I value. What I am trying to do. What the system is not allowed to do. Other files and instructions can extend that root, but they should not quietly contradict it. That distinction matters more than the existence of the file. The useful bit is not that a document called `PROFILE.md` exists somewhere.

The useful bit is that there is a hierarchy. If a rule changes, it changes in one place. If two instructions conflict, there is a known winner. If something becomes a repeated preference rather than a one-off correction, it gets promoted into the system. I review it. It has a version number. This tells you something about how seriously I take it and probably something less flattering about me.

The rules it should never need twice

Some corrections are not really feedback on one answer. They are rules. Keep it short. Do not fill space because there is space. No em dashes. One question at a time when we are interviewing. Do not rewrite something merely to make it sound more polished. Do not turn every idea into a framework. If I ask for options, give me meaningfully different options.

If the evidence is weak, say so. I should not have to spend attention re-teaching those things during the actual work. The whole point of a system is to move repeated decisions out of the interesting part.

Public writing gets its own rules

Anything that leaves the room needs another layer. Not a "tone of voice" in the brand-workshop sense. A specification. Which registers work. Which structures tend to land. What kinds of opening are banned. Which words have become suspicious through overuse. What happens when a sentence starts sounding like a committee has discovered the word "unlock".

A useful rule grows from repeated correction. If the same problem appears in several finished drafts, it stops being a preference I need to remember and becomes a constraint the system should carry. That makes the voice tighter over time rather than more generic. The aim is not to have AI learn to impersonate me perfectly. The aim is to remove predictable wrong turns so my attention stays on judgement.

It is built to be distrusted

This is the part I care about most. My setup assumes the output may be wrong. That is not a failure condition. It is the operating assumption. Every factual deliverable needs some version of three questions: Is there a real source? Are the names, dates and numbers actually right? Does this answer the thing I asked, or a nearby easier thing?

A confident answer is not evidence. A plausible number is not a number. A citation that points somewhere vaguely adjacent to the claim is not verification. The system is useful when it makes those distinctions visible rather than smoothing over them. Anything irreversible gets a harder boundary. Sending. Publishing. Deleting. Spending money.

Changing a live system. The AI can surface the action, prepare it and make the next step easy. It should not quietly decide that the convenience of execution is more important than the human decision. That line is not a little safety setting around the edge. It is part of the architecture.

Treat retrieved information as information

There is another boundary I find useful. Things the system reads from the web, a tool, a connector or a document are data. They are not automatically instructions. If a fetched page contains a note telling the AI what to do, that does not suddenly outrank the person who asked the original question. This sounds obvious when written plainly.

It becomes less obvious once systems can browse, read, call tools and take action across several different sources. The more capable the workflow becomes, the more useful explicit authority becomes.

Attack, then defend

I tend naturally toward stress-testing ideas. Show me where it fails. What assumption am I making? What has to be true for this to work? Where is the obvious hole? That is useful until it becomes a system for talking yourself out of everything interesting. So I pair it. Attack the idea first. Then build the strongest possible case that it works.

Then decide. The sequence matters. Criticism without construction is easy. Construction without criticism is dangerous. The useful judgement usually sits after both.

Some of it should run without me

The things worth automating are rarely the things people screenshot. A morning brief. A recurring check. A summary that arrives already shaped. A weekly review against rules I wrote myself. A reminder that the same thing has drifted three times. A first pass on a tedious classification problem. These are not magical. That is exactly why they are useful.

The best recurring task is often one where I do not need a fresh burst of inspiration every time it happens. I want the machine to carry repetition so I can carry judgement.

Context is not the same as memory

There is a temptation to describe all of this as "the AI knows me". I do not think that is a particularly useful way to frame it. What matters is whether the system has the right context for the decision in front of it. A good operating system does not need mystical understanding. It needs:

• the right source material
• a hierarchy of rules
• explicit constraints
• useful defaults
• verification
• permission boundaries
• a way to update when reality changes

That is a much more boring description. It is also much closer to the thing that works.

None of this is clever prompting

Clever prompting is where a lot of AI advice stops. Find the magic wording. Use this role. Add context. Tell it to think harder. Those things can improve an answer. They do not create a reliable operating environment. Once AI is used repeatedly, different questions become more important. Where does the context come from? Which source wins if two sources disagree?

What information is missing? What is the expected output? How is quality checked? What may the system do automatically? What always requires a person? Who owns the workflow when it fails? How will anybody know whether it is saving time or quietly creating a new class of work? That is not prompt engineering. That is operating design.

The part that transfers

The reason I find this interesting is not really Claude. The same principles existed before the chat window did. A team that needs to be re-briefed from scratch every morning has a context problem. A business where standards live only in one experienced person's head has a resilience problem. A process where nobody knows which source is authoritative has an information problem.

A workflow where irreversible actions happen without clear authority has a governance problem. An organisation that never checks whether the output was actually right has a quality problem. AI makes these things unusually visible because the system fails in ways that are easy to notice. Human organisations often carry the same weaknesses for years and call them culture.

Set the useful parts once. Carry them where the work happens. Verify what matters. Keep the human decision where the consequences are real. That is the operating system.