If your company runs on Google Workspace, Gemini is already sitting inside Gmail, Docs and Drive, and you have probably used it the way most people do, which is by opening it, explaining the situation, and asking for something. Gems are the feature that lets you stop explaining the situation every time you open the tab.
Table of Contents
A Gem is a saved version of Gemini configured for one job, and the useful ones are narrower than most people expect when they first build one. I want to work through the whole thing here: what a Gem actually holds, how to tell which of your tasks deserve one, how to write instructions that change the output instead of merely describing what you want, what happens the moment you share one, and the point at which you should be reaching for NotebookLM instead.
What a Gem is
A Gem is a saved configuration of Gemini made up of a name, a set of instructions, and optional knowledge files. Google’s own overview describes Gems as a way to build custom experts from Gemini, personalized to any topic, which undersells how specific the genuinely useful ones are.
Open a Gem and it already holds the instructions you wrote and the files you attached, so the conversation starts with your terminology, your format and your constraints in place rather than needing to be told again. There is no practical limit on how many you build, and the sections below argue for several narrow ones over a single Gem attempting to cover everything you do.
Which tasks deserve a Gem
The test is repetition against a stable standard, so a task you do most weeks measured against a format or rule set that does not change much is a Gem, while everything else is better handled in a normal chat where you can see exactly what you are feeding it.
| Task | Gem? | Why |
|---|---|---|
| Reviewing submittals against a spec | Yes | Repeats constantly, and the standard is a document that barely changes |
| Drafting the weekly look-ahead | Yes | Same format every week, and the structure is the whole value |
| Writing RFIs | Yes | Recurring, and consistency of tone and structure matters to how they land |
| Building project org charts for a bid | Maybe | Repeats, but the inputs change enough that a chat may serve you better |
| Answering a one-off question about a contract clause | No | Not recurring, and NotebookLM is the better tool anyway |
| Anything where you need to see exactly what went in | No | A Gem hides its knowledge files behind the conversation, which is the wrong trade when the input is the thing in question |
The instinct most people bring is to build one assistant that knows about the company. That assistant then has to be told every single time which of the many things it knows is relevant right now, which puts you back to explaining context to something you configured specifically so you would not have to.
Narrow works better because instructions serving one task can be specific in ways general instructions cannot. A Gem that only reviews submittals can be told to always cite the spec section, since every question it will ever get is a submittal question, whereas a Gem that also drafts client emails and summarizes meetings cannot be told that without the instruction being wrong two-thirds of the time.
Building your first three Gems
1. The submittal reviewer
Give it the governing spec sections and a review checklist, then constrain what it is allowed to conclude. The constraint is the important part, because an assistant left to itself will produce a verdict, and a verdict is exactly what a coordinator is not authorized to give.
Example instructions: “You review mechanical submittals against the project specification for a specialty contractor. Always cite the spec section you are relying on, quoting the relevant line. List what the submittal covers completely and what it leaves unanswered, in that order. Never approve or reject a submittal and never say whether it will be accepted, because that is the design team’s call. If the spec is ambiguous on a point, say that it is ambiguous rather than choosing the likelier reading.”
2. The look-ahead drafter
Attach a look-ahead you have already sent, because demonstrating the format works better than describing it, and tell the Gem to match it exactly. What belongs in a look-ahead is a solved question at most companies, so the Gem’s job is to follow your answer rather than invent its own.
Example instructions: “You draft our weekly look-ahead from crew assignments and schedule changes. Match the structure of the attached example exactly, including section order and how hours are grouped. Flag any crew assigned to overlapping jobs before anything else in the output. Never invent an hours figure. If a date is missing, list it as outstanding rather than estimating it.”
3. The RFI writer
Attach two or three RFIs you consider well written, because examples carry more than description here: tone is most of what makes an RFI land well, and tone is close to impossible to specify in the abstract. If the people writing them are unclear on the difference between RFIs and submittals, the Gem will inherit that confusion.
Example instructions: “You draft RFIs in our company format, following the attached examples for structure and tone. State the question plainly in the first line. Reference the drawing number and spec section the question arises from. Keep the tone neutral and factual, with no argument about responsibility or cost. If the question could be read two ways, split it into two RFIs.”
4. Write instructions with all four parts
Across all three, the instructions that work contain the same four elements, and the fourth is the one people leave out.
Start with the role, stated narrowly enough to exclude work you do not want it doing. Add the standard it works against, which in construction means naming a specific document rather than appealing to a general principle. Specify the output shape, because “summarize this” and “list what is complete and what is missing, in that order” produce very different things. Finish with the refusals, the two or three moves it must never make, which is the part that gets skipped and the part that matters most on a jobsite. An assistant with no stated refusals will fill gaps confidently, since filling gaps is what it was built to do. Telling it never to estimate an hours figure it was not given, never to approve or reject, and never to resolve a spec ambiguity by picking the likelier reading is what turns a tool producing plausible answers into one producing checkable ones.
Sharing, and the fact that a Gem is a Drive object
When you share a Gem it goes into Google Drive, and Google’s announcement of Gem sharing is explicit that it runs on the same technology powering Drive, that the experience matches sharing a Doc, and that shared Gems are stored in Drive. Recipients can then edit it, use it as it stands, or take a copy of their own to modify.
For a contractor already standardized on Workspace this is genuinely convenient, since there is no new permissions model to learn and a Gem obeys the file-sharing posture the company already set. It cuts the other way too, and the same announcement says so: if your organization permits sharing documents outside the company, Gems can travel outside the company in exactly the same way. Administrators who want to bound that can control it centrally in the admin console, under Generative AI, then Gemini app, then Gems.
Attaching knowledge from Drive rather than uploading a file has an advantage worth the extra click, since a Drive file the Gem points at is the file your team already maintains, so updating the source updates what the Gem works from while an uploaded copy stays frozen at the moment you attached it.
Two practical notes are worth having before you share anything with colleagues. A Gem is only shareable when its custom knowledge came from a device upload or from Drive, so attaching anything else greys out the share button with no explanation on screen, which is worth knowing before you spend an afternoon wondering what you did wrong. You should also decide deliberately whether your team edits one shared Gem or takes copies, because a single shared Gem stays consistent and accumulates everyone’s improvements, whereas copies drift into four versions that started identical and now behave differently in ways nobody has written down.
When to use NotebookLM instead
Gems draw on Gemini’s full capability plus whatever you attached, which is what makes them good at producing work and wrong for questions you need to defend. For those, Google’s other tool is the right one: NotebookLM answers only from documents you give it and shows the passage each answer came from. Bridgit’s guide on answers grounded in your own documents covers how that works and where it still needs checking.
The split is simple enough to hold in your head: reach for a Gem when you are producing something and already know what good looks like, and reach for NotebookLM when you are asking what a document actually says and the answer has to be traceable back to the page.
Where this falls short
Five Gems is five things to maintain, five instruction sets somebody may have edited, and five sets of knowledge drifting from their sources at their own pace. Whoever builds them should own them, since a shared Gem with no owner becomes something several people have quietly modified in different directions.
A knowledge file inside a Gem is also a copy taken on the day you attached it, so the crew list you upload on Monday is wrong by Thursday if somebody moved, and nothing in the Gem will tell you that. That is the line between a setup that drafts your paperwork well and a system holding the actual state of your workforce, which is what purpose-built AI workforce planning is for. The sensible division is to use Gems for the writing that surrounds crew work while keeping the roster itself somewhere that stays current on its own.
Opinion: build one, not five
The temptation once this clicks is to spend an afternoon building all three at once, and the teams I would bet against are the ones that do exactly that. Five Gems built in a single sitting are five untested instruction sets, none tuned by real use, all producing output that is almost right in ways you have not yet learned to spot.
Build the one covering whatever took most of your time last month, use it for a fortnight, rewrite the instructions once you have seen where the output still needs your hand, and only then start on the next. The first Gem teaches you how specific your instructions have to be for your own work, and that lesson transfers to everything after it.
