Gems, extensions, and knowing what to reach for

This lesson is about that decision. We will define each tool precisely, show where it actually lives in the product, then walk a single real task through all three so the trade-offs are concrete.

Three tools, three jobs

Think of these as three points on a spectrum from "stateless and instant" to "persistent and connected."

• Plain prompt: a single conversation. No saved configuration, no special powers beyond the model's native abilities (reasoning, native multimodality, long context). Fastest to start, nothing to maintain.
• Gem: a saved, reusable configuration of Gemini. You write persistent instructions once (role, tone, output format, steps to follow) and optionally attach reference files as knowledge. A Gem is *your* custom version of the assistant for a recurring job.
• Extension: a connector that lets Gemini take action in or pull live data from a specific service: Google Workspace (Gmail, Drive, Docs), Maps, YouTube, Flights, and more. Extensions are about *reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète →*, not personality.

A Gem changes *how* Gemini behaves. An extension changes *what it can touch*. They are independent, and you can use both at once.

Where each one lives

Gems and extensions both live in the Gemini app. You create and manage Gems in the Gem manager (the "Explore Gems" / "New Gem" area in the sidebar). Extensions are toggled under Settings → Extensions in the Gemini app, where you connect the Google services and third parties you want Gemini to reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète →.

This lesson is about the consumer-facing Gemini app surface. The APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →-level and Vertex AI equivalents (function calling, grounding, agents) are a separate layer we will name at the end, because the decision logic is the same even when the plumbing differs.

The decision example

Here is one task, run three ways. You are a consultant. Every Monday you write a short status update for three clients, in their preferred tone, summarizing last week's work and flagging risks.

Run 1: plain prompt

If you only ever did this once, you would just paste your notes and ask:

> "Turn these notes into a client status update. Professional but warm tone. Three sections: Done, In Progress, Risks. Keep it under 200 words."

This is correct. For a single task, writing a Gem first would be overhead with no payoff. If you will not repeat the instructions, do not save them.

The plain prompt breaks down the moment you do this weekly across three clients, because you are re-typing the same formatting rules every time and copy-pasting tone preferences you keep forgetting.

Run 2: a gem

Now make it a Gem. You write the instructions *once* and they apply to every conversation you start with that Gem.

A good Gem instruction reads like an onboarding doc for a new assistant. Structure it:

You can also attach knowledge files to a Gem: a doc of each client's tone preferences, your service descriptions, a glossary. Gemini treats these as reference context for every chat with that Gem. That is the difference between a Gem and a clever saved prompt: the Gem carries its own attached knowledge.

Now your Monday workflow is: open the Gem, paste notes, answer "which client," done. The instructions never drift.

Official guidance on building these lives at Google's Gems help page.

Run 3: add an extension

The Gem still has a gap: you are pasting notes manually. Your actual notes live in a Google Doc, and the client emails you reference are in Gmail. This is a *reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète →* problem, so it is an extension problem.

With Google Workspace extensions enabled, you can prompt:

> "@Google Drive find my doc 'Acme weekly notes' and @Gmail pull any emails from Acme this week, then write the status update."

Gemini retrieves the live content and feeds it into the task. Note what changed: the *instructions* still come from the Gem, the *data* now comes through extensions. Personality and reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → are doing separate jobs, exactly as designed.

A few honest limits to keep in mind:

• Extensions act on *your* data with your permissions. They do not magically have access you do not.
• Extension behavior and the exact set of available connectors evolve. Check Settings → Extensions for what is live in your account and region rather than assuming.
• Right now you cannot bundle a specific extension *into* a Gem as a guaranteed dependency the way you attach knowledge files. You enable extensions at the account level and invoke them per prompt. Treat them as a capability you turn on, not a permanent property of one Gem.

When grounding matters

If your task needs *current* facts (today's news, a live statistic, a recent product change), reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → for grounding with Google Search. In the Gemini app this is the built-in ability to consult the web and cite sources; it is distinct from extensions, which reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → into specific named services. Rule of thumb: extension to touch *a system* (your Drive, Maps), grounding to verify *a fact* against the live web.

A decision checklist

Run any task through these questions in order:

1. Will I repeat these instructions? No → plain prompt. Stop here.

2. Does it need persistent rules, tone, or attached reference knowledge? Yes → make a Gem.

3. Does it need live data or actions in a real service (my email, files, Maps)? Yes → enable the relevant extension.

4. Does it need current facts from the open web? Yes → use grounding with Search.

These are additive, not exclusive. The Monday task ended up using a Gem *and* extensions. That is normal. The mistake is jumping to step 2 or 3 for a job that step 1 already solved.

The overcomplication trap

The most common error among capable people is building a Gem for something they will do twice. A Gem has a maintenance cost: when your client's tone preference changes, you must remember to update the Gem and its knowledge files. For genuinely recurring, high-value work that cost pays off fast. For a one-off, it is pure friction. Match the tool to the *frequency and stakes*, not to how impressive it feels.

Model tier is a separate axis

One more thing the three tools do *not* decide: which model runs them. Gems and extensions work across the Pro and Flash tiers. Pick Flash for fast, high-volume, straightforward generation; pick Pro when the task needs deeper reasoning or handling of large, complex context. The status-update Gem runs fine on Flash. A Gem that analyzes a 90-page contract against a risk rubric wants Pro. Tool choice and model choice are independent decisions, so make both deliberately.

Where this goes when you outgrow the app

The Gemini app is the right surface for personal and team workflows. When a workflow needs to run *without you in the chair*, or needs to ship inside software, the same three concepts reappear under different names. Knowing the mapping saves you from relearning the decision.

• Reusable instructions (the Gem idea) become a system instruction plus reference content in the Gemini API, prototyped in Google AI Studio. Same job, now version-controlled in code.
• Reach (the extension idea) becomes function calling: you describe tools to the model, and it decides when to call them and with what arguments. Grounding with Google Search is also available as an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète → feature for live facts.
• Multi-step, autonomous behavior is where you graduate to the [Agent Development Kit (ADK)](https://google.github.io/adk-docs/) for building agents, and Vertex AI on Google Cloud when you need enterprise deployment, governance, and scale.

For developer-side automation specifically, Gemini CLI brings the model to your terminal and Gemini Code Assist brings it into your IDE. And inside Workspace, Apps Script lets you script Gemini-powered automation across Docs, Sheets, and Gmail without leaving Google's environment.

Here is the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →-level version of our Monday Gem, so the mapping is concrete. The system instruction *is* the Gem's instruction block:

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-2.5-flash",
    config=types.GenerateContentConfig(
        system_instruction=(
            "You are a client status-update writer. Convert raw notes into "
            "three sections (Done, In Progress, Risks), under 200 words, "
            "in a professional but warm tone. If no risks are given, write "
            "'No risks flagged this week.'"
        )
    ),
    contents="Notes: shipped onboarding flow, started billing migration, "
             "vendor API was flaky Thursday.",
)

print(response.text)

Same instructions you wrote into the Gem, now reusable in code, testable, and embeddable in a product. The decision logic from the checklist did not change; only the surface did.

Key Takeaways

• Start with the cheapest tool that works. A plain prompt is correct for anything you will not repeat. Do not build a Gem for a one-off.
• Use a Gem when instructions, tone, or reference knowledge recur. Write the Gem like an onboarding doc and attach knowledge files so it carries its own context.
• Reach for an extension when you need live data or actions in a real service, and grounding with Search when you need current facts from the open web. ReachReachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → and facts are different needs.
• Tool choice and model tier are separate decisions. Pick Flash for speed and volume, Pro for deep reasoning, independently of whether you are using a Gem or an extension.
• The same three ideas scale up to system instructions, function calling, and agents in the Gemini APIAPI, AI Studio, ADK, and Vertex AI. Learn the decision once; apply it at every level.