Gemini workflow placement

Gemini · Where each workflow layer lives

Use this page to decide where a reusable AI workflow belongs inside Gemini. Start with the surface you are actually using: Gemini app chat, a reusable Gem, account-level personalization, Google AI Studio, Gemini API, or Vertex AI. Then place each part of the workflow in the correct layer: instructions, reference material, current prompt, tools, retrieval, verification, or production infrastructure.

Start here: which Gemini surface do you need?

Use Gemini app chat: Choose this for a one-off task. Put the current question, current text, current code, or current document in the chat prompt. Do not use a normal chat as the only place for stable workflow rules that you expect to reuse later.
Create a Gem: Choose this when the workflow should be reused. In the Gemini web app, go to Explore Gems → New Gem. Add the stable workflow behavior in the Gem instructions. Add reusable source material in the Knowledge section.
Use Instructions for Gemini: Choose this only for broad account-level preferences that should apply across Gemini chats. In the Gemini web app, use Settings & help → Personal Intelligence → Instructions for Gemini. Do not put workflow-specific rules here if they belong only to one procedure or one Gem.
Use Gemini Memory: Choose this only as personalization from past chats. Treat Memory as personalization, not as a deterministic workflow-control layer and not as a project-scoped source of truth.
Use Connected Apps: Choose this when Gemini should personalize answers using eligible connected Google app context. Treat Connected Apps as personalization/context access, not as the canonical place for workflow rules.
Use Google AI Studio: Choose this for prototyping prompts, model settings, structured output, tool use, code execution, grounding, and Gemini API behavior before moving the workflow into code.
Use Gemini API or Vertex AI: Choose this for product, backend, automation, agent, RAG, document-processing, or production workflows. Put stable behavior in system instructions. Put current user input in the runtime request. Put files or retrieval material in Files API, File Search, URL Context, Google Search grounding, or application-owned retrieval.
Use Gemini in Chrome Skills: Treat Gemini in Chrome Skills as a separate product surface. Use it only when the workflow is intended for Gemini in Chrome. Do not describe it as equivalent to ChatGPT Skills or Claude Skills unless the exact capability and packaging model are verified for that surface.
Use Gems from Google Labs / AI mini-apps: Treat this as a separate experimental or product-surface-dependent workflow option. Do not merge it conceptually with classic Gems unless the current Google UI and documentation support the use case.

1) Gemini app and Gem setup

Use this section when the user works in the Gemini app rather than an API. The goal is to separate reusable rules, reusable reference material, and the current task.

Where to create a Gem: In the Gemini web app, open Explore Gems, then choose New Gem. Give the Gem a name, add instructions, optionally add Knowledge files, preview the behavior, and save the Gem before relying on it.
Gem instructions: Put stable workflow rules here. Use this for role, task boundaries, required process, output format, evidence rules, verification steps, and what the Gem should not do. This is the correct place for reusable behavior that should apply every time the Gem runs.
Use Gemini to rewrite instructions: Use this as a drafting helper only. It can help expand rough instructions, but the final instructions still need manual review for scope, accuracy, and workflow boundaries.
Gem Knowledge files: Put reusable reference material here. Use this for policies, procedures, examples, checklists, source documents, standards, reference packs, or other files the Gem should use repeatedly. Knowledge files are reference material. They are not the same as instructions.
Knowledge file sources: Gemini can add Knowledge files from device upload, Google Drive, and NotebookLM notebooks where available. Use uploaded files for static reference material. Use Drive files when the Gem should use the most recent version of a Google Drive file. Use NotebookLM notebooks only when that is the appropriate source surface.
Disable knowledge citations: Use this only when citations to Knowledge files are not wanted. Do not disable Knowledge citations for evidence-sensitive workflows, policy review, fact checking, research review, audit workflows, or any workflow where users need to see which source supported the answer.
Gem preview: Use preview to test the Gem before relying on it. Preview is for checking whether the Gem instructions produce the intended behavior. If the preview reveals incorrect behavior, edit the instructions before saving or updating the Gem.
Use a Gem in a chat: After the Gem is created, select it from Explore Gems and enter the current task in the chat prompt. The runtime chat prompt should contain the current task, current document, current code, or current question. It should not be the only place where stable workflow rules live.
Edit, update, delete, pin, and share a Gem: Treat these as management actions. They help maintain or distribute a reusable workflow, but they do not replace the instruction layer or reference layer.

2) Account-level personalization surfaces

Use this section only for broad Gemini personalization. These surfaces are not a substitute for workflow-specific Gem instructions or API system instructions.

Instructions for Gemini: Use this for broad preferences that should apply across Gemini chats, such as response style, language preference, formatting preference, or stable personal preferences. Do not put a specific code-review workflow, fact-checking workflow, or document-extraction workflow here unless you truly want it to affect every Gemini chat.
Gemini Memory / past-chat personalization: Use this only as personalization based on past chats where available and enabled. Do not treat Memory as a deterministic project memory, source repository, or workflow state store.
Connected Apps personalization: Use Connected Apps when Gemini should personalize responses using eligible Google app context. Do not treat connected app data as verified source material unless the workflow explicitly retrieves, checks, and cites the relevant source.
Temporary Chat: Use temporary chat when the interaction should not be used as ordinary saved chat context. Do not use temporary chat as a reusable workflow surface.
Recent chats: Use recent chats for conversation continuity and navigation. Do not rely on recent chats as a controlled reference layer for repeatable workflows.

3) Google AI Studio, Gemini API, and Vertex AI setup

Use this section when the workflow is developer-facing, API-based, production-facing, or needs tools, retrieval, structured outputs, batching, or backend validation.

Google AI Studio: Use AI Studio to prototype model behavior before implementation. This is where you can test prompts, model settings, structured output, function calling, code execution, grounding, and other Gemini API behaviors before moving the workflow into application code.
Gemini API system instructions: Put stable API-level behavior here. Use system instructions for role, task rules, output requirements, formatting requirements, workflow boundaries, and repeated behavior. Do not put secrets, API keys, private tokens, or privileged configuration in system instructions.
Vertex AI system instructions: Use Vertex AI system instructions for production workflows on Google Cloud. Use them for stable behavior rules, role, context, formatting, and repeated prompt behavior. System instructions guide behavior but are not a complete security boundary.
Generation config: Use generation configuration for model behavior parameters and response constraints. Use this when the workflow needs specific output behavior, supported thinking controls, structured response settings, or tool configuration.
Structured outputs: Use structured outputs when the response must follow a strict schema for UI rendering, extraction, automation, validation, or downstream processing. Treat model/tool support as model-specific and verify current compatibility before implementation.
Function calling: Use function calling when Gemini should call external APIs, application functions, databases, tools, or business systems. Function calling belongs in the tool/action layer, not in the instruction layer.
Code execution: Use code execution when the workflow needs Python-based calculation, transformation, data processing, or analysis. Do not treat code execution as a generic content-generation feature. Use sandboxing and validation for generated code workflows.
Grounding with Google Search: Use this when the workflow needs current or web-grounded information. This belongs in the retrieval/source layer, not in the instruction layer. Verify model support, billing behavior, and tool-combination support before use.
URL Context: Use URL Context when the workflow needs to retrieve and reason over specific known URLs. Use it for source-specific page analysis, not as a replacement for full document management or persistent retrieval.
Grounding with Google Maps: Use this only for location-specific workflows that need Maps grounding. Do not use it as a general reference layer for ordinary policy, code, document, or research workflows.
Files API: Use the Files API when an API workflow needs file-backed context for supported documents or media. Treat Files API uploads as request/file context, not as the same thing as persistent retrieval storage.
File Search: Use File Search when the workflow needs retrieval over imported files. File Search chunks, embeds, indexes, and retrieves relevant document sections through a File Search store. Use it for RAG-style workflows where the system must search across reusable documents.
File Search stores: Use File Search stores as the persistent retrieval container for imported documents. Do not confuse a temporary uploaded file with a persistent indexed retrieval store.
Batch API: Use Batch API for large-volume or offline request processing. Use it when the workflow can run asynchronously across many inputs. Keep request-specific instructions, files, tools, and output format explicit.
Interactions API: Use the Interactions API only when its Beta status is acceptable for the product. It is intended for model/agent interactions, state management, tool orchestration, and long-running tasks. Treat schemas and behavior as subject to change while Beta.
Vertex AI prompt templates: Use prompt templates when a workflow has a reusable prompt structure with replaceable variables. Use them for repeatable production prompts, testing prompt formats, and separating prompt structure from run-specific data.
Vertex AI prompt optimizer: Use prompt optimizer when you need to improve prompts or system instructions at scale, especially when changing models or reusing prompt sets.
Vertex AI context caching: Use context caching when repeated requests share large context and you need to reduce cost or latency. Treat cache creation, TTL, update, and deletion as infrastructure lifecycle concerns.
Application-side validation: Use application-side validation for schemas, policy checks, source checks, evals, tool arguments, and deterministic business rules. Do not delegate all verification to the model response.

4) Layer → where to put it in Gemini

Use this map after choosing the Gemini surface. The same workflow usually has multiple layers: stable rules, source material, current task input, tool actions, and verification.

Instruction layer

Put stable workflow rules here.

Gem instructions — repeatable workflows in the Gemini app.
Instructions for Gemini — broad account-level preferences across Gemini chats.
Gemini API system instructions — API and backend workflows.
Vertex AI system instructions — production workflows in Google Cloud.

Reference / source material layer

Put reusable source material here.

Gem Knowledge files — reusable reference files attached to a Gem.
Drive files in Gem Knowledge — living reference files when the newest Drive version should be used.
NotebookLM notebooks in Gem Knowledge — NotebookLM-backed reference material where available.
Files API — file-backed context for API workflows.
File Search stores — persistent retrieval over imported files.
URL Context — retrieval over specific URLs.
Grounding with Google Search — current web-grounded information.

Reusable workflow layer

Put repeatable workflow behavior here.

Classic Gem — reusable Gemini app workflow with instructions and optional Knowledge.
Gems from Google Labs / AI mini-apps — interactive mini-app workflow surface where available.
Application workflow — backend orchestration around Gemini API or Vertex AI.
Batch API — repeated offline processing across many requests.
Interactions API — agent-style or stateful workflows where Beta usage is acceptable.

Runtime prompt layer

Put only the current run’s task input here.

Current Gemini prompt — current question, current code, current document, or temporary task context.
Current Gem chat message — run-specific input to an existing Gem.
API request contents — current request payload in a Gemini API workflow.
Batch request item — one task inside a batch job.

Tool / action layer

Put external actions and computation here.

Function calling — external APIs, databases, tools, and business systems.
Code execution — Python execution for calculation, transformation, or analysis.
Search / URL / Maps grounding — retrieval tools for web, URL, or location-specific context.

Verification layer

Verification is a workflow requirement, not a single Gemini configuration surface.

Gem instruction requirement — require final verification inside a reusable Gem.
Second-pass prompt — run a separate verification pass before using the result.
Structured outputs — enforce response shape for downstream validation.
Application-side validation — enforce deterministic checks outside the model.
Prompt optimizer / evaluation loop — improve and test production prompts before rollout.

5) What not to put where

Do not put stable reusable workflow rules only in a one-off Gemini chat prompt if the workflow should be repeated.
Do not use Instructions for Gemini for workflow-specific rules that belong in one Gem or one API workflow.
Do not use Gemini Memory as a deterministic instruction layer or project-scoped workflow state.
Do not treat Connected Apps personalization as canonical source material for a controlled workflow.
Do not treat Knowledge files as instructions. Knowledge files are reference material; workflow rules belong in instructions.
Do not paste the same reusable source material into every prompt when Knowledge files, Files API, File Search, URL Context, or grounding are the correct layer.
Do not disable Knowledge citations for evidence-sensitive workflows unless there is a deliberate reason to remove citations.
Do not describe Gemini Memory as equivalent to ChatGPT Project Memory unless Google documents that exact project-scoped capability.
Do not describe Gemini as having a ChatGPT/Claude-style Skill folder surface unless Google documents that exact packaged workflow surface.
Do not assume every Gemini API tool can be combined with every other tool. Check current model and tool compatibility before implementation.
Do not treat system instructions as a complete security boundary. Pair them with validation, source checks, and application controls where risk is higher.

6) Practical placement examples

Code review workflow in a Gem: Put stable review rules in Gem instructions. Add coding policies, architecture rules, examples, and review checklists as Knowledge files. Put the current code or repository excerpt in the current Gem chat prompt. Require a verification pass before using the output.
Fact-checking or evidence review in Gemini app: Put broad response preferences in Instructions for Gemini only if they should apply across all chats. For a repeatable evidence workflow, prefer a Gem with Knowledge files. Keep the current claim set, source list, or document under review in the runtime prompt or attached run-specific files.
Research workflow with current sources: Use Gemini API system instructions for stable source and citation rules. Use Grounding with Google Search or URL Context when the workflow needs current web or specific-URL retrieval. Use structured outputs when the downstream system needs a fixed response shape.
Document-heavy API workflow: Use Files API for file-backed context in the current API workflow. Use File Search stores when the workflow needs persistent indexed retrieval over documents. Add metadata or filtering where the system must retrieve only a relevant subset of files.
Production workflow in Vertex AI: Put stable behavior in system instructions. Use prompt templates for repeatable variables. Use prompt optimizer and evaluation data before rollout. Use context caching when repeated requests share large context.
Agent or tool workflow: Use function calling for external APIs and actions. Use code execution for Python-based computation. Use Interactions API only when its Beta state and agent-oriented interface are acceptable for the product.

7) Official source check

Availability note: Gemini app, Gems, Knowledge files, Memory, Connected Apps, Gemini in Chrome, Google Labs Gems, AI Studio, Gemini API, Vertex AI, Files API, File Search, Batch API, Interactions API, and tool-combination behavior can vary by account, plan, workspace, region, model, product surface, and release stage. Use the current in-product UI and official Google documentation as the final gate.

Gemini: where each workflow layer lives