The Agent Definition¶

Anychat is the agent framework for business messaging. This page describes the Definition — the document you write to specify an agent — section by section. Two companion pages complete the picture: Capabilities covers the functionality you enable alongside the document, and How a turn is composed describes what Anychat does with the Definition at runtime.

What an agent is¶

In Anychat, an agent is a representative of your company or brand that talks to your customers and prospects in the rich messaging channels they already use — RCS, Apple Messages for Business, and WhatsApp — with automatic SMS fallback when a rich channel isn't available. Anychat also supports Viber, Instagram, Slack, and the Anychat web embed.

You describe the agent; Anychat does the wiring. It manages the conversation, generates the agent's responses, and translates them into whatever rich-messaging features the user's platform supports — suggestion chips, rich cards, calendar invites, dial actions, file attachments — so the same agent behaves natively across every channel.

The Definition¶

An agent is made of three things, each with its own verb. You write its Definition — the document this page describes. You enable Capabilities — scheduling, knowledge, people memory, outreach — which are configured, not authored. And you connect Channels — where it speaks.

Every section of the Definition is text that reaches the model: it either applies on every turn, governs one kind of situation, or supplies reviewed content the agent deploys verbatim. The smallest working Definition is an Identity and one Default Playbook; every other section is added as your use case demands.

You can read any agent's full Definition in the console — the Definition page shows it as one document, outline and all — and download it from Settings · Export & import as a portable file (see Exporting & Importing Agents).

The sections, in the order the document reads:

Section	What it holds	Applies
Identity	Who the agent is: name, company, contact details, branding.	Every turn
Personality	How the agent sounds.	Every turn
Guardrails	What the agent never does.	Every turn
Objectives	What a successful conversation achieves, in priority order.	Every turn
Playbooks	What the agent does, one situation at a time.	The active one
Content	Message Templates: reusable, exact-wording messages (text, cards, carousels); the media library they draw on.	When referenced

Identity¶

Who the agent is: its name, the company it represents, contact details (email, phone, website), legal links (privacy policy, terms of service), and branding (logo, banner, brand color). Identity applies on every turn — Anychat derives a short agent-level preamble from it ("You are Acme Corp's sales agent…") so the agent always knows who it is, and channels draw on the same fields when you bind them.

Identity is one of the two sections every agent needs. A new agent can be created with only a name; channel-specific details (RCS logo dimensions, banner image) are collected when you bind the channel that needs them.

Authoring guide: identity is edited at Settings · Identity; the fields each channel requires are covered in Channels.

Personality¶

The voice and tone the agent speaks in — distinct from what it does. Personality applies on every turn; it isn't something you attach per-Playbook. (A Playbook can ask for situational posture — "be more direct when handling refund disputes" — but the underlying voice stays consistent.)

Anychat ships a small library of personalities (Professional, Minimalist, Enthusiastic, Empathetic, Witty, Formal), each with a human-readable description and an agent-facing body behind an advanced toggle. Start from one, tweak it for your brand, or write your own.

Authoring guide: Personality.

Guardrails¶

What the agent never does. Guardrails apply on every turn, ahead of a Playbook's instructions; a Playbook can't override one. You typically express them as explicit lists:

Topics to avoid — subjects the agent should refuse to discuss (competitor pricing, legal advice, sensitive personal topics).
Claims to never make — statements about your product or company the agent must not assert without warrant.
Required disclaimers — language the agent must include in certain situations (regulated industries, financial or medical topics).
Additional rules — a free-form slot for any hard rule that doesn't fit the lists above ("never speculate about a customer's health", "always stay positive about partner brands"). Prose constraints, not general behavior — that belongs in a Playbook.

Anychat ships Guardrail catalog entries for common compliance shapes (healthcare disclaimers, financial-services disclaimers). Importing one merges its lists into your agent's guardrails, where you can edit them further.

On top of the guardrails you set, the platform applies a set of built-in guardrails to every agent — baseline rules every Anychat agent must respect (don't generate harmful content, don't leak internal source paths, don't impersonate a human). These aren't editable and can't be removed.

Authoring guide: Guardrails.

Objectives¶

An Objective is a desired conversational end-state — what success looks like at the end of a conversation ("the prospect has agreed to a discovery call"). Objectives apply on every turn and do two things:

During a conversation, they sit in front of the agent as a short, ranked background frame, helping it make better judgment calls within whichever Playbook is active. A Provide Product Information Playbook running under a Book a sales call Objective answers product questions with more momentum toward scheduling than the same Playbook would under Resolve technical issue.
After a conversation, the platform evaluates which Objectives were achieved and aggregates them into completion-rate analytics over time — so you can see that 40% of last week's conversations achieved Book a sales call.

An Objective is outcome-shaped, not instructional: "the prospect agreed to a call" is an Objective; "ask three qualifying questions, then propose a time" is Playbook content. You select the Objectives that matter to an agent and rank them, so that when they pull against each other on a given turn, the higher-ranked one wins. An agent without Objectives holds conversations normally; it just isn't being measured against a goal.

Authoring guide: Objectives.

Playbooks¶

A Playbook is a named mode of operation — a situated plan that tells the agent what to accomplish in this kind of moment, and how to approach it. An agent is always operating inside exactly one Playbook at a time. Moving between Playbooks is how the agent adapts as a conversation shifts from one kind of work to another: greeting and discovery, then product questions, then scheduling a call.

A Playbook is defined by three things:

A name and description — the labels you see in the console.
A when-to-use description — the activation context: when should the agent be operating in this Playbook? "When the user has expressed interest in talking to sales and we have enough qualifying info to book a call." This is how the agent recognizes which Playbook fits the moment.
An instructional body — the agent-facing text describing how to operate while this Playbook is active. The how.

A Playbook can also carry procedures (step-by-step instruction blocks of its own, below), reference Message Templates (reviewed copy from the Content section), rely on the agent's Capabilities — scheduling in a booking Playbook, knowledge in a product-questions Playbook — and carry a few examples of the behavior you want.

Anychat figures out when to leave a Playbook on its own. Because the agent always knows every other Playbook's when-to-use (see How a turn is composed), it moves on as soon as another Playbook fits the next phase of the conversation, and returns to the Default Playbook when a task is done. You don't author explicit exit rules; if a Playbook should wrap up a specific way ("once the call is booked, confirm the details and return to general help"), that's a line in its body.

Authoring guide: Playbooks.

The Default Playbook¶

Every agent has a Default Playbook — the general-purpose instructions the agent uses when no other Playbook is more appropriate. This is typically the opening of a conversation, the "what does this person want?" phase, and the connective tissue between more specialized modes.

The Default Playbook holds general behavior, not the agent's voice or its sense of who it is — those come from the agent's Personality and Identity, which apply everywhere automatically. And it doesn't need to list the agent's other Playbooks: the agent is aware of all of them at all times and routes to them as the conversation calls for it.

Examples of Playbooks¶

Default — the general-purpose opening. Greets the user, understands what they need, and moves to a more specific Playbook when one applies.
Schedule a Sales Call — activates when the user is ready to book. Relies on the Scheduling capability.
Provide Product Information — activates when the user is asking about products, pricing, or capabilities. Relies on Knowledge.
Handle Refund Request — activates when a customer asks about returning or being refunded for an order. Relies on a custom integration to your order system.
Graceful Fallback — activates when the agent genuinely can't tell what the user wants. Asks clarifying questions, surfaces human-contact options, never bluffs.

Special-purpose Playbooks¶

Two situations that used to feel like special cases are just Playbooks:

Outreach — when the agent starts the conversation rather than the user (see Outreach), it begins in the Playbook the send selected, or the one you've marked default for outreach. If you haven't defined one, it begins in the Default Playbook, exactly as an inbound conversation would.
Escalate to Human — a Playbook whose when-to-use is "the user has asked to speak with a person" (see Human escalation). Because every Playbook's when-to-use is always in view, the agent moves into it on its own when a user asks for a human; you don't wire anything up.

Procedures¶

A procedure is a named, step-by-step instruction block a Playbook carries with it — the exact mechanics of a task, the way Meeting Scheduling spells out proposing times, handling counters, and confirming a slot. Procedures belong to their Playbook: the agent reads them only while that Playbook is active, right alongside the Playbook's own body, and a capability's actions are offered when a procedure calls for them.

Most procedures arrive with a catalog Playbook — importing Schedule Sales Call brings its Meeting Scheduling procedure along — and each keeps its catalog lineage, so published updates surface per procedure. You edit a procedure inline in the Playbook editor, exactly like the Playbook's body. (Earlier versions modeled these as a separate "Skills" library that Playbooks referenced; that indirection is gone — the text now simply rides the Playbook that uses it.)

System skills¶

Separately from your Playbooks' procedures, Anychat applies a set of system skills automatically, based on the agent's configuration and the channel a conversation is on. When you define products, the agent learns how to discuss your catalog; when a knowledge base is attached, it learns to ground answers in it; on a rich channel it learns to use that channel's cards, chips, and actions, while on SMS it learns to keep messages short and plain. These apply at runtime, can't be edited or disabled, and are how the agent keeps working natively as you add more to it. You don't manage them — they're a property of the platform, not something you author.

Content¶

Message Templates are reusable, exact-wording messages: text you write, with {slot} placeholders (e.g. {person.firstName}, {agent.companyName}) filled in for each recipient from their Person record and the agent's identity, plus fallbacks for when a value is missing. Templates render the same way every time, so the message a person sees is copy you've reviewed, not improvised text.

Two things consume templates. Outreach uses one as the opening message of an agent-initiated conversation. And a Playbook can reference templates by name, so the agent deploys reviewed copy in the situations that Playbook handles (for example, a booking-confirmation message when an appointment is set).

A template body can carry rich-messaging markup (chips, a card, a carousel of cards), and the pictures in it come from the agent's media library: the images and videos the agent may show, each with a stable id, a name and an optional usage hint for people, and a description written by a vision model (editable) for the agent. Templates and playbooks name items by id, never by URL; the agent also reads the library and may attach an item itself when the description and hint say it fits. Removing an item deletes the hosted file; messages that still mention it send without the picture.

Authoring guides: Message Templates, Media.

Human escalation¶

Some conversations need a human — a frustrated customer, a question outside the agent's competence, an explicit request for a person. Anychat does not route conversations to a live human in real time. There is no realtime handoff. Instead, the agent surfaces the brand's own contact details so the user can reach a person directly.

This is handled by an Escalate to Human Playbook, whose when-to-use is "the user has asked to speak with a person" (or the agent has hit the limits of what it can do). The agent moves into it on its own, and the Playbook renders the brand's contact details — drawn from the agent's Identity (contactEmail, contactPhone, websiteUrl, plus an optional contactAvailability note like "Mon–Fri 9–5 PT") — as tappable elements: tap-to-call, a mailto link, an openUrl link. The user takes the action; the agent does not pretend a teammate is on the way, and when no contact details are configured it says so plainly rather than inventing them.

Anychat ships a ready-made Escalate to Human Playbook. If your brand handles escalation differently, edit its instructions or replace it — the contact-rendering still works, so you're changing the approach, not the mechanism.

Capabilities¶

Everything the agent can do beyond conversing — book calls, ground answers in your knowledge, remember people, start conversations, alert your team, call your systems — is a capability: functionality you enable and configure rather than author. Capabilities have their own page: Capabilities.

Capability	The agent can…
Scheduling	book, reschedule, and cancel calls with your representatives.
Knowledge	ground answers in your documents and product catalog.
People	remember each person and, if you allow it, save what it learns.
Outreach	start conversations with a reviewed opening message.
Notifications	alert your team where you choose.
Custom integrations	use abilities backed by your own HTTP endpoints.

Channels¶

The messaging apps your agent answers on. Anychat leads with the rich business-messaging channels — RCS, Apple Messages for Business, and WhatsApp — with SMS as an intelligent fallback when a rich channel isn't available. Viber, Instagram, Slack, and the Anychat web embed are supported too. Each channel binds independently; one agent can talk on one channel, several, or all of them.

You write your agent once, channel-agnostic. Anychat tells the agent how to make the most of whatever channel a given conversation is on — so it uses rich cards, suggestion chips, and dial actions where the channel supports them, and composes plainly where it doesn't — and translates the agent's replies into each channel's native format. The same agent Definition behaves natively everywhere it speaks.

There are two ways to connect a channel. Managed (the default): you name the channel and supply the business details its setup form asks for — brand name, banner, registration info — and Anychat provisions it end to end: provider selection, credentials, and the carrier, Apple, or Meta workflow are all handled for you. Rich channels take days to weeks to provision; the binding reports its status (Requested → Provisioning → Active, with ActionRequired when something needs your input) the whole way. Unmanaged: if you already have your own provider relationship — your own Twilio account, Webex Connect tenancy, Google RBM agent, or WhatsApp Business Account — you can bring it and supply its credentials instead. Webchat is created automatically with every agent. See Channels in the Agent API.

Each channel has its own setup requirements and its own identity fields. RCS, for example, requires specific logo dimensions, a banner image, a contact email, a website URL, a privacy policy URL, and terms of service; webchat needs none of that. The agent carries identity defaults, and when you create a channel binding Anychat pulls those in and prompts you only for what's still missing — so a new agent can be created with just a name, and the RCS-specific details supplied when you actually bind RCS.

After a binding is created, its identity is its own. Updates to the agent's name or logo don't automatically propagate, and some channels (RCS in particular) require administrative updates at the provider that can't be made automatically — so each binding's identity is best understood as a snapshot of what that channel actually has.

Agent Templates and the Catalog¶

Two different things help you build faster, and it's worth keeping them distinct in your mind.

Agent Templates are complete starting points for a whole agent, aimed at a common use case — a Sales Development Agent, a Med Spa Concierge, a Franchise Development Agent. This is what you pick first when creating an agent. An Agent Template is a full agent document with identity omitted: it carries a Default Playbook, additional Playbooks, a Personality, Guardrails, capability configuration, and a starter outreach greeting — everything except the per-agent name, branding, and contact details. Creating an agent from a template copies that document onto a fresh agent; from there it's yours to edit.

The Catalog is the library of reusable sections and pieces you draw on while shaping an agent — individual Playbooks (with their procedures), Objectives, Guardrails, and Personalities curated by Anychat. The Schedule Sales Call Playbook, the healthcare disclaimers Guardrail set: pull any of them onto an agent that needs it.

Catalog pieces copy on import: when you pull one onto an agent, its content is copied in and the agent owns that copy — you edit it freely. Each imported piece keeps a back-link to its catalog origin, so the console can show you when your local copy has diverged, and preview the changes when Anychat publishes a new version. Adopting them is your choice. (Agent Templates are a one-time scaffold and don't carry this ongoing relationship — once your agent exists, it's just your agent.)

Both are curated by Anychat; you don't publish your own. Neither includes identity (name, logo, contact details) or external-service credentials — those are always per-agent, configured after you import.

Framework v2 (preview)¶

Preview

Framework v2 is available to orgs that hold the framework-v2 feature. Ask your Anychat contact to enable it.

Framework v2 is a second runtime for the same Definition. Everything this page describes (Identity, Personality, Guardrails, Objectives, Playbooks, Content) is read unchanged by v2; what changes is how a turn is composed and what you can see afterwards. The full operator description is in The agent framework (v2 preview). What differs, in brief:

A runtime switch, per agent. The agent's Overview page shows a Switch to v2 preview control (and Switch back to Generic). Switching is reversible and takes effect on the next turn; a conversation in progress resumes in the new runtime's Default Playbook with the same transcript. Through the API it is PATCH { "framework": "v2" } on the Agent. Check the Readiness card first: lint lists the v1-only constructs v2 ignores.
Capabilities per Playbook. On v2 a Playbook declares the capabilities it draws on in Uses capabilities (uses: scheduling, knowledge, people, notifications, or a custom integration), and only those are offered while it is active. Procedures' requiredTools are not read; a Playbook's uses governs. A Playbook with no uses gets every ready capability (the lenient default), and lint suggests the list to declare, with a one-click Declare fix on the Readiness card. See Capabilities (v2).
Deterministic paths. A Playbook that describes a procedure (booking, consent, intake) can carry a fixed path the platform walks step by step, generated from the Playbook's own text and checked before you accept it. The body becomes the path's brief. See Playbooks and Flows.
Rules the platform enforces. Guardrails still steer the agent's judgment. v2 adds Policies: checks the platform applies before a capability action runs and after a reply is written, which the agent never sees and cannot override. Your own output checks appear on the Definition page under Rules the platform enforces. See Rules and safety.
A record of every turn. Each v2 turn keeps a record (which Playbook was chosen and why, what was offered and called, which Policies fired, the path steps that ran, latency) that you open from a conversation with Inspect turns. See How a turn works.

System skills, the switch_playbook mechanism, and procedure requiredTools described above are v1 runtime behavior; on v2 they are replaced by capability manifests, a router decision, and uses. Agent Templates and the Catalog apply to both runtimes.

Where to go next¶

The agent framework (v2 preview) — the v2 runtime for the same Definition: the one promise, capabilities per Playbook, Flows, Policies, turn records.
Capabilities — the functionality you enable alongside the Definition: scheduling, knowledge, people, outreach, notifications, custom integrations.
How a turn is composed — what Anychat does on each turn: how the Definition's sections are assembled into the agent's instructions, and how conversations move between Playbooks.
Playbooks — authoring Default and additional Playbooks, writing good when-to-use descriptions, and patterns for handoff behavior.
Objectives — choosing, ranking, and authoring Objectives, and reading completion-rate analytics.
Guardrails — the four rule lists and the compliance catalog.
Personality — picking a voice and tailoring it to your brand.
Capabilities in the console — enabling, configuring, and connecting; custom integrations.
Knowledge & Products — documents, website import, and the product catalog.
Message Templates — reviewed copy with slots and fallbacks.
People — the per-agent CRM and how Person records are populated.
Channels — binding an agent to RCS, webchat, and the other supported messaging apps.
API reference — the Agent API for building and configuring agents programmatically, and the Messaging API for integrating Anychat's runtime message delivery into your own systems.