You know that moment when you've built something genuinely useful with AI, and then someone on your team asks: "Can I use that too?"
That's where I found myself last week. I'd built 9 specialized AI employees: Claude Code projects set up to handle specific marketing tasks like battlecards, email sequences, and visual asset creation. They worked beautifully. For me. On my machine. With my folder structure.
When my colleague needed access, I realized I had a context architecture problem, not a file sharing problem.
The Context Gap
Here's what I discovered: my AI employees weren't just files. They were a web of interconnected context. Each project referenced shared identity files (our ICP, personas, brand voice) through symlinks. Move the files without preserving those connections, and the AI loses its foundation.
The surface-level task was "share files via Google Drive." The actual challenge was: how do you share a context layer that depends on relative references, without duplicating the source of truth?
The insight: Sharing AI context isn't about copying files. It's about preserving the architecture that makes those files meaningful.
What I Built
I needed a system where both team members could:
- Access the same AI employees
- Edit them collaboratively
- Maintain a single source of truth for our company context
The solution was a layered symlink architecture. Here's the approach:
Phase 1: Move projects to shared Google Drive, accepting that the internal symlinks would break temporarily.
Phase 2: Audit every broken reference: 35 symlinks across 5 projects, pointing to identity files, sibling projects, and research documents scattered across Drive.
Phase 3: Recreate each symlink with the correct relative path in the new structure. Test each one immediately.
Phase 4: Replace my local folders with symlinks to Drive. My paths still work; the files live in shared storage.
What's in my context layer now:
- 9 AI employee projects in shared Google Drive
- Single source of truth for identity files (ICP, personas, positioning)
- Symlink architecture that resolves transparently for both users
- Setup instructions so Theresa can create her own local symlinks
The result: both of us can open the same AI employee, give it the same commands, and get consistent results. It's all drawing from the same context layer.
How It Actually Works
When Theresa opens the Sales Enablement Machine and runs /battlecard [competitor], the AI reads from our shared positioning file, our shared competitor intelligence, our shared voice of customer research. She gets the same foundation I do.
When either of us improves a context file (adds a new customer quote, updates a pain point), the change propagates instantly. We're both working with the same source of truth.
The unexpected benefit: this forced us to clean up. Some of those original symlinks? They were broken from the start, pointing to files that didn't exist. The migration surfaced technical debt we'd been ignoring.
The Context Layer Lesson
What this teaches about building AI context:
Architecture over files. I didn't share "files" with Theresa. I shared an architecture: a structure of references that gives AI the context it needs. Copy the files without the architecture and you get a hollow shell.
Single source of truth scales. Having one identity folder that both AI employees and both team members reference means updates happen once. No more "which version has the latest personas?" confusion.
Symlinks are transparent. Here's what surprised me: the AI instruction files (CLAUDE.md) don't need to know about any of this. They reference context/positioning.md and it works, whether that's a local file or a symlink to Drive. The infrastructure is invisible to the AI.
Try This Yourself
If you've built AI context that works for you but hasn't been shared with your team, here's how to start thinking about it:
First, map your dependencies. What files does your AI reference? Where do those references point? You might be surprised how interconnected your setup has become.
Second, identify your source of truth. Which files should be canonical? If two people edited different copies, which one wins?
Third, design for transparency. Your AI instructions shouldn't care where files physically live. Use relative paths and let the filesystem handle the rest.
Start here: Run a simple audit. In your AI project folder, look for any references to files outside that folder. List them. That's your dependency map, and the first step toward shareable context architecture.
Questions You Might Have
This sounds like a lot of work. Is it worth it for a two-person team?
It took about 90 minutes, and most of that was fixing 35 symlinks. For ongoing collaboration? Absolutely worth it. Every future AI employee we build will work for both of us from day one.
What if we both edit the same file at the same time?
Google Drive handles this reasonably well. You'll get a conflict copy if you're editing simultaneously. We've agreed to communicate when making big changes. For small edits, Drive's sync is fast enough that conflicts are rare.
Can't you just use Google Drive directly without the symlinks?
You can. The symlinks give you a cleaner local path (~/AI-Brain/01_Projects/... instead of a long CloudStorage path) and let you keep your local folder structure intact. If you don't care about local paths, skip the symlinks.
Does this work with other cloud storage (Dropbox, OneDrive)?
Same principle applies. The symlink targets would be different paths, but the architecture is the same: shared storage as source of truth, local symlinks for convenience.
How does this relate to the Context Layer methodology?
This is the architecture layer in action. The Context Layer isn't just about what context you give AI. It's about how you structure that context so it persists, scales, and compounds. A team sharing one context layer will build something more powerful than two people maintaining separate ones.
Building context that compounds.
