Sharing it, and what that costs
An assistant that lives in your account helps one person. The step from personal tool to team tool is where most of the value is, and it is also where the questions get awkward — about who can see what, who pays, and what happens when you leave.
The three sharing modes
Private is the default and is right for anything experimental. Nobody sees it, nothing leaks, and you can be careless in a useful way.
Shared by link or workspace is the mode most team tools should be in. Anyone in your organisation with the link can use it. They see the assistant's responses and the openers; depending on the product they may or may not be able to view your instruction block, and you should assume they can — write it as though it will be read, because sooner or later it will be.
Published or public puts your assistant in a directory anyone can find. There are good reasons to do this and they are almost all marketing reasons. Be aware that a public assistant with attached files is a public assistant with public files.
The permission fact that catches people
Attached knowledge does not inherit the permissions of the folder it came from. A document that was restricted to three people, attached to an assistant shared with forty, is now effectively available to forty. Nobody is warned, because as far as the system is concerned you deliberately attached it.
This is not a hypothetical problem. It is the single most common data incident in no-code AI deployments, it is invisible until someone asks the right question, and it is entirely preventable by asking one before you share: if this assistant simply printed everything in its knowledge base to whoever asked, would that be acceptable? If the answer is no, remove files until it is yes.
What it costs, realistically
The billing models differ, and the differences matter at team scale.
For Custom GPTs, the builder needs a paid plan, and so does each person using it. Usage counts against each user's own limits, so a heavily-used assistant does not generate a bill for you — it consumes your colleagues' caps, which shows up as complaints rather than invoices.
For Claude Projects, the same broad shape: paid plans per person, with team plans that pool administration. Large attached knowledge consumes context on every conversation, which is a real cost at volume even when it is not itemised.
For Gemini Gems, sharing follows Workspace, which is convenient if your organisation is already there and irrelevant if it is not.
The honest planning number for a small team is that a genuinely useful shared assistant costs roughly one paid seat per active user per month, and that this is cheap relative to the time it saves — provided you did lesson 5's arithmetic and know that it saves time at all.
The question nobody asks until it is too late
Who owns this when you leave?
An assistant built in a personal account, with instructions nobody else has read and knowledge files pulled from someone's own drive, disappears when that person does. This happens constantly and is deeply annoying for everyone involved.
Two habits prevent it entirely. Keep the instruction block in a shared document as the master copy, and paste it into the tool — the tool is where it runs, the document is where it lives. And attach knowledge from a shared drive location rather than a personal one, so the source survives independently.
Rohit keeps a folder called Studio Kalpa — assistants. One document per assistant: the instruction block, the list of knowledge files and where they came from, the ten-row test sheet, and the failure log. It takes about five minutes per assistant to maintain and means the studio owns its tools rather than renting them from whoever built them.
Do this today: write your instruction block into a shared document, then share your assistant with exactly one colleague and watch them use it without helping. What they do in the first two minutes is the most useful feedback you will get all month.