Copilot Agent Memory: What Persists and Where It Lives

Copilot agent memory is saved information an agent can use in a later interaction, but its scope depends on the specific Copilot product. Instructions, the current conversation, and a persistent memory store do different jobs; seeing an agent use one does not prove it has the others.

For reviewed project context, fenbs keeps decisions and progress outside a single agent. It connects to supported assistants including GitHub Copilot, but it does not connect to Microsoft 365 Copilot or Copilot Studio agents. Start by naming the agent you use, then ask where each important fact should live.

Which Copilot agent are you asking about?

GitHub Copilot and agents built in Microsoft Copilot Studio have different memory designs. GitHub describes repository facts and personal coding preferences in its Copilot Memory documentation↗ (opens in a new tab). These are scoped records used by supported GitHub Copilot features, rather than a universal memory shared by every product bearing the Copilot name.

Microsoft separately documents a Copilot Studio memory preview↗ (opens in a new tab) for the agent experience covered by that page. Its stores are separate for each user and agent. Check that your agent uses that experience before expecting the feature. A guide about another Copilot surface cannot establish what yours retains.

The broader Microsoft Copilot agents guide explains agent choices; the dedicated GitHub Copilot memory guide covers the coding product in more detail. Here, the useful question is which layer holds the context your next agent session needs.

How are instructions different from remembering?

Instructions describe how an agent should behave. A memory describes information retained from an interaction or discovered while working. A task update describes what changed today. Putting all three into an undifferentiated paragraph makes it harder to tell a lasting requirement from an observation that may already be obsolete.

Microsoft’s agent instructions documentation↗ (opens in a new tab) says instructions direct which configured resources an agent uses and how it responds. Instructions cannot give an agent a tool or knowledge source that has not been configured. Writing “remember every approved request” is therefore not evidence that a durable, reviewable record exists.

Keep approved requirements in a place people can inspect. In fenbs, Decisions and rules preserve the choice and its owner; the work context workflow puts rules first when a connected assistant reads the project.

Does conversation state survive the next session?

Do not infer persistence from a fluent follow-up. An agent can answer “use the same format” because that format appeared moments earlier. To test continuity, finish one interaction and start another with a harmless fact whose source you can identify. Ask for the source as well as the answer.

For agents using the standard Copilot Studio experience, Microsoft’s variables overview↗ (opens in a new tab) distinguishes topic variables from global variables that are usable across topics. “Global” describes scope inside that design; it should not be read as a promise of permanent storage across unrelated conversations.

A practical check is to record the account, agent, starting prompt, and result. Repeat with a new conversation, then with a second authorized teammate. Different answers reveal a boundary worth understanding. They do not automatically mean the product is broken or that adding a longer prompt will fix the underlying scope.

Whose information does persistent memory contain?

Ask whether the saved information belongs to one person, one agent, one repository, or a shared project. These boundaries matter when someone leaves the team or another assistant takes over. A useful personal preference can still be the wrong place for a team’s accepted delivery requirements.

In the documented Studio preview, individual memories are private to the user, and turning memory off does not delete the stored information. That makes the feature different from a shared approval log. For GitHub’s repository memories, access and validation follow the repository-specific model described in its documentation.

Before relying on a memory, ask who can review it and what happens when it becomes wrong. For sensitive work, also check your organization’s rules before copying anything into a different service. The agent memory security guide covers those review questions without assuming all memory stores share the same controls.

What belongs in a shared project record?

Save what changes the next action: the goal, current tasks, accepted constraints, open questions, and the next check. Keep the source or reasoning close enough that another person can verify a statement. Leave unrelated preferences and complete conversation transcripts out of that short starting record.

Say a small agency uses an agent to draft a client proposal. “Use concise paragraphs” is a style preference. “The client approved the accessibility review” is a project decision. “The estimate still needs approval” is current work state. The next assistant needs these distinctions even if it writes in a different style.

In fenbs, keep that decision with the project and leave the estimate as waiting on a person. People decide; assistants record what people chose. The wider AI memory library explains other ways context can persist when this project record is only one part of your setup.

How to keep agent context with fenbs

1. Create a free account, free for one person with no credit card, and add the project you are already working on.
2. Add the current tasks, a concise project description, and the approved choices in Decisions and rules. Name unanswered questions as open.
3. Connect a supported assistant using Integrations. MCP, a standard way for an AI app to use an outside tool, provides the connection through a browser sign-in.
4. Ask that assistant to read project context before work and save task progress plus Where we left off before stopping. Check its handoff against the actual result.

fenbs is not the right fit if you only need private personalization inside a Copilot Studio agent. It does not import an agent’s memories automatically. Use it when people and supported assistants need a deliberately maintained work record they can return to together.

How can you tell the setup is useful?

Run one ordinary handoff. Ask a fresh assistant to identify the active requirement, the last checked result, and the next unfinished action. Compare its answer with the actual project before letting it continue. Correct the source record if the answer exposes ambiguity.

Repeat after a person changes a decision. The assistant should distinguish the replaced choice from the current one and avoid presenting an untested step as complete. Reliable continuity means the right work reaches the next session with its status intact, rather than merely producing a familiar-sounding answer.