How Claude actually works — and how to unlock it

Most people use Claude the slow way: type, wait, copy, fix, ask again — all by hand. It isn't that the fast way is hard. Nobody has shown you what's happening under the hood. See it once and it clicks. This guide comes in two halves — first you understand how Claude actually works, then you unlock it — and every section ends with 🔓 the unlock: the one change it makes to how you work. No code required to follow along.

Claude is two workers, not one

Almost everything else in this guide clicks the moment you can tell Claude's two halves apart, so start here. The Brain is the AI model — the thinking part, the same kind of engine behind the chatbot you already know. The Hands are Claude Code, the app running on your computer that can actually do things: read files, edit them, run tests, search the web.

The Brain decides what to do; the Hands do it. On their own, each is nearly useless — a brain with no hands can only talk, and hands with no brain don't know what to reach for. Bolt them together and you have an agent, and you're the one directing it. One consequence falls out of this immediately, and it reshapes how you should think about every disappointing result: the Brain never touches your world directly. So whatever it produces is capped by what the Hands can reach.

They pass work back and forth in a loop

Watch what happens when you ask for something concrete — say, "add a test for the calculator." The Brain looks at your request and notices the calculator file isn't in front of it. A chatbot would guess and hallucinate something plausible. The agent doesn't. It reaches into its list of tools, sees it has a Read tool, and instead of writing an answer it asks for the file. The Brain can't open anything itself, so it hands that request to the Hands.

The Hands read the file off your disk, pass the contents back, and now the Brain can actually work: it writes the test, edits the file through an Edit tool, then runs your test suite through a Bash tool to check its own work. Reason → tool → result → reason again. That cycle — not raw brilliance — is what separates an agent from a chatbot. The chatbot answers once; the agent keeps going until the job is genuinely done.

It has no memory — at all

Here's the fact that surprises almost everyone: the AI model is completely stateless. On its own it has zero memory of anything you said a moment ago. The smooth, flowing "conversation" is an illusion the Hands maintain — every time you hit Enter, they quietly reassemble the whole package above and hand it to the Brain, which reads it fresh as if for the first time.

That reframes what a prompt even is. Whatever sits in that package is the entire universe Claude knows about for that turn. If a fact is in there, Claude can use it. If it isn't — a decision you made yesterday, a file you never opened, a preference you assumed it remembered — then as far as the Brain is concerned, it doesn't exist. Great results and confused ones both trace back to what made it into the package.

Part 1 was the machine. Part 2 is the steering. Three controls decide almost everything about how Claude behaves for you — and they map cleanly onto the three questions you'd ask about any new hire: what does it know, what may it do, and what can it do in one move?

Teach it once with CLAUDE.md

We just saw that the Brain forgets everything between turns — so the obvious question is: how do you make it remember the things that never change? You don't repeat yourself. You write them down once, in a plain text file named CLAUDE.md at the root of your project, and the Hands load it into the package automatically on every session.

The cleanest way to think about it is onboarding an employee. A new hire is capable, but on day one they don't know your conventions, your tools, or the things your team simply never does. So you write a short handbook: here's how we build, here's the style we use, here's what to avoid. CLAUDE.md is that handbook for Claude — build commands, coding style, project rules, the "always" and "never" list. Written once, it shapes every reply without you ever typing it again.

Hold the keys with permissions

Because the Hands touch your real machine, every single action they take is checked against your permission rules before it runs — a plain allow / ask / deny list saved in a settings file. This is the one control that isn't advice: instructions shape what Claude tends to do, but permissions guarantee what it can and can't do. A deny rule holds even if something in the conversation tries to talk the model into ignoring it — the Hands, not the model's good intentions, enforce the line.

Here's the full picture in one table:

Two commands end the endless clicking. /permissions opens the list so you can edit it by hand. Better, /fewer-permission-prompts reads back through your past sessions, finds the safe commands you keep approving, and adds them for you — conservatively, telling you exactly what it skipped and why. And when several rule files disagree, they resolve in a strict order:

It's almost a reverse hierarchy — the layer closest to the organization wins, so a personal setting can never override what the company locked in. Put your own taste in user settings, shared norms in the project file, and non-negotiables at the top. Then, moment to moment, shift the gear to fit the task: Plan mode when you want it to think before touching anything, Accept-edits for flow, Auto for chores — while your deny rules stay locked in every one.

Automate it with skills

---
name: deploy
model: sonnet
---
1. run the tests
2. build the app
3. ship to $ARGUMENTS

The last control is the one that compounds. A skill lets you bottle up a whole workflow behind a single word. It's just a plain markdown file — a short recipe of steps — with a few lines of config on top that set which model runs it and who's allowed to trigger it. Once it exists, a job that used to take a paragraph of instructions takes one slash command. The $ARGUMENTS slot even lets you pass in a word — /deploy staging drops "staging" right into the recipe.

You don't hand-write these. Run the built-in /skill-creator, describe the job in a sentence or two, and it writes the file for you. This is where the whole guide pays off: the more of your repeat work you bottle into skills, the more Claude stops being a thing you operate move-by-move and becomes a set of one-word commands that run your actual process.

Which brings up the part almost everyone walks straight past. There is one moment when making a skill is easiest, and it isn't when you sit down to plan one — it's the moment you just finished something.

Say you run a small agency and you just spent an hour walking Claude through onboarding a new client — pulled their site, audited the pages, drafted the kickoff doc, set up the tracker, fixed the two things that came out wrong. It came together. The instinct is to close the tab and get on with your day. That's the moment to stop, because you've just done something better than describing a process: you've proven one.

Run /skill-creator before you leave that session and Claude writes the skill from the conversation you both just had. You don't have to remember the steps or explain them well — the steps are right there in the history, including the two corrections you made along the way. Next client, that hour becomes /onboard acme-co. The same move works for anything you just pushed through end to end: a landing page, a monthly report, an SEO pass, a launch checklist.