Team Workflows

Individual memory is useful. Team memory is transformative. When your whole team captures work into a shared workspace, every member's AI assistant walks into each session knowing what everyone on the team has been doing — not just what you yourself remember.

This guide covers the workflows that make the most difference when multiple people are working from the same memory store.

How team memory works

Everyone on the team uses the same API key (or keys scoped to the same workspace). When you save a memory, it's visible to everyone. When a teammate searches memories before starting work on a component you built, they find your notes, your decisions, your gotchas.

The memory store becomes a shared second brain.

Standups

The most immediate use case: standups that take less time and communicate more.

Individual prep (30 seconds)

Before your standup, run:

mx memories recap --recent 24h

That's it. You get everything you and your teammates worked on in the last day, grouped by conversation. No more "wait, what did I do yesterday?"

Team-wide status digest

For a synthesized view of what the whole team is working on:

mx memories digest --query "sprint work" --recent 7d --digest-format status-report

This produces a status-report format specifically designed for standups: what's done, what's in progress, blockers. You can ask your AI to read it and give you the three-sentence summary.

Automated standup notes

Some teams use Claude Code with a CLAUDE.md rule to generate standup notes automatically at the end of each session:

## Session end

Before closing, run `mx memories digest --query "today's work" --recent 8h --digest-format status-report`
and share the output as a standup note.

Handoffs

When someone hands off work to someone else, memory makes that handoff complete. The person picking up the work can load the full context of what was done, why, and what's next — without a 45-minute call.

Giving a handoff

At the end of your work on something, save a handoff memory:

mx memories create \
  --conversation-id "conv_your_id" \
  --content "Handing off rate limiting work to @Jamie.
  Current state: middleware is implemented and passing unit tests (PR #234, merged).
  Next task: integration tests against staging Redis instance.
  Known issue: the connection pool is set to 20 but may need tuning — under synthetic load we saw latency above 40 connections. I'd test with 30 first.
  Gotcha: the Redis client's reconnect behavior needs the keepAlive option set; see commit e4a1c02 for why.
  Open question: whether to enforce limits at the gateway level as well — haven't decided." \
  --topics "handoff,rate-limiting,in-progress"

Receiving a handoff

When picking up someone else's work:

# Synthesized overview of the feature area
mx memories digest --query "rate limiting" --digest-format structured

# Find any notes tagged for handoff
mx memories search --query "rate limiting handoff" --brief

# See the timeline of decisions
mx memories search --query "rate limiting" --timeline

This gives you the full picture: what was built, why decisions were made the way they were, and where things stand.

Onboarding

New team members face a steep curve: understanding why things are built the way they are, what's been tried and failed, where the sharp edges are. Most of that knowledge lives in people's heads and gets lost over time.

With memory, it's searchable.

What to search when joining a team

# Architectural decisions for a service
mx memories digest --query "auth service architecture decisions" --digest-format structured

# Hard-won lessons
mx memories search --query "auth service" --topics "gotcha" --brief

# Recent history
mx memories recap --recent 30d --query "auth service"

What teams should save for onboarding benefit

The most valuable memories for onboarding are:

• Why was this approach chosen? — not just what was built
• What was tried and abandoned? — save dead ends explicitly so they don't get re-explored
• Non-obvious setup steps — things that aren't in the README because everyone on the team already knows them
• Known rough spots — components that are fragile, places where the abstraction leaks, things that "just work but we don't know why"

Cross-team knowledge transfer

When someone leaves a team or moves to a different project, their knowledge doesn't leave with them if it's in the memory store. The patterns they discovered, the debugging sessions that found root causes, the architectural reasoning — it stays.

Before rotating off a project

Save a "leaving notes" memory:

mx memories create \
  --conversation-id "NEW" \
  --content "Leaving notes for whoever works on the payments service next.
  Three things that aren't obvious from the code:
  1. The idempotency key pattern — we had a duplicate charge incident in Feb 2025 (issue #341). All Stripe calls now require idempotency keys. Don't remove this.
  2. The webhook signature verification uses the CLI-forwarded signature in test mode, not the test mode webhook secret. This is Stripe's behavior and the docs are confusing about it.
  3. The refund flow goes through a separate queue (not the main event queue) because refunds have a different SLA and we didn't want them backed up behind high-volume events. This is in the ADR from March 2025." \
  --topics "payments,handoff,gotcha"

Shared debugging

When debugging a hard problem, team members can pool knowledge in real time.

One person is investigating a production issue. Another is checking a related system. Instead of syncing verbally, both save as they learn:

# Person A
mx memories create \
  --conversation-id "conv_incident_123" \
  --content "Checked the auth service logs. Token validation latency spiked at 14:32 UTC. No errors — just slow. Redis shows normal load. Not a Redis issue." \
  --topics "incident-123,in-progress"

# Person B (same conversation ID)
mx memories create \
  --conversation-id "conv_incident_123" \
  --content "Found it. The JWT signing key was rotated at 14:30. Old tokens are being verified against the new key, hitting a fallback path that's O(n) instead of O(1). All tokens issued before 14:30 are slow to verify." \
  --topics "incident-123,in-progress"

Both people's findings are in the same conversation. When the incident is over, mx conversations summary conv_incident_123 gives you a complete account that's ready to become a postmortem.

Postmortems

After an incident, the investigation notes are already in memory. The postmortem writes itself.

# Get the full picture of the incident
mx conversations summary conv_incident_123

# Timeline of what happened
mx conversations timeline conv_incident_123

# Check for similar past incidents
mx memories search --query "auth latency JWT token" --timeline

The last command surfaces whether this has happened before — and if it has, whether the previous fix matches the current one.

Making team memory work

A few practices that make the difference between a memory store that stays useful and one that fills up with noise:

Save with enough detail that a stranger can understand it. Write as if you're leaving notes for someone who wasn't there. "Fixed the thing" is useless. "Fixed race condition in token refresh: two concurrent requests could both see an expired token and both try to refresh, causing duplicate refresh calls. Fixed with a Redis lock with 5-second TTL." is useful.

Use --topics "gotcha" for hard-won lessons. When something took real effort to figure out, tag it. Your teammates can then search --topics "gotcha" to find a curated list of things worth knowing before they step on the same rake.

Name incident conversations consistently. Use a pattern like incident-<date> or incident-<id>. Then when you want to look back at past incidents, mx memories search --query "incident" --timeline gives you a chronological picture.

Capture dead ends. "We tried X and it didn't work because Y" is as valuable as "we did Z and it worked." It prevents your teammates from re-exploring the same paths.

Next steps

• Capturing memories that actually help — What to save and how to write it
• Session start ritual — How to warm up at the start of each session
• recap vs digest vs search — Choosing the right retrieval method