Draft: Agent Memory — How Agents Carry Knowledge Across Conversations - #355
Draft: Agent Memory — How Agents Carry Knowledge Across Conversations#355adilei wants to merge 1 commit into
Conversation
Draft blog post on agent memory in Copilot Studio, adapted from
Kaashyap Murali's source article. Converts the source's custom SVG
diagrams to Mermaid + Markdown tables and adds an on-brand header image.
- New post: _posts/2026-08-01-agent-memory.md (agent_edition: github-copilot)
- New author: kaashyapmurali in _data/authors.yml
- Header image: assets/posts/agent-memory/header.png
- Fix: wrap the sandbox Mermaid diagram in {% raw %} so Liquid does not
strip the {{ }} hexagon-node braces (was rendering a syntax error)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: ab7da142-a130-4777-862c-5452da21f3bf
There was a problem hiding this comment.
Kaashyap Murali (@kaashyapmurali) — first editorial pass on the draft. The mechanical conversion (SVG→Mermaid, cards→tables, header image) is done and the site builds clean. Inline notes are on specific lines; here's the one big-picture piece of feedback.
Distill the purpose and voice, and let that drive the structure.
Right now it's not clear who's speaking or to whom, and the post interleaves two different threads: (1) the techniques Copilot Studio uses to manage memory, and (2) the governance/safety/controls around it.
My suggestion: pick the lane. If this is data science / engineering telling the story of how memory is built under the hood — genuinely cool, and a strong angle — then commit to that voice, keep the post focused on the techniques, and be explicit that governance and other pieces are coming in follow-up posts. In that framing, avoid over-elaborating on governance and on how users access their memories. If we do keep governance in, we have to be much more specific about both the architecture and the actual user experience (concretely: how do I revise or delete the memories stored about me?). Half-answering governance is worse than clearly deferring it.
Structurally, that means separating the two threads into distinct parts. The one section that's genuinely both is "Scoped, separated, and sandboxed" — it's simultaneously the mechanism (distinct scopes → separate stores → mounted per-turn into a sandbox with access modes) and the governance guarantee ("privacy by construction," least privilege). If you keep both threads, split it: mechanism + diagram stay in the techniques half, and the "privacy/compliance become properties of the architecture" framing opens the governance half. Two overlaps to state once: Reflection's "gated, staged rollout" tail vs. the Guardrails "Staged rollout" row, and the Guardrails "Isolation by construction" row restates the sandbox section.
(Housekeeping: the source article was bylined Kaashyap Murali and Michal Sroka — let me know if you want a co-author credit line, since Michal isn't in _data/authors.yml.)
|
|
||
| ## How Copilot Studio approaches memory | ||
|
|
||
| Agent memory in Copilot Studio is built on a deliberately simple idea: **memory is content the agent can read and write**, in plain, human-readable form, rather than an opaque embedding blob nobody can inspect. If a person can open the agent's memory and understand what it believes and why, then makers can audit it, reviewers can reason about it, and the agent itself can revise it in place when something changes. |
There was a problem hiding this comment.
Kaashyap Murali (@kaashyapmurali) This alludes to how memory is accessible in Copilot Studio but is vague on how to actually do it. Two concrete details to add: (1) memory is stored on blob storage, and (2) you can inspect it by conversing with the agent. Let's add both and link to the relevant product docs.
|
|
||
| ### Scoped, separated, and sandboxed | ||
|
|
||
| Not all memory belongs to the same person. What one user told an agent about their own preferences is very different from a pattern the agent learned about how a business process works, which is different again from knowledge owned by the whole organization. Copilot Studio keeps these in **distinct scopes**, and those scopes are **separate stores, not labels on a shared one**. |
There was a problem hiding this comment.
Kaashyap Murali (@kaashyapmurali) Needs more detail on what "separate stores" actually means (physically/architecturally). Governance is going to be a major concern for organizations, so this section should be concrete about how scopes are separated rather than just asserting it.
| | Consent and control | Whether an agent uses memory, and at which scopes, is an explicit decision rather than an implicit behavior, with controls for the maker who builds the agent and for the people who talk to it. | | ||
| | Isolation by construction | Scopes are separate stores, addressed per tenant, environment, agent, and user, and surfaced to a session only when it is entitled to them. | | ||
| | Least privilege on write | Live turns cannot rewrite broader-scope memory. Anything that would widen a memory's audience is treated as a promotion that has to be earned, not a side effect. | | ||
| | Inspectable and reversible | Memory is human-readable and versioned, so it can be reviewed, corrected, or deleted, including deletion initiated by the person it describes. | |
There was a problem hiding this comment.
Kaashyap Murali (@kaashyapmurali) This guarantee is important but hard to operationalize as written. What are we actually suggesting — that an end user logs into each agent individually and asks it about its memories? If there's no first-class experience for a consumer to see and manage the memories stored about them across all agents, we should call that out honestly as a current gap rather than imply a clean self-service capability exists. Either point to the real surface, or name the gap.
|
|
||
| ## Trusted, but also verified | ||
|
|
||
| Adding memory to an agent is a change you have to prove, because the failure modes are quiet. |
There was a problem hiding this comment.
Kaashyap Murali (@kaashyapmurali) Who has to prove it? As written it's ambiguous — is this Microsoft engineering/data science validating the platform capability, or the maker validating their own agent? This ties to a broader issue across the post: we keep jumping between personas (platform builder vs. maker vs. end-user/consumer). Let's pin down whose responsibility each claim is, and be consistent about which persona the post is speaking to.
|
Blog preview check passed for The Jekyll site compiled successfully and generated previews for the newly added post.
Preview artifacts:
|
1 participant
Draft for review by Kaashyap Murali (@kaashyapmurali)
This is a draft of the Agent Memory post, adapted from your source article into the blog's Jekyll/Chirpy format. I've done the mechanical conversion and a first editorial pass; the substantive calls below are yours.
What I did
_posts/2026-08-01-agent-memory.md(author:kaashyapmurali,agent_edition: github-copilot)assets/posts/agent-memory/header.png)_data/authors.yml{% raw %}— Liquid was stripping the{{ }}hexagon-node braces, which rendered a "Syntax error, mermaid version 11.4.0" graphic on the live page. All three diagrams now render clean.Review notes
I've left inline + general comments on the specific spots. The headline feedback (see the general comments): we should distill the post's purpose and voice — commit to the "how it's built under the hood" story and either defer governance/UX to a follow-up, or go deep on it with real architecture + user-experience specifics. Right now those two threads are intertwined, and the governance/consumer-access parts raise questions we don't fully answer.
You now have push access to the repo, so feel free to push directly to this branch or resolve/answer the comment threads inline. Happy to pair on any of it.