Skip to lesson

Google CloudProfessional Agentic Architect2026-091.1 Configuring agentic workflows and behavior using low-code tools

Write effective system instructions

Completed by the knowledge check

Learning objective

Write system instructions that establish an agent’s role, constraints, tool-use boundaries, and output requirements. This lesson covers behavioral guidance, not hard security enforcement or few-shot examples.

Core idea

A useful system instruction answers four questions in priority order:

  1. What job does the agent perform?
  2. What boundaries must shape its behavior?
  3. When may it use each capability?
  4. What must a valid response contain?

System instructions guide a probabilistic model. They are not an authorization system, schema validator, or guaranteed defense against prompt injection. Put hard controls in code and platform policy.

How it works

Start with a narrow role and outcome. “You are a procurement assistant that compares approved catalog items” gives more operational direction than “You are helpful.” State the intended audience and the point at which the agent should defer, ask for missing information, or abstain.

Next, express constraints as concrete behavior. Identify approved sources, forbidden actions, required evidence, privacy limits, and escalation conditions. Resolve conflicts by stating an order of precedence. Separate instructions from untrusted user or retrieved content with consistent headings or delimiters.

Define tool boundaries with the same precision:

  • name the situation that requires the tool;
  • state important situations in which the tool must not be called;
  • require necessary facts before calling it;
  • distinguish read operations from consequential writes;
  • require confirmation or approval when the workflow calls for it;
  • define behavior for empty, conflicting, or failed results.

CX Agent Studio supports explicit references such as {@TOOL: tool_name} and {@AGENT: Agent Name} in natural-language instructions; see CX Agent Studio instructions. References help bind the text to configured capabilities, but the runtime must still enforce whether an action is authorized.

Finish with an output contract: format, required fields, citation behavior, verbosity, and acceptable fallback. For machine-consumed output, use the model API’s structured-output feature when available instead of relying only on a prose request for JSON. Google’s Gemini prompt design strategies recommend direct, well-structured instructions and consistent separators.

Keep instructions concise enough to audit. Remove duplicated or contradictory rules, define ambiguous terms, and avoid embedding secrets. Google Cloud notes that system instructions apply to the whole request but do not fully prevent jailbreaks or leaks; see System instructions.

Evaluate the instruction against normal, ambiguous, adversarial, and tool-failure cases. Version it with the agent configuration so a behavior change can be traced to the exact instruction set.

Key distinctions and trade-offs

Role versus persona: A role defines responsibility and scope. A persona defines presentation style. “Triage support incidents” affects task selection; “use a calm tone” affects delivery.

Instruction versus enforcement: An instruction can say “never issue a refund above the limit.” Deterministic authorization and approval logic must prevent the tool call even if the model ignores that sentence.

Tool selection versus tool execution: The model may decide that a tool fits the request. The controller validates arguments, identity, permissions, and preconditions before execution.

More detailed instructions can cover edge cases but consume context and create conflicts. Short instructions are easier to maintain but may under-specify behavior. Add rules for observed failure modes, then validate them with an evaluation set rather than accumulating defensive prose indefinitely.

Architecture / decision scenario

An HR policy agent must answer from approved documents. Its system instruction defines the role, tells it to use the policy-search tool for policy questions, requires citations, and directs it to say that evidence is insufficient when no current policy supports an answer. It prohibits making employment decisions and routes those requests to HR.

The search service separately filters documents by the employee’s access. An output schema requires answer, citations, and status. A policy prevents any write tool from being exposed to this read-only agent.

The instruction improves behavior, while data access and capability restrictions remain enforceable even if malicious document text tells the model to ignore its role.

Common exam traps

  • Writing a decorative persona without a concrete responsibility or stop boundary.
  • Treating system instructions as a complete defense against jailbreaks and prompt injection.
  • Listing tools without stating when and when not to use them.
  • Placing secrets in instructions because end users cannot edit them.
  • Requesting complex JSON only in prose when structured output is available.
  • Adding rules without testing whether they correct a measured failure.

What to remember

  • Define role, constraints, tool boundaries, and output requirements explicitly.
  • State missing-evidence, failure, abstention, and escalation behavior.
  • Use platform controls for authorization and other hard constraints.
  • Keep untrusted content distinct from instructions and never place secrets in the prompt.
  • Version and evaluate instructions like other production configuration.

Knowledge check

References