> For the complete documentation index, see [llms.txt](https://playbook.nativemsg.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://playbook.nativemsg.com/mcp/guides/build-an-experience.md).

# Build an Experience with Your Agent

From "I want customers to book over text" to live on a phone, in one conversation. Works the same in Claude, ChatGPT, or any connected client.

## 1. Describe it

Tell your agent the outcome, the trigger, and any systems involved:

> "Build a booking experience: when someone texts BOOK, show our three services, capture their preferred time, and confirm with an add-to-calendar button. Pull available slots from our scheduling API."

A good agent will play the design back as a plain-language flow before writing anything. Ask for changes here — it's the cheapest point to iterate.

## 2. Create

The agent calls `create_experience` with a name and the workflows (RCS Experience Schema). Things it should get right — check its plan if you're unsure:

* A **welcome workflow** (`welcome_workflow`) so new visitors never face silence
* A **fallback workflow** for unmatched input
* **Prompt → wait → validate** for every captured value, with timeout and error paths
* A **channel fallback**: plain-text variants for SMS-only recipients
* For external calls: a `fallback` workflow on every request, so an API timeout mid-conversation degrades to a graceful message, not silence

## 3. Test on a real phone

> "Add my number as a tester and let me try it."

The agent calls `add_tester_device` (you'll get an invitation to accept), you text the keyword, and you tap through the real thing. Test at least one failure path too — send a malformed time, let a prompt time out.

## 4. Go live

Attach a channel: `create_channel` with the experience's id (a channel runs one experience, chosen at creation). For RCS, your agent must be launched with carriers — until then it can only message tester devices.

## 5. Revise safely

Every `update_experience` saves a revision and returns its number:

* **Published experiences** keep running their published revision — edits are safe to stage.
* **Unpublished experiences with subscribed contacts** run the current revision, so an edit reaches those contacts immediately. The server refuses this (reporting the subscriber count) unless you explicitly force it — your agent should tell you and ask.
* Roll back anytime: "restore the previous revision" → `restore_experience_revision`.

## Connecting to your systems

Inside an experience, a `request` action calls any HTTP API mid-conversation and maps response fields to attributes used in later messages. If your AI tool is also connected to the target system (your CRM, your store), ask the agent to read that system's fields itself and generate the wiring — don't type field names it can look up. Never put raw API keys in experience JSON; use the platform's credential handling.

Schema reference for everything the agent generates: [playbook.nativemsg.com/rcs-experience-schema](https://playbook.nativemsg.com/rcs-experience-schema).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://playbook.nativemsg.com/mcp/guides/build-an-experience.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.