
Claude agent memory that your whole team can use
Claude agent memory keeps one person continuous in Claude. BitsWeave is shared team context so decisions survive Cursor, ChatGPT, or a teammate.
Claude just held the whole call. It remembered the constraint, the option you killed, and the three steps that follow. The next chat in that Project can use the topics Claude saved, without a paste of the whole call. Then you open Cursor on the repo. That agent has the files and none of the call. ChatGPT, opened for the update, asks what you chose. A teammate starts a fresh thread and rebuilds the brief from Slack.
The continuity inside Claude was real. The work still stopped at the host.
People search for Claude agent memory when that stop shows up. Claude already keeps one person current inside Claude. Projects keep the instructions and the files for a body of work. That is a good product. It is also a personal layer inside one host. The organization still needs a home for the decision, the record, and the next step when the work moves to Cursor, to ChatGPT, or to someone else.
BitsWeave is that home. Claude stays the host you decide in. BitsWeave is the shared team context the next host can read.
What people mean by Claude agent memory
Claude agent memory is the phrase people use when they want an agent in Claude to stop starting from zero. The same intent shows up as agent memory, and as a question about handoffs to ChatGPT or Cursor. The words sound like one feature. They cover two jobs Claude already does, and a third job it does not try to own.
Memory keeps facts about you across chats outside a Project. Each Project has its own memory, separate from other Projects and from those chats. Preferences, standing constraints, and details you stated before can return in the next conversation in that same space. The unit is the person using Claude. Success looks like "I did not have to re-explain myself."
Projects keep a body of work together. Custom instructions and the files you add stay with that Project. Later chats in the Project use those instructions and files. They do not receive the earlier chat unless it is in the project knowledge, or Claude saved it as project memory. The unit is the Project, still inside Claude. Success looks like "this thread already has the spec."
Both are continuity. A session that forgets yesterday's constraint is a bad session. Claude built memory and Projects so that does not happen for the person in front of Claude.
The third job is shared team context: the same decision, available to a teammate and to an agent in another product, after this chat closes. What is agentic memory? names that split. One side is private recall. The other side is the organization's work. Claude memory sits on the first side, on purpose.
If the pain is "Claude forgot me," stay with memory and Projects. That is the job they chose.
What that continuity is good at
A fair read starts with what Claude does well. Memory and Projects are not a weak team workspace. They are a strong form of personal continuity.
Memory fits a long relationship between one person and Claude. You correct a preference once. Later chats respect it. You do not open every thread with a biography. The model keeps the lesson.
Projects fit work that should stay in one room. A spec, a style note, and a set of instructions can live with the Project for weeks. Strategy, drafting, and review start from those files. You do not paste the same brief into the prompt every morning.
They also fit a handoff that is still a Claude handoff. A later chat can continue the Project. On a Team or Enterprise plan, a teammate you invite into that Project can continue inside Claude. The host did not change. The material did not have to leave Anthropic's product to be useful. Sharing a Project with the people who work in Claude is a sound way to keep one room current.
That scope is the product. Use it for personal continuity, and for project continuity, inside Claude. The mistake is to treat it as the system of record for a team that also lives in Cursor and ChatGPT.
The owner is a person. The host is Claude.
The limits are the boundary of a host feature. Two of them matter when the work leaves the room.
The owner is the person, or the Claude Project. Memory follows the account that built it. A Project follows the people who can open that Project. The company does not hold those objects as records every tool can cite. Remove someone from Claude and you are managing a Claude membership. You are not pointing at a decision Cursor still has.
The host is Claude. Cursor does not read Claude's memory. ChatGPT does not open a Claude Project. A teammate in a different product does not inherit the chat, the standing facts, or the uploaded brief unless someone copies them.
A shared Project does not erase the host limit. The share is still a Claude object. It does not become the decision on the issue, and it does not become a next step Cursor can cite. People who work in Claude can share the room. A different product cannot read that room.
Owner and host explain a familiar week. The Claude setup can be careful, and the Monday re-brief can still happen. Claude did its job. The job stopped at Claude.
One decision, three hosts
Walk one decision through a normal week. The tools can all be working. The week only requires more than one host.
On Monday you close a scope call in Claude. The Project holds the spec. Memory already knows you want the smaller launch. Claude states the decision: ship the smaller scope, because the date is fixed, and do not reopen the platform rewrite. It names the issue and lists three next steps.
On Tuesday you open Cursor on the same repo. The agent can read the code. It cannot read Monday's Project. You paste the decision, or you do not. A short paste drops the rejection. The agent drafts the rewrite you already killed, because nothing in Cursor says it is dead.
On Wednesday someone opens ChatGPT to write the update. The answer is in Claude. You paste again. That paste is the integration. A shorter paste lets the update reopen a door the team already shut.
On Thursday a teammate who missed the chat asks the same question. Your memory is not theirs. A shared Project still leaves them inside Claude. The Cursor notes never landed there. They rebuild the brief from Slack and miss the rewrite.
Each host answered the person in front of it. The organization had no shared page. Claude agent memory removed the restart inside Claude. It does not remove the restart across Claude, Cursor, and ChatGPT. A teammate is a different owner.
Shared team context is the other layer
Shared team context is the model of the work that stays after the tab closes. The unit is the organization. People and agents read the same objects. A session in Claude can land a decision. A session in Cursor can read it. A teammate can open it without the original transcript.
Agent memory vs shared team context puts host memory, including Claude's, on the personal side. Shared team context sits on the org side. You can run both. Do not ask one of them to do the other's job.
BitsWeave is the org side. It does not replace Claude, and it does not switch Claude's memory off. Keep Projects for files that belong in that room. Put the objects the rest of the org must continue into BitsWeave.
The next host can cite a small set:
- Decisions — what you chose, why, and what you rejected
- Records — the issues, docs, and app objects those decisions rest on
- Next steps — the queue a person or an agent can pick up without a re-brief
Decisions, records, and next steps walks that set. A chat log is evidence. The decision is the choice the org will stand on. The record is the issue. The next step is the open work, attached to both.
Claude can still hold the conversation. The next agent should cite the decision, not a private recall of your preferences.
What stays in Claude on purpose
BitsWeave does not scrape chat memory out of Claude, Cursor, or ChatGPT. Those products stay the hosts. Your Claude memory remains Claude's. Files in a Project stay there until you also record what the org must keep.
That boundary is intentional. How you like a draft to sound does not belong on the company graph. The decision to kill a rewrite does.
The organization keeps what landed through sessions, tools, records, and the connectors you installed. If you never recorded the decision, the graph does not invent it from a transcript BitsWeave cannot see. If the issue tracker did not deliver the issue, the record is not there.
You finish the call in Claude, write the decision, attach the record, and leave the next steps. Cursor reads those objects without your Claude login. ChatGPT can draft the update from the same decision. The teammate can take the next step without a forwarded Project.
If Claude forgets a preference, fix it in Claude. If Cursor reopens a killed option, the decision was never an org object. A longer paste does not change the owner.
How the next host reads the work
Each person adds the BitsWeave MCP server to the host they already use. Claude, Cursor, and ChatGPT attach to the same organization. They do not each get a private copy of the decision or of the team's credentials.
The MCP surface is how an agent reaches the org. A document, a record, and a broker action are addresses on one MCP surface. Credentials stay on the org's broker install. The agent holds a credential for BitsWeave. It does not receive the GitHub token, the mail secret, or the Grafana key. MCP connectors and team context covers that split. The connector belongs to the org, so a second host does not need a second copy of that app credential.
context.graph takes a focal identifier — the decision, the project, or the record — and returns the neighborhood around that seed. The context graph is that walk. A Project can hold a file. The graph is how another host, and another person, start from the same seed.
An agentic workflow plans, calls a tool, checks the result, and writes the next step. The plan only looks finished when its only copy is the Claude window. Shared context lets that workflow resume in Cursor or ChatGPT, on the decision and the queue.
The walk returns what the org recorded. It does not return your Claude memory. A broker does not invent an event the app did not send. If the pull request never arrived, it is not in the neighborhood.
Personal continuity versus the org layer
Use the table as a filter. Both rows are legitimate. They fail when you swap them.
| Claude memory and Projects | Shared team context in BitsWeave | |
|---|---|---|
| Who it serves | One person, or one Claude Project | The organization |
| What it keeps | Preferences, instructions, files | Decisions, records, next steps |
| Who else can read it | The account, or people in that Project | Teammates and connected agents |
| A move to Cursor or ChatGPT | A paste, if someone makes one | The same objects |
| When someone leaves | Their Claude memory stays on that account | The org records stay |
| Where app credentials live | Whatever that host was given | The org's broker install |
Read the first row when the product in front of you is Claude, and the person who must stay continuous is you. Read the second row when the next reader might be a teammate, or an agent in another host. Most teams want both. The miss is to keep only Claude memory and then expect Cursor to know the call.
Questions to ask before you rely on it
Ask these where the decision has to survive. The answers separate Claude agent memory from shared team context.
- Who must still know this after the chat ends? If the answer is you, next time you open Claude, memory and Projects are enough. If the answer is the org, you need a shared object.
- Does the decision survive a move to Cursor? If that agent needs a paste, the decision never left Claude.
- Does it survive a move to ChatGPT? The update should cite the same decision. A second retelling drifts on the option you rejected.
- Can a teammate continue without your transcript? A shared Project helps people in Claude. It does not help an agent in another host.
- Is the rejection an object? "Do not reopen the rewrite" has to be citable. A line in personal memory is easy for every other host to miss.
- Where do the app credentials live? A token per host is a personal connector pile. A broker install on the org is shared, and the credential stays with the organization.
- What is left when someone leaves? Personal memory goes with the account. Org records should remain. A decision that lived only in one Claude login is already gone.
If the answers point to one person inside Claude, keep Claude memory. If they point to the team, on more than one host, keep Claude memory for the person. Do not make it the record of the work.
Keep Claude. Give the work a home.
Use Claude for the call. Use Projects for the files that belong in that room. Use memory so you do not re-introduce yourself every morning. Those tools are the right ones for personal continuity.
When the outcome has to outlive that room, write it where the next host can read it. Decisions, records, and next steps stay on the organization. context.graph is how an agent walks from one of them to the others. Brokers keep app credentials with the org, on one MCP surface. The move from Claude to Cursor to ChatGPT does not mint a new app secret.
The hosts can change. You should not have to be the integration each time they do.
Connect Claude, Cursor, or ChatGPT at bitsweave.com. Claude keeps your continuity. The team keeps the work.