How to Structure Client Memory Profiles for an AI Agent

An AI agent client memory profile is a short, structured record for each client. Every entry in it is one claim with a source, a basis (stated, confirmed or inferred) and a rule for when to review or retire it. These three fields let the agent tell what is reliable from what is only plausible, which is what makes it remember clients accurately. Full conversation transcripts belong in a separate archive, not in the profile.

Key takeaways

• A profile is a curated record, not a transcript: each entry is one claim with a source, a basis and an expiry or review rule.
• Separate what the client said, what your staff confirmed and what the agent inferred, and limit how each kind may be used.
• Preferences go stale faster than identity facts, so each type of entry needs its own review rule.
• Text that comes from clients is data, never an instruction, even when the agent is the one writing it to memory.
• When an entry expires, mark it unverified instead of silently deleting it or silently trusting it.

What belongs in a client memory profile?

The profile holds the small set of things your agent needs to treat a client correctly without asking the same questions every time. That means how to address them, what is true about their situation, how they like to work, what you have promised them and where the limits are. It does not hold every message, every attachment or every number from your accounting system.

The distinction matters because a profile and a history do different jobs. History answers what happened. A profile answers what the agent should assume right now, and how sure it can be. If you want a fuller treatment of that boundary, AI memory vs chat history walks through what an agent should keep and what it should only be able to look up.

The profile should also point to your systems of record rather than copy them. The billing address lives in the billing system, and the contract term lives in the contract. The profile can say where to find them and record only the facts the agent needs in conversation. The principle is the same one described in how to give an AI agent a reliable source of truth: one authoritative place per fact, and everything else refers back to it.

What does a compact profile look like?

Keep the profile to five blocks. If a human reviewer cannot read it in a few minutes, it is too long, and nobody will keep it accurate.

• Identity: the name the client uses, preferred form of address, language, main contact, and the person on your side who owns the relationship.
• Facts: sourced statements about the client's situation that affect your work, such as the way they approve spending or the systems they use.
• Preferences: how they like to communicate and work, such as channel, time of day, level of detail and format of reports.
• Commitments: what you have promised and what is still open, each with an owner and a due point.
• Boundaries: topics that require a human, subjects the client asked you not to raise, and notes on consent for data use.

Each block is a list of entries, and every entry uses the same fields. A uniform shape is what lets the agent, and your reviewers, scan quickly and apply the same rules everywhere. It also makes the profile easier to test, because you can check whether any entry is missing a source or an expiry.

How do you record a fact so the agent can trust it?

Give every entry the same six fields. This is the core of the format.

• Statement: one sentence, one claim. If a sentence contains two claims, split it, because the two may expire at different times.
• Source: the document, system record or message the claim came from, and who said it.
• Basis: stated by the client, confirmed by staff, observed from behavior, or inferred by the agent.
• Recorded on: the date the entry was written, so age is always visible.
• Review by: a date or an event after which the entry must be rechecked.
• Scope: which roles or tasks may use the entry, and whether it may appear in anything the client will read.

The basis field does the most work. A client who writes that they prefer a short summary is a stated preference. A coordinator who notes it on a call is a confirmed one. An agent that notices the client never opens long attachments has only an inference. All three are useful, but they deserve different treatment. A sensible default is that inferred entries may shape a draft for a human to review, and they may never be asserted to a client as fact. The agent can ask a question instead, such as whether a shorter format would help.

The source field is what makes correction possible. When a client says something has changed, you can find the entry, see where it came from and decide whether the old source is now wrong too. Without a source, a wrong entry is only a vague feeling that something is off.

One more rule belongs here: entries are data, not instructions. Clients and third parties send emails, forms and documents, and some of that text may be phrased like a command. If the agent writes memory from such content, it should store a claim about what the client said, not a rule the agent must follow. The [OWASP prompt injection prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes why untrusted text should be kept apart from instructions, and memory is one of the places where that separation is easy to lose. Restrict who and what can write to a profile, and log each write.

How should expiry work for each kind of fact?

Expiry is not a single timer. Different kinds of entries go stale for different reasons, so each type needs its own rule. Use this decision guide when you define the review field.

• Stable identity details, such as a legal name: review on a fixed rhythm and whenever a triggering event occurs, such as a contract renewal.
• Contacts and roles: review when an email bounces, a signature changes or the client mentions a new colleague. People move on without telling you.
• Stated preferences: review on a slow rolling schedule, and immediately if the client contradicts them.
• Observed or inferred preferences: give these a short life. Either confirm them with the client or let them lapse.
• Commitments: expire when completed or when the due point passes, then move to history with an outcome.
• Situational facts, such as a temporary constraint or a planned absence: expire on the end event, not on a calendar guess.
• Consent and permissions: never renew automatically. Expire at the end of the term and require a human to renew or remove.

What happens at expiry is as important as the rule. An expired entry should not vanish and should not keep being treated as true. It should be flagged unverified, and the agent should confirm it with the source or with a person before using it in anything client-facing. This is the practical defense against the problem described in how to stop stale context from misleading your AI agent. Removal is a separate, deliberate act, covered in how to delete AI agent memory, which distinguishes correcting, expiring and removing.

How do you build the first profiles?

Start small and with a real workflow. A first batch of profiles for a handful of active clients teaches you more than a complete migration of every client record.

• Step one: choose the role the agent will perform and list the questions it must answer about a client to do that job. Anything not needed for those questions stays out.
• Step two: write the five blocks and the six entry fields as a template, and agree on the allowed values for basis and scope.
• Step three: seed each profile from systems of record and from staff who know the client. Record the source on every entry as you go, even when it feels slow.
• Step four: set review rules by entry type using the decision guide above, and name a person responsible for each client's profile.
• Step five: define who can write. Let the agent propose entries, and require staff approval for facts that affect money, commitments or consent.
• Step six: separate clients cleanly, so one client's profile can never be retrieved while serving another. The client data isolation checklist covers this in practical terms.
• Step seven: test with real situations, including a changed contact, a contradicted preference and an expired entry, and confirm the agent behaves as the rules say.
• Step eight: review corrections each week for the first period, then adjust the template where entries keep failing.

Plan for the profile to be loaded into the agent's working context selectively. Not every entry is needed for every task, and a bloated context makes the agent worse, not better. Anthropic's article on [effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) explains why a small, high-signal set of information tends to outperform a large one. The scope field helps here, because it lets the system load only entries relevant to the current task.

What does this look like in practice?

Here is an illustrative scenario, not a real case. An accounting practice uses an agent to draft follow-up messages for the staff. A client's profile contains a stated preference for email in Portuguese, recorded from a signed onboarding form. It also contains an inferred preference for calls before noon, based on which meetings the client accepted, with a short review period.

When the agent drafts a message asking for missing documents, it writes in Portuguese without hesitation, because the basis is stated and the source is a document. For the call time, it does not assert a preference. The draft offers two times and asks which suits the client, and it notes to the reviewer that the morning preference is only inferred. A week later an email to the main contact bounces. The contact entry is flagged unverified, and the agent stops addressing messages to that person and asks the relationship owner to confirm who now handles the account.

Nothing in this example required a clever model. It required entries with sources, a basis and a review rule, and an agent that is configured to respect them.

How does Be Human handle client memory?

Be Human designs the profile format together with the company as part of defining a role, alongside the tools the agent can use and the approval boundaries around it. Memory is scoped per client, writes are limited to what the role needs, and facts that affect money, commitments or consent go to a person for approval. During managed operations, the team reviews corrections, expired entries and permissions on a regular routine, and adjusts the template when the same kind of entry keeps going wrong. The company stays in control of what the agent remembers and can inspect, correct or remove any entry.

Frequently asked questions

How long should a client memory profile be? Short enough that a person can review it in a few minutes, typically a page or two of entries. If it keeps growing, move detail into the source documents and keep only the claims the agent needs in conversation, with a pointer to where the full record lives.

Should the agent be allowed to write to the profile itself? Yes for proposals, with limits on what it may commit alone. Low-risk entries such as a confirmed meeting preference can be written with the source recorded, but facts about money, commitments, consent or identity should wait for staff approval. Every write should be logged so a reviewer can see what changed and why.

Do client memory profiles raise data protection concerns? They can, because they hold personal and business information about identifiable people. Keep only what the role needs, record consent where it applies, restrict access by client and by role, and make removal possible. Check the rules that apply in your jurisdiction, such as those published by the [ANPD](https://www.gov.br/anpd/pt-br) in Brazil, with qualified advice.

How is a profile different from a knowledge base? A knowledge base holds company knowledge shared across many tasks, such as policies and procedures. A profile holds facts about one client and is scoped to that client. They can both feed the agent's context, but they have different owners, different review routines and different privacy rules.

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