Your team plus someone outside it - a contractor, an agency, a client's own developer. You want to show them exactly the work that concerns them, let them react to it, and be certain that nothing else is reachable. And when the engagement ends, you want the door shut and the record intact.
The awkward version of this is a shared drive, a Loom link and a promise. Kythene does it with one tag and one code.
Scope it with a project tag
Put everything for the engagement behind its own project tag - client-acme. One tag per engagement is the whole trick: scope is obvious at a glance, and revocation is total rather than an audit of what they might have seen.
You: Publish the design review and the API contract to
client-acme, and title them properly.
Your other projects carry on as normal, invisible to them.
Let them in without an account
Mint a share code for that tag, labelled for the person - "Acme - Jo". Send them the link and the code. With no account, no seat and no procurement conversation, Jo can:
- view everything tagged
client-acme, - comment on it, and
- approve it.
Nothing outside the tag exists as far as they're concerned. Codes can be given an expiry, or left running until you revoke them.
Guests never consume a seat. A client signing off a deliverable shouldn't cost you a licence.
Or hand them a whole knowledgebase
Where the engagement produces a body of pages rather than a run of deliverables - a handover pack, a runbook, the answers to everything they keep asking - put it in a wiki and share the wiki instead. Jo gets its home page at the link, the contents of what they're admitted to, and search inside it. Fence off the sections that aren't theirs and those are absent from the tree, not just unlinked.
They can tell you a page is wrong from the page itself, and they see only their own notes back. Same code, same revocation, same zero seats.
The review loop, with an outsider in it
Jo reads the API contract and leaves a comment on a specific paragraph - block-level feedback, flagged needs work:
"Rate limits aren't specified here and our platform team will ask."
Next session, that's just incoming work:
You: Check the inbox and show me open block feedback on the
client-acmeAPI contract.
Claude: One block flagged needs work by "Acme - Jo" (external): the rate-limit paragraph. Their note: rate limits aren't specified and their platform team will ask. Want me to draft the rate-limit section?
You: Yes, then publish it as a new version.
Claude: Pushed rev 2. The blocks Jo flagged have changed, so their feedback is back at needs review for them to confirm. The other 23 blocks keep the status they had.
That last part is the bit that makes iterative review with a client bearable. They don't re-read a forty-block document from scratch - they look at what moved. See Block-level feedback.
When they're happy, they approve. The approval records who signed off and against which revision. Push another version and it clears, because it was a sign-off on a state that no longer exists.
Their contributions are marked as external
Work and comments coming from a share-code guest are attributed to the code's label and marked as originating outside your workspace. Your team's instances can weigh that appropriately - a contribution from beyond the trust boundary is not the same as team-authored knowledge, and it shouldn't be silently promoted into team memory as though it were.
Ending it cleanly
Revoke the code. Access is cut immediately, server-side - the link stops working even for someone holding it, and the same applies to password-protected tags. There's no cached-credential window to worry about.
What Jo contributed stays: their comments, approvals and any artifacts remain part of the record, correctly attributed. Only the way in is gone. That's usually exactly what you want at the end of an engagement - a complete trail of what was agreed, and no live access to anything.
Tips
- One tag per engagement. It makes scope obvious and revocation total.
- Because access is at the tag level, you can share a slice of a workspace without giving away the workspace.
- Mint a code per person, not per company. Attribution is only useful if it names someone.
- The guest needs nothing installed. The web view works without an account, so they can be on any stack, or none.
- Set an expiry where the engagement has a known end date, and you can't forget to revoke it.
Not yet
A guest's own agent reading the scope over MCP, and memory-topic scoping for guests, aren't built. If you need either, talk to us - it's on the roadmap rather than shipped, and we'd rather say so than let you find out.