What makes up an agent?

An agent combines instructions with capabilities that handle customer requests. Playbooks support flexible conversations, workflows define explicit processes, and knowledge and tools supply information and actions. You decide how these pieces fit together.

When to use this model

Use this model when designing an agent or diagnosing unexpected behavior. First identify which part should own the job: routing, a goal-specific conversation, a defined process, a knowledge lookup, or an external action.

How the pieces work together

The agent brings guidance and capabilities together. Its global prompt establishes identity and guardrails; its instructions guide what to do next. Playbooks and workflows handle different kinds of work, supported by knowledge and tools.

One agent, complementary capabilities

Agent

Global promptIdentity and guardrails

InstructionsWhat to do next

Can use

Capabilities

PlaybooksPursue a goal

WorkflowsFollow a process

KnowledgeFind information

ToolsTake action

The agent’s guidance shapes how it uses its capabilities. Playbooks and workflows can work together, using knowledge and tools as needed.

What each part contributes

Part	Responsibility
Global prompt	Shared identity, tone, and guardrails for agentic responses.
Agent instructions	Guidance for routing requests and selecting capabilities.
Playbooks	Goal-specific conversations that adapt to what the customer says and what tools return.
Workflows	Defined steps and branches, including calls to playbooks where flexible reasoning is useful.
Knowledge	Retrieved information from your imported content.
Tools	Actions and lookups through integrations, APIs, functions, and system capabilities.
Variables	Named values that configured steps and tools can store and reuse.

Playbooks or workflows?

Need	Choose	Support example
Adapt questions and actions to the customer’s situation	Playbook	Clarify an order-status request and explain the lookup result.
Follow a defined process with explicit branches	Workflow	Collect an order ID, check return eligibility, then follow the eligible or ineligible branch.
Keep a controlled process with a flexible part	Both	Use a playbook to clarify a return reason inside a returns workflow.

A playbook can call tools, and a workflow can include AI reasoning. The distinction is how the process is controlled, not whether it uses AI.

Example: handle a return request

A customer wants to return an item. You want a consistent eligibility process, but customers describe their reasons in different ways. Combine a workflow with a playbook:

A returns workflow with a flexible conversation inside

Customer“I want to return this.”

Request

AgentSelect the returns workflow

Start

Returns workflow

PlaybookClarify the return reason

Reason collected

Eligibility checkContinue the defined process

The workflow controls the process; the playbook handles the conversation within it. Once the reason is collected, the workflow continues.

The agent recognizes the request and selects your Returns workflow. Inside that workflow, a playbook asks follow-up questions until the return reason is clear. The workflow then uses that information in its eligibility check and follows the appropriate path.

This is an example you can configure, rather than a built-in returns process. The playbook step’s exit connection joins the flexible conversation to the next workflow step. Configure that connection.

Instructions and state have different scopes

The global prompt and agent instructions are different layers. When a playbook is active, agent-level routing instructions are no longer in context; put the guidance it needs in its own instructions. Compare instruction scopes.

A variable is stored data, not the same thing as the model’s current context. Configure where values are captured, where they are referenced, and whether they persist across sessions. Do not assume changing from one capability to another makes all prior instructions available. Understand variables and context.

How agents work