Cursor agent memory for shipping teams

The agent in Cursor just shipped a clean diff. It followed the project rules. It found the right files without a map. It knew you wanted the migration in two steps, because a rule said so. Then the reviewer opens the pull request and asks why the cache layer was left alone. The answer was a call on Monday. It is not in the repo, and it is not in the rule.

The agent did its job. The reason stayed somewhere the reviewer could not read.

People search for Cursor agent memory when that gap shows up. Cursor already gives an agent a lot to stand on. Rules carry standing instructions. The agent searches the codebase. Projects keep shared files across the agents working inside them. That is a good product. It is also a layer built around the code and the people in Cursor. A shipping team still needs a home for the decision, the record, and the next step when the work moves to a reviewer, to Claude, to ChatGPT, or to someone who was not on the call.

BitsWeave is that home. Cursor stays the host you build in. BitsWeave is the shared team context the next host can read.

What Cursor agent memory means today

Cursor agent memory is the phrase people use when they want the agent to stop starting from zero. Under that phrase sit a few separate things Cursor does on purpose.

Rules give the agent persistent instructions. Cursor's docs are plain about why: models do not keep memory between completions, so rules supply reusable context at the start of the model context. Project rules live in .cursor/rules and are version-controlled with the code. User rules are your own preferences across projects. AGENTS.md is a plain markdown alternative, including nested files in subdirectories.

Team rules are the org-shaped piece. On Team and Enterprise plans, admins manage them from the Cursor dashboard. They can be enforced, and they apply to Agent across the team's repositories.

Search is how the agent finds its way around the repo. The agent greps for exact symbols and can hand broad searches to an explore subagent. The codebase is the context. It is always current, because it is the code.

Projects keep longer work together. A Project maintains a set of files that sync across the cloud and local machines its agents use. Agents add research, artifacts, and what they learn about the codebase. The next agent in that Project starts from those files.

All of that is continuity. An agent that forgets your conventions every morning is a bad agent. Cursor built rules, search, and Projects so that does not happen.

The job underneath is different from the one this post is about. What is agentic memory? names the split. One side is how an agent stays useful to the person or project in front of it. The other side is the organization's work: what was decided, on what record, and what happens next.

What Cursor does well

A fair read starts with the strengths. Rules are a sharp tool. A convention written once and checked into git is better than a convention repeated in every prompt. Anyone who clones the repo gets the project rules with the code.

Team rules go further. An admin can say "every migration needs a down step" once, and every agent on the team sees it. That is real org-level guidance. It lives in Cursor, and it is aimed at how code gets written.

Search keeps the agent honest about the code. It does not need a summary of the repo. It reads the repo.

Projects fit work that runs for weeks. A migration with several pull requests can live in one Project. A lesson one agent learns about testing a service can help the next agent. Inside that Project, the brief does not have to be pasted again.

That scope is the product. Use it for how code is written, and for the work inside a Cursor Project. The mistake is to treat it as the system of record for a team that also reviews, decides, and reports outside Cursor.

Where it stops for shipping teams

The limits are not bugs. They are the shape of a coding host. Two of them matter when the work leaves the editor.

Rules describe how. They rarely record why this time. A rule says "use the repository pattern." It is a standing instruction. The decision to leave the cache layer alone for this release is not a standing instruction. It is a one-time choice, with a reason and a rejected option. Writing it as a rule turns a decision into a law nobody remembers passing. Leaving it out means the agent never hears it.

The host is Cursor. Claude does not read your Cursor rules. ChatGPT does not open a Cursor Project. The reviewer reads the pull request, not the files the Project kept for its agents. A product manager writing the release note never opens the editor at all.

There is also a person-vs-org split inside Cursor itself. User rules belong to you. Project rules belong to the repo. Team rules belong to the Cursor team. None of them is the decision on the issue. None of them is the next step a teammate in another tool can pick up.

So the setup can be careful, and the Thursday re-brief can still happen. Cursor did its job. The job stopped at Cursor.

One pull request, a normal Tuesday

Walk one change through a week. Every tool can be working. The week only needs more than one host.

On Monday the team takes a scope call. Ship the smaller fix to the session timeout. Do not touch the cache layer before the release. The date is fixed, and the cache rewrite can wait. Someone writes it in a chat in Claude. The issue gets a one-line comment.

On Tuesday you open Cursor on the repo. The project rules are loaded. The agent finds the session code fast. You tell it the scope, briefly. The short version drops the part about the cache. The agent notices the cache layer is slow, and helpfully fixes that too. The diff is good code. It is also the work the team said no to.

Tuesday afternoon the reviewer opens the pull request. The diff is bigger than the issue. They ask why the cache changed. You explain the call. The reviewer was not on it. Their agent in another host was not on it either.

On Wednesday someone opens ChatGPT to draft the release note. The answer is in Claude, the rules are in Cursor, and the reason is in your head. You paste again. That paste is the integration.

On Thursday a teammate picks up the follow-up. Your Cursor Project is not theirs. The rule does not mention the cache. They rebuild the context from the pull request thread.

Each host answered the person in front of it. The organization had no shared page. Cursor agent memory removed the restart inside Cursor. It does not remove the restart across the reviewer, Claude, ChatGPT, and the next teammate.

The BitsWeave team shape

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 reviewer can open it without the original transcript.

Agent memory vs shared team context puts host memory on the personal side and shared team context on the org side. You can run both. Do not ask one to do the other's job.

BitsWeave is the org side. It does not replace Cursor, and it does not switch rules off. Keep conventions in rules. Keep the repo as the source of truth for code. Put the objects the rest of the team must continue into BitsWeave.

The next host can cite a small set. Decisions, records, and next steps names it:

• Decisions — what you chose, why, and what you rejected
• Records — the issues, pull requests, and app objects those decisions rest on
• Next steps — the queue a person or an agent can pick up without a re-brief

A rule is how the team writes code. A decision is what the team chose this time. The record is the issue. The next step is the open work, attached to both.

Each person adds the BitsWeave MCP server to the host they already use. Cursor, Claude, and ChatGPT attach to the same organization. They do not each get a private copy of the decision, or of the team's credentials. MCP connectors and team context covers that split. Credentials stay on the org's broker install. The agent holds a credential for BitsWeave, not the GitHub token.

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. On Tuesday, the agent in Cursor starts from the issue and finds the decision next to it, rejection included.

Tuesday, again

Run the same week with the decision as an object.

Monday's call ends with a written decision: smaller timeout fix, no cache changes before the release, cache rewrite deferred. It is attached to the issue. The next steps are listed under it.

On Tuesday the agent in Cursor reads the issue through BitsWeave. The rejection is there. It leaves the cache alone. The project rules still shape how it writes the code. The decision shapes what it touches.

The reviewer opens the pull request and the same decision. The diff matches the scope. The question about the cache already has an answer.

On Wednesday ChatGPT drafts the release note from the decision, not from a paste. On Thursday the teammate takes the next step from the queue.

Nothing in that week asked Cursor to be something else. Cursor wrote the code. BitsWeave kept the reason.

Limits worth knowing

BitsWeave does not scrape memory out of Cursor, Claude, or ChatGPT. Those products stay the hosts. Your rules stay in Cursor. Files a Cursor Project keeps stay with that Project.

That boundary is intentional. Your preferred reply style does not belong on the company graph. The decision to defer the cache rewrite does.

The organization keeps what landed through sessions, tools, records, and the connectors you installed. If nobody recorded the decision, the graph does not invent it from a transcript BitsWeave cannot see. If the pull request event never arrived, it is not in the neighborhood.

Shared context also does not fix a bad decision. It makes a decision readable. Someone still has to make it, and someone still has to write it down.

A checklist before you rely on it

Ask these where the decision has to survive.

1. Is this a convention or a choice? Conventions belong in rules. One-time choices with a reason belong in a decision.
2. Does the reviewer need it? If the pull request only makes sense with context from a call, that context has to be readable outside Cursor.
3. Does it survive a move to Claude or ChatGPT? If the next host needs a paste, the decision never left the editor.
4. Is the rejection an object? "Do not touch the cache before the release" has to be citable, or the next agent will helpfully fix it.
5. Can a teammate continue without your Project? Project files help agents in that Project. They do not help a teammate in another tool.
6. Where do app credentials live? A token per host is a personal connector pile. A broker install keeps them with the org.
7. What is left when someone leaves? Your user rules go with you. The team's decisions should not.

If the answers point to the code, keep it in Cursor. If they point to the team, on more than one host, give the work a shared home.

Keep Cursor. Give the work a home.

Use Cursor to build. Use rules so the agent writes code the way your team writes code. Use Projects for long work inside Cursor. Those tools are the right ones for the job they chose.

When the outcome has to outlive the editor, 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 to the others. Brokers keep app credentials with the org, on one MCP surface.

The hosts can change. The reviewer can change. You should not have to be the integration each time.

Connect Cursor, Claude, or ChatGPT at bitsweave.com. Cursor keeps the code moving. The team keeps the reason.