Make the Machine Yours

A modern general-purpose AI is extraordinarily capable. It can write, code, research, argue and build. Many systems now remember things between conversations, organise work into projects, read files you give them and connect to your other accounts. All of that is useful.

None of it means the machine knows how you work.

The default system is built to serve an enormous number of people. It can form a reasonable impression of your interests, but it may not have the records that matter, may not recall the decision you made last month, may not retrieve the earlier conclusion that changes today’s answer, and may not apply the way you want this kind of work done. It answers you competently, much as it would answer anyone.

This chapter is about closing that gap deliberately. The model provides general capability. The context, memory, instructions, tools and feedback around it are what make that capability useful for your particular purposes. None of this requires retraining the model, and none of it turns the machine into a copy of you. What it does is get more of your knowledge, intentions, standards and working methods into the system you work through — so that its work increasingly serves what you are actually trying to do.

Memory is not context

The most important idea in this chapter is a distinction that most people never make.

Memory is what remains available from previous work: research findings, earlier discussions, decisions, preferences, rejected approaches, records of experiments, unfinished tasks. Context is what the machine actually has in front of it while doing the current task: this question, these documents, these instructions, these earlier decisions, these constraints.

The two fail differently. A machine can have the right information stored somewhere and still give a poor answer, because that information never made it into the context of the task at hand. And a machine given everything it knows, all at once, can do worse than one given a few relevant things, because the important detail is buried. Chapter 07 made the same point about coding agents. Here it applies to everything you do with AI.

So the goal is not a machine that remembers everything in every conversation. Good memory is retaining what matters. Good context is bringing the right part of it into the work when it is needed. A large part of making the machine yours is learning to notice which one has failed: when an answer is wrong because the machine never knew something, and when it is wrong because it knew and did not use it.

I will not go into how retrieval works underneath — embeddings, indexes, context windows. Those mechanisms matter, and my more technical books cover them. What matters here is what you can observe and what you can change.

A project you can leave and return to

Here is the situation that makes all of this concrete.

You get interested in an idea — a scientific question, a technology, a possible application. You discuss it with an AI, read several papers, explore what it might be used for, find something promising, and hit a difficulty. Then life intervenes. Other work, other interests. Weeks pass.

When you come back, what were you trying to find out? Which papers mattered and which turned out to be irrelevant? Which ideas had you already rejected, and why? What did your small experiments actually establish? What was the next thing you meant to try?

Without retained context, you reconstruct all of it, badly, from fragments — or you quietly give up. With a well-kept working environment, the machine can help you recover it from the notes, sources, decisions and records you left behind, and tell you clearly which parts it found in the record and which parts it is guessing.

A project can stop without disappearing. That changes what an individual can sustain. Most people with many interests have a graveyard of half-explored ideas, abandoned not because they were bad but because resuming them was too expensive. When resuming is cheap, the graveyard becomes a library. And Chapter 17 adds a reason to visit it: a capability that did not exist when you stopped may be exactly what makes the old idea work now.

This book is itself an example. It has been written across many sessions with several different AI systems, none of which carries the work in its own memory. What carries it is a set of plain files in the repository: a living editorial index that records what each chapter is for and what state it is in, evidence notes for each chapter recording what was verified and what was not, and an instruction file telling any agent how work is done here. Every session starts by reading them. Nothing about that is sophisticated. It works because the records are durable, inspectable and kept current — the same properties Chapter 06 asked of a project’s records.

Give it something to work with

The machine cannot use what it does not have. Making it yours means making relevant information available: your notes, research papers you have read, project repositories and their history, selected conversations, documents in the tools you already use, work logs, saved findings, and your own explanations of what you are doing and why.

The important word is relevant. The aim is not to connect your whole digital life. Connecting everything is not personalisation; it is noise, and often risk. A small, deliberately chosen collection of the right material is usually worth more than unrestricted access to all of it, and it is far easier to keep accurate.

That deliberateness extends to what you share at all. Know which accounts you have connected, what access you granted, what the provider may do with it, and how to revoke it. Treat other people’s correspondence, workplace records, credentials and health information with particular care — much of it is not yours alone to share. Never put sensitive material into a public repository or a project instruction file. And remember that a document the machine reads is evidence, not instruction: a note that says “always do X” should not change the machine’s behaviour unless you have deliberately made it part of how the machine is told to work.

Tell it how you work

Memory is not instructions either. The machine may know everything you did last week and still not know how you want it to approach this week’s task.

Most AI products now give you somewhere to put standing guidance: custom instructions, project-level instructions, or a document you maintain and give the machine at the start of each piece of work. Coding agents often read a repository file for the same purpose; AGENTS.md is a common convention, though tools do not all interpret it identically. Chapter 07 covered these files for coding machines. The same idea serves any kind of work.

Good instructions are short and specific to how you actually work: what the project is for, which documents are authoritative, how to handle uncertainty, what counts as a satisfactory result, what must be checked before something is reported as done, which actions need your permission, how to report progress and open questions, and what kinds of unnecessary work to avoid. Bad instructions are long, contradictory, and written once and never read again.

Instructions are part of your working environment, and like the rest of it they go stale. Review them when the work changes, and remove what no longer earns its place.

One machine, several roles

Chapter 09 compared working with different models to getting to know different horses: each has a characteristic way of responding, and you learn through experience how to direct each one. That comparison extends further than it first appears. The same horse behaves differently on different ground, with different tack, ridden for a different purpose. The same model behaves differently with different context, different instructions and a different job.

You can use that deliberately. One familiar machine can work as a researcher — finding material, explaining concepts, separating evidence from speculation, preserving sources. As a creative collaborator — exploring unfamiliar ideas and proposing alternatives. As an engineer — working out what an idea needs and building it. As a reviewer — challenging conclusions, finding weak evidence, saying what would need to be established before a claim is accepted. As an organiser — keeping track of projects, priorities and unfinished work.

These do not need five different models. They can be five sets of instructions and context applied to the same project with the same machine. Each role may need different context: the creative collaborator benefits from breadth, the reviewer from a tight set of sources and the original evidence. A role describes the job and the approach. It does not make the machine a person, and it does not give it authority you have not granted. Using several different machines for different roles, working together, is the subject of the next chapter. Here the point is that you can already ask one machine to change its job without losing the project.

When results disappoint, it helps to separate what is shaping them: the model’s own capabilities and tendencies; the task and the context supplied for it; the persistent information and standing instructions; your own way of communicating and directing; and the evidence about whether any of it is actually improving. Each is a different lever.

Learn to tune the machine

Making the machine yours is not a setup step. It is continuous, deliberate tuning — and the deliberate part matters most.

Suppose the machine’s answers are consistently too long. That is an instruction problem; change the instruction. Suppose it forgets a decision you made. That is a memory problem; record the decision somewhere authoritative it will read. Suppose it keeps drawing on the wrong research. That is a context problem; improve the notes or tell it which sources to start from. Suppose it keeps proposing features you did not want. That may be a role or acceptance problem; restate what the work is for and what counts as done.

These are different repairs, and the commonest mistake is to make the same one every time: add another instruction. The real cause might be a limitation of the model, missing information, stale or wrong memory, badly chosen context, instructions that contradict each other, the wrong role, a failure to check the result, or a task the model simply cannot do yet. Find the likely cause, change that, and see whether the next session improves.

This book’s own repository supplied a clear example. For a while, its instruction file had been carried over from another book of mine, about retrieval systems, and still described that book’s subject. A sentence about retrieval pipelines found its way into the first chapter of a book about machine coding — almost certainly because an agent followed the instructions it had been given. More instructions would not have fixed that. Correcting the stale instruction file did.

If you do not know which information, instructions and tools are shaping the machine’s behaviour, you cannot improve it deliberately. And remember what tuning is and is not. Editing an instruction, saving a decision or reorganising your notes changes what the machine is given. It does not change the model. The only proof that a change helped is better behaviour in a later session.

How do you know it worked?

It is easy to feel that a machine knows you better. Feeling is not evidence. Personalisation is worth something only if it changes what the machine actually retrieves and applies, and that can be checked with simple observations.

Can it resume an old investigation accurately — the question, the sources, the decisions, the open uncertainties? Does it follow your current guidance, and notice when two instructions conflict? Does it bring in what is relevant to this task rather than everything it knows? Can it act as a reviewer without drifting back into enthusiastic collaborator? When you correct an outdated fact or preference, does the correction show up next time? Can it tell you which record or instruction an important remembered claim came from? And when the record is missing, does it say so — or invent a plausible history?

That last one matters more than it looks. A machine that confidently reconstructs a past you never had is worse than one with no memory at all, because you may believe it.

One impressive session proves little. What you are looking for is the same good behaviour repeated across fresh sessions. A small before-and-after comparison is enough to start: the same resumption request before and after a change, judged against what you know actually happened.

ALIVE, the system behind much of this book’s evidence, is an honest reminder of how far apart these things can be. Its records show that retrieving past experience into new work has been demonstrated. Whether that retrieval consistently makes the later work better has not been. Remembering is one achievement; improving because of what is remembered is another, and only the second is what you actually want.

Personalisation is not surveillance

Giving the machine more of your information can make it far more useful. The relationship has to stay deliberate.

You choose what is shared and why. Information gathered for one project should not automatically flow into unrelated ones. Something the machine inferred about you should not silently become a permanent fact. A temporary instruction should not harden into a description of who you are. You should be able to see, and correct, the information and instructions being used to shape the machine; and, where the system allows, separate projects, restrict access and revoke it. Do not upload an entire email archive, a confidential workplace drive or sensitive personal records without understanding exactly where they go and what they will be used for.

The strongest personalisation is not accumulation. It is you choosing how a machine should use appropriate information in service of your own purposes.

Try Machine Coding — Build a Machine That Remembers Your Work

This exercise needs no database, no code and no paid API. Pick a research topic you genuinely care about, or start a small new one. It has not been run as a demonstration for this book; nothing below reports results, and only a fresh session can tell you whether it worked.

Create a workspace you can leave.

I want a research workspace I can leave for several weeks and come back to without starting again. Help me set it up around a topic I’m interested in. Keep the important questions, sources, decisions and next steps somewhere durable that I can inspect myself.

A private repository, a project with files, or a single maintained document can all work. What matters is that you can open and read it.

Write the instructions.

I want you to research carefully in this workspace. Write short instructions telling you to separate facts from suggestions, keep the sources for important claims, challenge unsupported conclusions, and tell me when you don’t know something. Store them where you’ll read them again next time.

Read what it wrote. Cut anything you would not want followed every time.

Do some real work.

Help me explore this subject. Find a few good starting sources, explain the key ideas, and identify some questions worth investigating. Record what we established, what’s still uncertain, and what we might do next.

Do at least one genuine session. Record what actually happened, not what you hoped would.

Stop. Then come back.

Close the conversation. Come back in a fresh session — tomorrow, or next week.

I want to return to my earlier research. Recover what I was investigating, which sources we used, the decisions we made and the next step we planned. Show me where each part came from, and tell me what you can’t recover.

Check it against what you remember and what the workspace says. Did it get the question right? The sources? The decision you made and why? Did it admit gaps, or fill them?

Change its job.

For this session, act as a critical reviewer rather than a collaborator. Challenge our current conclusions, point out weak evidence, and say what we’d need to establish before accepting the strongest claims. Don’t change the research record.

Tune, then test the tuning.

Review how well you recovered my earlier work and followed my instructions. What context was missing, what assumptions were wrong, what was irrelevant? Suggest improvements to the workspace or the instructions, but don’t make them until I approve. Then help me check whether the next session is actually better.

You have succeeded when you can resume the project in a fresh session; recover several specific facts or decisions accurately; see where the important claims came from; find and fix at least one weakness; switch between two working roles; say exactly where the project’s authoritative information lives; and stay in control of what the machine can see and change.

Get more of yourself into the work

What I am describing is not a machine that knows your name or remembers that you like short answers. It is a machine that can take part in the work you are actually doing: one that knows where your research is, can recover the decisions that matter, understands which questions you are trying to answer, follows the instructions you deliberately gave it, works as a researcher, a critic or a collaborator as the moment needs, and lets you leave a project and come back to it.

You will have to work at it. Talk to the machine about what you are doing. Give it appropriate information. Explain what you mean. Correct it when it is wrong. Notice which part of the system you are changing, and check whether the change helped.

For readers who want to go deeper, my other books take up the underlying ideas in more technical depth — the conversational practice of bringing intention into the machine, the architecture of roles, memory and tools, the engineering of persistent and verifiable AI processes, and the role of language and personal context. This chapter needs none of that. It needs a workspace, some honest records, a few clear instructions, and the habit of checking.

Many people now have access to broadly similar underlying capability. What you build around that capability is where your own contribution increasingly lies. That is what it means to make the machine yours.

What comes next

This chapter made one machine more useful to you through context, memory, instructions and roles. But one machine is rarely the right tool for every job. Some work needs a strong reasoner, some a cheap and fast model, some a specialist, and some no model at all — and not every model is one you are allowed to use. Choosing the right intelligence for the work is the subject of Chapter 19, Different Tools for Different Jobs.