Question
Working solo with an AI-driven IDE is straightforward: my assistant remembers project context through a memory-banking routine I keep to on my own. Scaling that to a team of UX designers, each running their own AI tools asynchronously, is a different problem. I saw the fragmentation risk clearly: duplicated design and research work, divergent terminology and patterns, hard onboarding for new teammates, and no clear line between personal scratch notes and shared team knowledge. Could a team share one reliable memory across multiple people and multiple AI agents, without losing the clarity a single person gets working alone?
Experiment
I designed a Git-backed memory bank, adapted from the Cline memory-banking protocol I already use solo, structured around two tiers:
Shared documentation, version-controlled and reviewed like code:
projectbrief.md: core project scope and objectivesproductContext.md: user goals, challenges, and UX strategysystemPatterns.md: architectural decisions and design patternstechContext.md: technology stack and technical guidelinesprogress.md: chronological project status and key decisions
Personal documentation, kept separate from the shared tier:
activeContext.md: real-time scratch notes, meeting summaries, competitive analysis, exploratory ideas
In practice, a designer syncs their local environment with the latest shared context, then asks their IDE's AI assistant to validate a new interaction idea against it, something like "compare this approach with our team memory, are there blindspots?" The assistant reads systemPatterns.md and productContext.md and can surface something like a teammate's accessibility update from the day before, which the designer then folds into their own decision. 1Decision 01Designers needed a shared source of truth without losing space for personal, half-formed notes. Chose: I split the memory bank into shared files that document team-level decisions and a personal activeContext.md per designer for scratch work, with a review workflow (proposed, accepted, deprecated) governing what moves from personal to shared. Traded: The extra tier and review step add process overhead compared to one shared folder, but without the split, personal drafts and team-approved decisions would blur together.
Learning
This is currently prototyped and in team-wide rollout rather than a finished system. The structure reduces the context-fragmentation problems I set out to solve: less duplicated work, clearer onboarding for new teammates through structured history, and a real boundary between personal exploration and collective knowledge instead of everything living in one undifferentiated folder.
Open questions I'm still working through: tooling to keep the personal-versus-shared boundary enforced rather than just documented, automation for tasks like tagging sentiment or summarizing long-form notes, and a way to actually measure whether onboarding time or duplicated work drops once a team adopts this.