How to create a Gemini Gem: build your own AI assistant

Short answer

To create a Gem in Gemini, you start a new Gem in the Gemini app, give it a clear role, step-by-step instructions and reliable reference material, test it with real questions, then share it with your team. No coding is required, but a useful Gem depends on well-written instructions.

A Gem does not retrain the model or learn your company knowledge on its own; it works only with the context you supply. Quality depends on precise instructions and current sources more than on the model name.

What a Gem is and what it is not

A Gem is a saved configuration inside Gemini for one job: a role, rules of behaviour, an output format and optional reference material. Once it exists, you no longer retype the same long prompt in every conversation.

It is not a new model or a fine-tuned version of one, and it teaches the model no permanent knowledge: when a file goes out of date, the Gem keeps answering from the old version with confidence. Nor is it a knowledge base or an audit trail; access control and approval flows need a written process and a named owner behind them.

Google’s official Gems help page lists the current steps and options.

Who should use a Gem

Gems pay off for defined, repetitive work:

• Small business owners: first-reply drafts, proposal summaries, service descriptions.
• Marketing and content teams: briefs, headline variations, social posts, pre-publication checklists.
• Sales teams: first-contact messages, objection responses, meeting-note summaries.
• Support teams: brand-tone answers to frequent questions, request classification, templates.
• Agencies and consultants: one Gem per client, so voices stay separate.

For one-off tasks, building a Gem wastes time. For legal advice, financial decisions, contract clauses or a firm price, a Gem only drafts; a person decides.

Creating a Gem step by step

1. Define the job and the user

Write a one-sentence definition: “This Gem prepares a first-reply draft for the sales team when a demo request arrives.” It should show who uses the output and where the work ends. Several jobs in one Gem lower quality.

2. Start a new Gem

Open the create-a-Gem flow from the Gem list and name it something recognisable, such as “Sales First Reply — EN”.

3. Fill in the instructions field

The instructions field is the brain of the Gem. Write the role, task, rules, output format and limits there, like a short but complete brief for a new colleague.

4. Add knowledge sources

Add only current and publishable files. Upload is optional: start without files and add sources as gaps appear in the output.

5. Test with real questions

Take five to ten questions that genuinely arrived recently and write the expected answers. Identify whether the instructions or the source caused each wrong answer, fix it and test again.

6. Publish and share

When the quality is right, save the Gem and share it. Which question was hard, which answer needed correcting? Those notes feed the next version.

How to write good instructions

Good instructions have seven parts: role, goal, context, steps, output format, limits and an example:

You are a B2B content editor at Argo Ajans. Turn the raw meeting notes I give you into a publishable blog draft.

Use only my notes and never invent missing details; say “this is not in the notes”. Flag every figure, date, price and regulatory statement, and keep the introduction to three sentences.

Output format: H2 headings, two to three paragraphs per section, a four-item checklist at the end. Ask me about anything missing before you answer.

The strength of that prompt is that it says what not to do. Ask yourself: who consumes the output, when should the Gem stop and ask me, and how long should the answer be? If those answers are missing, behaviour changes every time.

Knowledge sources and file uploads

The second factor is your source material: a good source is current, approved and has exactly one authoritative version. If two price lists for the same product are uploaded, the Gem will mix them.

• Suitable to upload: published product and service information, brand and tone guidance, public FAQs, approved process notes, good and bad output examples.
• Do not upload: customer records with personal data, contracts, private pricing, employee information, unpublished financial data.

Every source needs an owner and a review date; a quarterly review removes most stale-information errors. For source governance at scale, align ownership and access levels with our work on enterprise AI.

Sharing and publishing with your team

What makes a Gem valuable is not one person using it quickly, but the whole team hitting the same standard: clear naming, a single owner and a short usage note.

Sharing options depend on your account type and organisation settings; some accounts allow link sharing, others follow administrator policy. Trial the Gem with a small group first.

Users then ask: when should I not use this Gem? Put that in the usage note too: “Do not send this Gem’s output to a customer unchanged; the responsible person approves it first.”

Limits and risks: privacy, hallucination, currency

The biggest risk is not the tool but over-trusting it:

• Data privacy. Every uploaded file falls under your organisation’s data policy. For personal data, contracts and confidential material the default answer is no, written down as a rule.
• Hallucination. A Gem can state a wrong answer confidently, especially on figures, dates, prices and regulatory statements. Add a rule such as “if it is not in the source, do not invent it — flag the uncertainty”, and route those outputs through human review; we cover oversight in our guide to AI in digital marketing.
• Currency. A Gem never questions what you gave it: when a product changes and you do not replace the source, the old version still looks correct.
• Accountability. A Gem is not an accountable decision maker; responsibility for customer-facing text stays with a person. Transparency and oversight build trust and the quality signals you want.

Gem, custom GPT and Claude Projects compared

All three give a model a persistent role, instructions and reference material; differences appear in three areas:

• Ecosystem. A Gem works alongside the Gemini app and Google services. The custom GPT approach offers a broad plug-in environment on OpenAI’s side; Claude Projects emphasises long documents in a project context.
• Source handling. All three accept files, but supported types, size limits and retention behaviour differ and change over time. Verify them before you commit.
• Team adoption. Turning a Gem into a team standard is a process task: ownership, version tracking, training and feedback. Without those four, usage stays a personal experiment.

When choosing, ask which tool your team already uses and where your data lives. A simple Gem in a familiar ecosystem beats an advanced configuration nobody opens.

Business scenarios

• B2B content team. A Gem turns meeting notes into a blog draft; the editor verifies claims, figures and client examples.
• E-commerce product descriptions. A Gem turns attributes into category-appropriate descriptions that do not repeat each other; product data comes from one approved table and the copy is reviewed before publication.
• Sales first reply. A Gem drafts the first reply to a demo request in your company tone; price and timeline commitments are flagged for approval.
• Agency work across clients. One Gem per client: one carries voice and terminology, another banned phrases, so everyone produces to the same standard.
• Human resources. A Gem drafts job adverts and candidate emails; candidate assessment stays out of scope.

Common mistakes

• Defining the job too broadly. A Gem that produces “any marketing content” does nothing well.
• Omitting the output format. Without length, structure and tone, every answer arrives in a different shape.
• Skipping the limits. Rules such as “do not invent when unsure” and “never commit to a price” belong in the instructions.
• Working from stale sources. A file nobody updates quietly turns the Gem into a machine for wrong answers.
• Sharing before testing. A Gem untried on real questions loses the team’s trust on day one.
• Loading everything into one Gem. Separate sales, support and content work; each has its own language.
• Leaving it unowned. A Gem with no owner is forgotten, and customer-facing text must pass human approval.

Checklist

• The job is defined in one sentence and narrowed.
• The intended user and output format are written down.
• The instructions cover role, rules, format and limits.
• A “flag uncertainty, do not invent” rule is included.
• Only approved, current sources are uploaded.
• Every source has an owner and a review date.
• No personal data or confidential files are uploaded.
• At least five real questions were tested.
• One person is named to update the Gem.
• The team was told when not to use the Gem.
• Outputs needing human approval are stated.

Next step

A Gem is a low-cost experiment whose effect can be measured quickly. Pick one repetitive job, write the instructions and test it on real work for two weeks; then check whether the team saved time and quality stayed consistent. Writing those instructions is most of the work, and our prompt engineering guide covers that craft; if you would rather buy a managed assistant than build one, start with AI chatbot cost for small businesses.

To connect AI usage to a wider roadmap, see our enterprise AI service and get in touch to plan a first pilot. You can also explore the product we build for multi-channel customer communication at YanıtLabs.