Skip to lesson

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

Correct recurring behavior with few-shot examples

Completed by the knowledge check

Learning objective

Use few-shot prompt templates in Gemini Enterprise low-code tools to correct recurring behavior and tool-selection errors. This lesson focuses on configuring and selecting examples, not on model tuning or authorization controls.

Core idea

A few-shot prompt teaches by demonstration. It gives the model a small set of example inputs paired with desired responses or actions. The model infers the pattern and applies it to the current conversation.

When you configure an agent in Agent Designer or Customer Experience Agent Studio (CX Agent Studio), treat an example as a governed configuration artifact, not as loose text pasted onto the end of a prompt. In CX Agent Studio, examples are first-class resources under projects.locations.apps.examples, with create, get, list, patch, and delete operations.

Dialogflow CX provides the clearest mental model: a playbook example is a sample conversation that includes both the dialogue and the agent’s actions. Google states that these examples are effectively few-shot prompt examples for the large language model. Because an example can contain tool invocations, it can demonstrate the correct tool and arguments for an intent that the agent repeatedly misroutes.

How it works

Begin with trace evidence. Identify a repeated error, such as choosing a write tool for an information request or treating “no results” as a tool failure. Write the intended rule in one sentence, then create the smallest examples that make the decision boundary visible.

Use the same structure for every trajectory. For example:

User input: What is the status of invoice 1842?
Agent action: call get_invoice with invoice_id "1842"
Agent response: Invoice 1842 is awaiting approval.
State: OK

User input: Approve invoice 1842 for payment.
Agent action: call route_to_invoice_approval with invoice_id "1842"
Agent response: I routed invoice 1842 to a human approver.
State: ESCALATED

The second trajectory demonstrates what the agent should do instead of stating a prohibition. The matching labels also prevent the format itself from becoming an accidental lesson. Google’s few-shot prompting guidance explains that models learn formatting, phrasing, scope, and patterns from examples. It recommends consistent tags, whitespace, newlines, and example separators.

In a CX playbook, an example is a series of actions. Supported actions include user input, agent responses, tool use, and playbook invocation. A tool-use action records the tool, operation, input, and output. This full trajectory is why an example is more useful for a recurring tool-selection error than an isolated input/output pair.

Each example and playbook invocation also has a state:

  • OK: The playbook achieved its goal.
  • CANCELLED: The user decided not to continue.
  • FAILED: An error prevented the playbook from continuing.
  • ESCALATED: The playbook transferred the situation to a human.
  • PENDING: The conversation is still continuing in the playbook.

The state is part of the demonstration. Correcting behavior sometimes means showing a non-OK outcome. For example, use ESCALATED to demonstrate that a request requiring human approval must be handed off rather than completed by the agent.

Key distinctions and trade-offs

Few-shot examples versus instructions: An instruction states a rule; an example demonstrates the rule in a conversation. CX Agent Studio’s instruction guidance recommends starting with clear instructions and adding few-shot examples when instructions alone don’t correct the behavior.

Few-shot examples versus tuning: You can change configured examples without running a separate training process. Selected examples consume prompt context; tuning learns from a larger dataset outside the request prompt.

Example versus test case: An example influences runtime behavior. A held-out test case measures behavior and should not automatically become a production example.

CX playbooks provide three selection strategies that control context use:

  • Dynamically select includes an example when it is relevant to the current conversation. The platform may omit it near the token limit.
  • Always select includes an example regardless of relevance, although the platform may still omit it near the token limit.
  • Never select excludes an example. Use it to disable an example temporarily while testing.

Dynamic selection reduces unnecessary context, but a relevant example isn’t guaranteed to appear near the token limit. Always selection is appropriate for a critical boundary, but it increases context use and still isn’t a deterministic policy control. More examples can cover more variation, but they can conflict or overfit behavior. Use a small, high-information set and verify it with evaluation results.

Architecture / decision scenario

A service-desk agent repeatedly calls reset_password when users ask how a password reset works. The team creates one example that calls the read-only knowledge tool for an informational request. A second example performs identity verification before a reset. A third example routes a request to reset a colleague’s password to a human and ends in ESCALATED.

The team marks the common informational and reset examples as Dynamically select. It marks the cross-user security boundary as Always select, then tests behavior near the context limit. The held-out evaluation set uses wording not present in the examples. Tool-choice accuracy improves, but the reset service still enforces caller and target authorization. Examples correct routing; they don’t become the security boundary.

Common exam traps

  • Treating CX Agent Studio examples as arbitrary prompt text instead of managed conversation-and-action resources.
  • Writing a prohibition where the example should demonstrate the desired action and terminal state.
  • Using inconsistent labels or formats across examples.
  • Assuming every configured example is included on every request.
  • Treating Always select as guaranteed inclusion near the token limit.
  • Treating an example tool call as authorization to execute it.
  • Evaluating only the examples included in the prompt.

What to remember

  • Use few-shot examples to demonstrate a recurring decision boundary.
  • In CX Agent Studio, examples are managed conversations with agent actions, including tool invocations.
  • Demonstrate the desired trajectory and state, including non-OK outcomes.
  • Choose dynamic, always, or never selection based on relevance, context cost, and testing needs.
  • Validate improvement on held-out cases and retain deterministic tool controls.

Knowledge check

References