How to Seed an AI Agent's Memory With Company History

To give an AI agent company history, do not upload everything you have. Convert the past decisions, client context and lessons the role actually needs into short entries, each with a date, a source and a named owner, and load only the ones a person has confirmed. That keeps the starter memory small, checkable and easy to correct.

Key takeaways

• Seed memory from the questions the agent's role must answer, not from the size of your archive.
• Every entry needs a date, a source, a scope and an owner who can confirm it. Without those, nobody can review it.
• Write decisions with their reasons and their conditions, because the reason is what lets the agent apply them to a new case.
• Keep unconfirmed material in a staging area, separate from the memory the agent acts on.
• Test the seeded memory against past cases where you already know the right answer, then schedule reviews.

Why is starter memory not a document dump?

The instinct is to hand the agent every folder, every old thread and every slide deck, and let it sort things out. This fails in predictable ways. Old plans sit next to current ones with no signal about which is true. A casual remark in a chat becomes indistinguishable from a signed decision. A client's preference from an earlier relationship contact gets applied to a different contact.

An agent does not have a sense of institutional history the way a long-serving employee does. It has whatever you put in front of it, and it treats that material with roughly equal confidence unless the structure says otherwise. Anthropic's guidance on [context engineering for agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) makes a related point: the goal is the smallest set of high-signal information that lets the agent do the work, not the largest pile.

So the task is editorial. You are deciding which parts of the company's past deserve to become memory, writing them in a form that can be checked, and leaving the rest in the archive where people can still find it. If you are unsure how this differs from raw conversation logs, AI memory vs chat history covers the distinction.

What company history is actually worth seeding?

Start from the role, not the archive. Write down the ten or so questions the agent will face in its first weeks, then ask what history a careful new colleague would need to answer them well. Four kinds of material usually earn a place.

• Decisions: what was chosen, what was rejected, why, and under which conditions the decision should be revisited. Examples: a rule to quote only after a scoping call, or a choice to stop supporting a legacy workflow.
• Client and account context: stable facts about how a client works, who approves what, what they dislike, and what was promised. These belong in structured profiles. See how to structure client memory profiles for the shape.
• Lessons: what went wrong or right, written as a short cause and a change in practice, not as a story about blame.
• Procedures and exceptions: how the company handles recurring cases, including the exceptions that only live in people's heads.

What usually does not belong: raw meeting transcripts, long negotiation threads, personal opinions about individuals, drafts that never became decisions, and anything covered by your rules on sensitive data in agent memory. Those can stay as sources the entries point to, without being memory themselves.

One more filter helps. Ask whether the fact is still true, and whether the agent would act differently if it knew it. If the answer to either question is no, leave it out.

What does a good memory entry look like?

A good entry is a short, self-contained claim with enough metadata that a reviewer can judge it in under a minute. Free-form paragraphs copied from old documents fail this test, because the claim is buried and the date and author are lost.

Use the same fields for every entry:

• Statement: one or two sentences in plain language, written as a claim the agent can use.
• Type: decision, client context, lesson or procedure.
• Date: when the decision was made or the fact was last confirmed. Not the date you wrote the entry.
• Source: the document, thread or meeting note it came from, with a pointer someone can open.
• Scope: which client, team, product or role this applies to, and where it must not apply.
• Owner: the person who can confirm, correct or retire it.
• Status: confirmed, inferred or needs verification.
• Review by: when a person should look at it again, or the event that should trigger a review.

For decisions, add two more lines: the reason, and the condition that would reopen the question. A decision stored without its reason turns into a rule the agent follows past the point where it makes sense. A decision stored with its reason lets the agent notice when a new case falls outside it, and ask.

The date field deserves special care. History is full of facts that were true at one point. Recording when each was true is what lets you later resolve disagreements and expire what has gone stale, which is the core of stopping stale context from misleading an agent.

A step-by-step plan for seeding the memory

This plan suits a single role with a clear job. Resist the urge to seed for the whole company at once.

• Step one, define the role and its questions. Write what the agent is responsible for and the questions it must answer. This is your relevance filter for everything that follows.
• Step two, inventory candidate sources. List where relevant history lives: decision logs, project retrospectives, client notes, shared drives, ticket histories, the heads of two or three long-serving people. Mark which are authoritative and which are informal.
• Step three, set exclusions before you read anything. Agree what must never be stored, such as credentials, health details, private personnel matters and anything a client asked you to keep out. Do this first so exclusions are not decided case by case under pressure.
• Step four, interview the people who hold unwritten history. Ask for the decisions that surprised them, the client quirks that cost time, and the exceptions that are never documented. Capture these as draft entries with the person named as source.
• Step five, draft entries in the standard format. Extract claims, attach dates and sources, and assign an owner. Where the date or source cannot be found, mark the status as needs verification rather than guessing.
• Step six, have owners confirm or reject. Each owner sees only their entries and answers three things: still true, true but narrower or different, or retire. Rejections are useful output, not failures.
• Step seven, load in tiers. Confirmed entries go into the memory the agent acts on. Inferred or unverified entries go to a staging area the agent can be told about but not rely on, or are held back entirely.
• Step eight, test against known cases. Pick past situations where the right answer is known and see whether the agent retrieves the right entries and reaches the right conclusion. Testing retrieval quality describes how to do this without guesswork.
• Step nine, set the review routine. Name who reviews what, how often, and what events (a client change, a policy change, a departure) trigger an early check.

Two details save time. First, keep a short log of what you excluded and why, so the next person does not rediscover the same documents and reopen the question. Second, store the source pointer even when you rewrite the claim, so a reviewer can always get back to the original wording.

How do you handle conflicts, sensitive details and gaps?

Seeding history surfaces disagreements, and that is a benefit if you handle them on purpose. Two old documents will say different things about the same client or process. Do not let the agent discover this at runtime.

Resolve conflicts during seeding with a simple order of precedence that you write down. A common one: a signed or formally approved record outranks a dated decision note, which outranks an email, which outranks someone's recollection. When two sources of the same rank disagree, the more recent usually wins, unless the older one has a stated reason that still holds. If neither rule settles it, the owner decides and the entry records that they did. The fuller rules are in when AI agent memories conflict.

Sensitive details need a stricter stance. History is where people paste things that should not persist: personal circumstances, payment details, candid comments about colleagues. When in doubt, store the conclusion without the detail. For example, record that a client requires written approval before any change, not the story of the dispute that led to it.

Gaps are normal. If nobody can say why a decision was made, store it with the reason marked as unknown, and flag it for the owner. An honest gap is better than a plausible reason that someone invented to fill the space.

Finally, treat memory as content that could be wrong or hostile. Old documents can contain instructions written for another purpose, and any stored text can influence behavior. The OWASP list of [risks for LLM applications](https://genai.owasp.org/llm-top-10/) is a useful checklist for why seeded content should come from trusted sources and be reviewed before use.

An illustrative scenario

This is an illustrative scenario, not a real client. A small design studio wants an agent to help its account managers prepare for client calls. The role's questions include: what did we agree last time, what does this client dislike, and what is our rule on revisions?

The studio's operations lead builds starter memory in a week of part-time work. She pulls from the project retrospectives, the account notes and a conversation with the longest-serving account manager. A few of the resulting entries:

• Statement: Client A approves all creative changes through one named director, not through the day-to-day contact. Type: client context. Source: kickoff notes and a later email thread. Owner: the account manager. Status: confirmed. Review by: next contract renewal.
• Statement: Revision rounds are capped in the scoping document, and extra rounds are quoted separately. Type: decision. Reason: unlimited rounds had stretched earlier projects. Reopen if: the studio changes its engagement model. Owner: studio founder. Status: confirmed.
• Statement: Client B prefers short written summaries over calls. Type: client context. Source: the account manager's recollection only. Status: needs verification, held in staging.

During the interview, the account manager recalls an old rule about weekend delivery that contradicts a newer process note. The operations lead does not pick one. She asks the founder, who confirms the newer note and retires the older rule with a recorded date. When she tests the agent on three past calls, it retrieves the director rule correctly but misses the revision cap, because the entry was phrased in internal jargon. She rewrites it in the words clients actually use, and the retrieval improves.

The lesson of the scenario is the workflow, not the details: owners confirm, conflicts get resolved by a person, uncertain items wait, and testing finds wording problems before clients do.

How does Be Human handle starter memory?

Be Human treats seeding as part of the first engagement for an agent's role. We help define which history the role needs, draft entries in a dated and sourced format, route them to your named owners for confirmation, and load only confirmed material into the agent's memory. Exclusion rules, approval boundaries and the review routine are agreed up front. As part of managed operations, we can run recurring memory reviews, test retrieval against known cases, and make controlled corrections as your company changes. You keep the decisions about what the agent may remember. For a deeper look at the review step, see how to audit what an agent remembers.

Frequently asked questions

Should I fine-tune a model on our history instead of seeding memory? Usually not for facts that change or need correcting. Retrieved memory can be dated, sourced, edited and removed, while knowledge baked into model weights is hard to inspect or retract. AWS gives a useful comparison of [retrieval and fine-tuning](https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/rag-vs-fine-tuning.html) if you want the technical trade-offs.

How much history should the first version contain? As little as lets the role do its first tasks well. A small set of confirmed entries beats a large unreviewed one, because every entry is something a person must be able to stand behind. You can add more once the review routine is working.

What if the person who knows the history has left? Record what remains from documents, mark the status as needs verification, and ask the nearest colleague to confirm or reject it. If nobody can, keep the item out of active memory. An unconfirmed claim from a missing source is a risk, not an asset.

How often should seeded memory be reviewed? Set the cadence by how fast the facts change. Client preferences and process rules usually need a regular check, and any policy change, client change or staff change should trigger an early review of the affected entries. Assign each entry an owner so review does not depend on one person remembering to do it.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.