Skip to main content
Once your agent is connected to xysq via MCP, it can work with team vaults as naturally as personal ones. You decide which team to work with — your agent handles the rest.

​
Before you start

You’ll need:
  • xysq connected via MCP (Claude or Cursor)
  • A team created in app.xysq.ai with at least one member
  • Your team ID — find it in the Teams page URL or in Team Settings

​
Telling your agent which team to use

The simplest way is to say it explicitly at the start of a session: 
Work with the xysq team vault for Acme Engineering.

Use my team context for this session — team is Acme Engineering.
Your agent will call memory_list(team_id="<id>") or memory_recall(team_id="<id>") behind the scenes. You can also find your team ID and tell the agent directly: 
My xysq team ID is 46cec015-3b2a-4f9a-8d1c-e2f3a7b90c12. Use this team's vault for our session.
If you’re unsure of your team ID, ask your agent to look it up: 
List my xysq teams.
Your agent will call list_teams() and show you all teams you belong to with their IDs and your role in each.

​
Retaining to a team vault

​
Explicit retain

Retain this to the Acme Engineering team vault: We've decided to use Postgres, not MySQL. Final decision.

Save to team memory: the API rate limit for production is 1000 req/min, agreed with infra on the 14th.

​
During a conversation

Once you’ve told your agent to use a team vault, it retains context there automatically — the same way it would for your personal vault: 
We're going with the monorepo structure. Two packages: api and web. Infra will mirror this.

Got it — retaining that decision to the team vault.

​
Retaining a decision with context

Retain to team: decision — we're deprecating the v1 API by end of Q2. Owner: backend team. Ticket: ENG-441.
Good team memories include who decided, what was decided, and when. Your agent can infer most of this from context if you provide it naturally.

​
Recalling from a team vault

​
At session start

Ask your agent to load team context at the beginning of a session — this is the most efficient pattern: 
Before we start, recall what the team has decided about the payment integration.

Load the Acme Engineering team context so you're up to speed.
Your agent will call memory_reflect("team context and recent decisions", team_id="<id>") and synthesise the relevant facts into a working summary.

​
Targeted recall

What has the team decided about authentication?

What do we know about the deployment process for the web package?

Has anyone captured notes from the Q1 retro?

​
Cross-checking personal and team context

Your agent has access to both vaults simultaneously. You can ask questions that span both: 
What's my personal preference on code reviews, and what has the team agreed on?
xysq routes personal recall to your vault and team recall to the team vault — you get a unified answer.

​
Reflecting on team knowledge

memory_reflect synthesises a grounded answer from stored memories. It works identically for team vaults: 
What should I know about this team's approach to API design before starting this ticket?

Summarise what the team has agreed on so far about the new onboarding flow.

What are the outstanding decisions the team still needs to make on the data model?
Your agent calls reflect behind the scenes and returns a direct answer — no need to browse raw memories yourself.

​
Working with multiple teams

If you belong to more than one team, be explicit about which vault you want: 
List my xysq teams.

Switch to the Platform team vault for this next question.

Retain to the Design Systems team: our token naming convention is documented in Figma, link in the team wiki.
Your agent tracks the active team for the session. Switching is as simple as naming a different team.

​
Deleting a team memory

Members with admin or owner role can delete memories from the team vault: 
Delete the team memory about the v1 API deprecation — that decision was reversed.

Remove the outdated deployment notes from the team vault.

​
MCP tools reference

These are the underlying tools your agent uses when you ask it to work with team vaults. You don’t need to call them directly — your agent handles this — but understanding them helps you write more precise instructions.
ToolWhat it doesMinimum role
list_teams()Lists all teams you belong to with IDs and rolesmember
memory_list(team_id=...)Lists recent memories from the team vaultro
memory_recall(query, team_id=...)Semantic search over team memoriesro
memory_reflect(query, team_id=...)Synthesised answer from team memoriesro
memory_retain(content, team_id=...)Stores a memory in the team vaultrw
memory_delete(memory_id, team_id=...)Deletes a memory from the team vaultadmin

​
Tips for effective team memory

Retain decisions, not discussions. A 30-message thread about auth design is noise. The final decision — what was agreed, who owns it, what it replaces — is signal. Retain the outcome. Include ownership and dates. “We’ll use JWTs” is harder to reason about than “Auth decision (14 April): JWTs with 1-hour expiry. Owner: backend. Replaces the session cookie approach.” Use the team vault for shared facts, personal vault for personal preferences. Your coding style preferences belong in your personal vault. The team’s API versioning policy belongs in the team vault. Recall at session start, not mid-conversation. Loading team context at the start of a session is cheaper and more coherent than piecemeal lookups mid-task. Correct outdated memories. Decisions change. When something is reversed or superseded, delete the old memory and retain the new one. Stale context is worse than no context.