Give the agent memory and context

A model starts every session knowing nothing about your company. Whatever it should know comes from three places: what it reads every time it starts, what it can look up when the task calls for it, and what it learned last time and someone wrote down. When an agent drifts, the cause is usually its memory: the same fact exists in four files with three different values, or a lesson was noted somewhere nobody reads. The fix is an organisation rule: every fact lives in one place, at the lowest level shared by everything that uses it, and everything else points to it.

Sort what the agent needs to know

Take the agent you are building and list what it needs. Then put each item in one of three columns.

Always loaded	Looked up on demand	Never in context
Role, scope, the rules it must never break	Product facts and prices	API keys and passwords
Where each kind of fact lives	The customer list, the CRM	Raw personal data it does not need
The format of its output	Past results, the lessons ledger	Full exports when a digest will do
The checks before anything goes out	Style examples for the current task	Anything “just in case”

The first column has to stay short, because it is paid for in every session and competes for the model’s attention with the task itself. A good test: if a line only matters for one task in ten, it belongs in the second column, behind a pointer such as “before quoting a price, read facts/pricing.md”. How to write that first column is the subject of the chapter on role, rules and examples.

In Claude Code, the always-loaded layer is the CLAUDE.md files: one in your home folder for everything, one per project, one per subfolder if needed, read in that order when a session starts. The memory documentation explains how they combine. Other tools have an equivalent; the principle is the same.

One source of truth per domain

Here is the rule I apply across my own agent setup: a fact lives at the lowest level shared by every agent that uses it, higher levels point to it, and nothing is copied. Product facts used by the SEO agents, the LinkedIn agents and the outbound agents live in one file at the root, because all three use them. The SEO publishing rules live in the SEO folder, because only SEO uses them.

company/
  CLAUDE.md               # who we are, where each domain lives (pointers only)
  facts/
    product.md            # features, prices, banned claims: one owner, dated
    customers-public.md   # what can be said about customers
  seo/
    CLAUDE.md             # SEO rules, points to facts/product.md
    agents/
      head-of-seo.md      # role, rules, lessons that became rules
    ledger.md             # experiments and verdicts, dated
  linkedin/
    CLAUDE.md
    voice.md              # voice calibration, banned phrases

Copies are what kill you. When a price changes and it was written in five places, four agents keep quoting the old one, and they do it with full confidence. With one file and pointers, you change one line and every agent reads the new value the next time it starts.

Each facts file carries a date of last check and an owner. A fact without a date is a fact you cannot tell is stale.

Compute what can be computed

Some facts should not be written down at all. A count of features, of pages, of customers changes, and a number typed into a file is wrong the day after it changes. In my setup, counts are never hard-coded: a script computes them from the source, and a check confirms that a feature exists before any content cites it. Your version can be very small:

# Fails if the article cites a feature that is not in the catalogue
for slug in $(grep -o '/features/[a-z0-9-]*' draft.md | cut -d/ -f3 | sort -u); do
  grep -q "\"$slug\"" data/features.json || echo "Unknown feature: $slug"
done

The instructions then say “to state how many features exist, run the count script” instead of giving a number. The agent does one more tool call and never quotes a stale figure.

Give digests, not raw files

A 40 MB CSV, a month of logs or a full database dump does not belong in the context. The model reads part of it, drowns in the rest and answers with confidence about rows it never saw. My agents read a digest: a short summary produced by a script, with the structure, the counts and the rows that matter, and with secrets and personal data removed before the model sees anything.

Here is the shape of one, with made-up figures:

digest: search_console_export
rows: 18,240 (pages x queries)
total_clicks: 12,906   # check against the interface total before use
columns: page, query, clicks, impressions, position
top_pages_by_clicks: [10 rows]
pages_with_zero_clicks: 312
redacted: none needed (no personal data in this export)

The comment on the third line is there for a reason: on 5 November 2026, the Head of SEO agent in that setup found that one of its own exports counted only about a third of the real clicks (the full story). A digest that prints its total next to a reference total makes that kind of gap visible on the first read.

Make lessons stick

An agent that makes the same mistake twice was told about it in the wrong place. I use two levels. A ledger records each lesson with its date and context: what happened, how it was caught, what changed. When a lesson is durable, it is written straight into the instructions of the expert concerned, as a rule. A reminder is not an action: a note saying “be careful with exports” changes nothing, while a rule in the instructions changes the next run.

Ledger entry	Rule it becomes in the instructions
2026-11-05: export counted only named-query clicks, about a third of the total	Before combining two exports, check their totals match. If they differ, stop and report.
2026-11-05: a routine edited pages that were under test	Before editing a page, read the list of pages under test and skip them.

The second line is real too: declaring pages under test was useless as long as the routine that edited pages did not read the declaration. A rule that nothing reads is the same as no rule.

Keep the memory itself safe

The memory is now an asset, so treat it like one. Until 9 November 2026, my whole agent organisation existed in one copy, on one laptop (the security chapter shows how it is protected now). Do the same before you need it: version the instruction and facts files, keep personal data out of them, and review the diff when an agent edits its own instructions.

Your next step: list every fact your agent relies on, mark where each one is written today, and for each fact that appears in more than one place, keep one copy, date it, and replace the others with a pointer.