How to Use Gemini Gems (and Where They Fall Short)

A Gem is a saved version of Gemini that already knows the job. You write the instructions once, attach the files it should read, give it a name, and from then on you open something that arrives half-briefed instead of blank.

Google launched Gems for paid subscribers in August 2024 and opened them to everyone in the Gemini app the following March. So the feature is free, it is sitting in a menu most people have scrolled past, and it has a hard limit worth knowing before you move your working files into it.

How to use Gemini Gems

A Gem holds two things: written instructions that apply to every chat you have with it, and up to ten knowledge files it can read. You build one from the Gems manager — open Gemini on desktop, go to Explore Gems, choose New Gem — and you can start from one of Google's premade Gems or write your own from scratch. Setup takes about twenty minutes, and the order matters more than the contents.

Write the instructions first, before a single file goes in. Google's own guidance is unusually specific here, and it's good: cover persona, task, context, and format. Who the Gem is. What you want it to do. What it needs to know about your situation. How the answer should be shaped. Files are reference. Instructions are intent, and intent is what changes the output.

Then attach ten files at most, and mean all ten. The cap is ten knowledge files per custom Gem, and it sounds generous right up until you start treating a Gem as a filing cabinet. Four documents that each earn their place beat ten that mostly overlap, because every extra file hands the model one more thing to be confidently vague about.

Name them the way you'd describe them out loud. strategy-doc-FINAL-v3.pdf gives Gemini nothing to grab. Q3 pricing objections from sales calls tells it exactly when to reach for that file and when to leave it alone.

And put in the documents that make it sound like you. Gems get filled with company material almost by reflex, which is a large part of why so much AI output reads like it was written by a committee that has never met you. The files that make writing feel human are the files about the human.

One small thing that trips people up: the preview pane lets you test the Gem as you write it, but previewing doesn't save it. Click save.

The one thing Gems do better than Projects

Here's the part that deserves real credit, because it's genuinely ahead of the competition.

When you attach a knowledge file from Google Drive, the Gem references the live document. Google's own language is that Gems use the most recent version of that file, so it stays up to date. Change the Drive doc, and the Gem's knowledge changes with it. No re-upload, no version drift, no wondering which copy it's reading.

That matters more than it sounds. The quiet failure mode of every AI workspace is that the material inside it ages while you keep trusting it. A Gem built in March answers in September with March's numbers, no hedge, no warning, because it has no way to know. We wrote a whole post about how AI context goes stale, and Drive-linked knowledge is the closest thing any major tool ships to a fix. ChatGPT Projects and Claude Projects both take a frozen copy at upload. Gemini reads the original.

So if you're going to keep something in a Gem, keep the things that move in Drive.

Gems, saved info, and custom instructions are three different things

They get used interchangeably. They behave nothing alike.

	Gemini saved info	A Gem	Portable context anchors
What it holds	Facts about you Gemini keeps or you set	Instructions plus up to ten knowledge files	Documents you wrote and own
Where it applies	Across the Gemini app	Inside that one Gem	Anywhere you paste them
Who decides what's in it	Partly the model	You	You
If you switch tools	Stays behind	Stays behind	Comes with you
When it's wrong	Dig through settings	Rewrite the instruction	Edit the source

Saved info is account-wide and shallow. A Gem is deliberate and walled. Custom instructions sit somewhere between. We put all of them side by side in every way to give AI context, compared, and the honest summary is that each one is good at a different job, and none of them is the durable layer.

Where Gemini Gems fall short

The context stops at the Gem. That's the design, not a defect, and it's why Gems work as well as they do. It also means each Gem starts empty. Build a second one and you're writing your background, your voice, and your standing preferences again. Change your job title and you don't update it once. You update it in every Gem that mentions it, assuming you remember which ones do.

And none of it leaves Google. A Gem's instructions and knowledge are a Google feature. They don't travel to ChatGPT. They don't travel to Claude. They aren't available to anything you build on an API, or to the AI features quietly appearing inside tools you already pay for. Projects have the identical ceiling from the other side, which is the tell. Every vendor builds the same trap, and each one builds it well. The better the workspace, the more expensive it is to leave.

Ten files is a real number. For a single focused Gem it's the right constraint. For anyone trying to give one assistant a full picture of their work, it runs out faster than you'd expect, and the thing that usually gets cut is the personal material, because the company material feels more official.

And the empty instructions box is harder than it looks. "Write instructions" reads like a task. It's really a decision about what actually matters, and it's where most people stall, type two lines about tone, and end up with a Gem that knows their formatting preferences instead of their work. Figuring out what belongs in there is its own skill, context mining, and it's the one part of this no interface can do for you.

What to keep outside the Gem

So the fix isn't to skip Gems. It's to stop treating one as the place your context lives.

Write it down once, as plain markdown you own. Who you are and what you're optimizing for, how you sound, the stories you already tell, what's true this quarter. There are six anchors in all, and together they cover most of it. Keep them somewhere that isn't a product. Then paste them into whatever needs them: this Gem, the next Gem, a Claude project, your ChatGPT custom instructions, the app your team is building on an API.

The Gem becomes a place you deploy context instead of the only place it exists. Nothing about the setup changes. What changes is where the original lives, and whether losing access to one product costs you an afternoon or a year.

That distinction is worth being exact about. A context anchor is a file you own. A Gem is a place you point files at. One survives the tool. The other is the tool.

Build one anyway

Gems are good, and the Drive-linked knowledge is better than good. Write the instructions before you attach anything, cover persona and task and context and format, keep the file list short, put the things that change in Drive, and save it before you close the tab. You'll have an assistant that beats a cold chat window, and you'll have it by lunch.

Just keep the originals somewhere you can reach them. Because there will be a second Gem, and a fifth, and eventually a different tool entirely. On the morning you're staring at another empty instructions box, the difference between twenty minutes and a lost afternoon is whether those files already exist.