Google gives two prompt frames for two audiences

Start here

Someone typing into a Gemini app at work and someone calling the Gemini API from code are reading different Google guidance, and it shows. Google's API prompting strategies page, retrieved 16 September 2026, lists clear instructions, choosing between zero-shot and few-shot examples, adding context, breaking a task into steps, adjusting parameters such as temperature, iterating on wording, and using grounding tools such as search to reduce invented answers. Its separate Workspace guide for business users skips model parameters entirely and instead names four things to put in a sentence: persona, task, context, format.

What the documents say

The API page's own recommended template for its current flagship, described on the page as Gemini 3 models, is structural rather than a sentence: it recommends XML-style tags for role, constraints, context and task, and states a rule for where to put the most important parts, placing essential behavioural constraints, role definitions and output format requirements in the system instruction or at the very beginning. The same page also says to keep temperature, top_p and top_k at their defaults for its 3.x models specifically, even though an earlier, more general section on the same page lists experimenting with those parameters as a general strategy. The Workspace page never mentions parameters at all; its one worked example is a program-manager email prompt built from the four named parts. Both are Google's own documentation, describing its current products as retrieved, not an outside test of them.

Check this

The check is to place the same request into both templates and compare what each forces a person to specify. The four-part Workspace sentence forces a persona and an output format even for a casual request; the API-style tags force a separation between a fixed constraint and a one-off task, which matters more once a prompt is reused in code. A reader can also test the parameter caveat directly by trying a non-default temperature on the current flagship model and checking, against the page's own warning, whether output quality changes.

What holds and what fails

The persona-task-context-format frame holds well as a beginner's checklist for a single request typed by hand; it is short enough to remember. It fails as a description of what changes a reused, coded prompt's reliability, where the API page's advice about fixed structure and default parameters matters more. This is an editorial distinction: the two pages do not compare themselves to each other, and a reader has to notice the difference in audience to see why the advice diverges.

• Match the guide to the interface: the Workspace four-part sentence for typed requests, the API's tagged structure for anything called repeatedly.
• Leave temperature and similar parameters at default on a current flagship model unless a specific page says otherwise.
• Put the one constraint that must never be violated at the very start of a prompt, as the API page recommends.

Two guides from one vendor are not a contradiction so much as a map of who each page assumes is reading it, and that map is worth checking before copying either one wholesale.