The Agent Framework¶

Anychat is the agent framework for business messaging. This page introduces the building blocks of an Anychat agent and how they fit together. The companion How an agent runs page describes what happens at runtime when a user sends a message.

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.

The smallest agent you can build is barely more than three things:

An identity — a name and a logo so users know who's talking to them (and a personality, which has a sensible default until you change it).
A Default Playbook — the general-purpose instructions the agent follows when a conversation starts and no more specific situation applies. This is the seed from which every conversation grows.
One or more channels — the messaging apps the agent should answer on.

From that minimal configuration Anychat builds a fully-functional chat application. 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 definition behaves natively across every channel. You describe the agent; Anychat does the wiring.

The sections below describe the building blocks you add to turn that minimal configuration into an agent for a real brand: one that knows your products, behaves consistently across many situations, takes actions on the user's behalf, and stays within the limits you set.

The building blocks¶

An Anychat agent is composed from a small set of building blocks. You select the ones that apply to your use case; most are optional.

Playbooks are the heart of the system — they describe what the agent does. Tools are how the agent reaches beyond the conversation to get things done. The remaining blocks — Skills, Knowledge, Personality, People, Guardrails — shape and support that behavior. Objectives are a distinct, optional layer for driving and measuring business outcomes; they're introduced on their own and aren't needed to understand the rest of the system.

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, optionally, reference Skills (reusable instructions, see below) and Tools (actions it may need to take), and carry a few examples of the behavior you want. These are conveniences layered on the three essentials above — you can build a complete agent without any of them.

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 an agent runs), 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 just a line in its body.

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. References the Meeting Scheduling Skill and the Calendar Tool.
Provide Product Information — activates when the user is asking about products, pricing, or capabilities.
Handle Refund Request — activates when a customer asks about returning or being refunded for an order. References the Order Lookup Tool.
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:

Outbound — when the agent starts the conversation rather than the user (see Outreach), it begins in a Playbook you've marked as outbound. 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.

Tools¶

Tools are the actions an agent can take during a conversation — alerting your team to an important event, looking up or updating a customer record, querying the knowledge base, browsing the web, sending email, scheduling a meeting. Tools are fundamental: they're how an agent interacts with the wider world, whether that's an Anychat-provided service like the People CRM or an external system like your order-management platform.

Anychat's built-in tools are general-purpose capabilities, not vendor-specific connectors. The agent sees a single Notify Operator tool, not a separate Slack tool and Email tool; a single Manage Users tool, not a separate Monday tool and HubSpot tool. You choose which service sits behind each one, and that choice does not enter the agent's vocabulary. The result is a small, stable set of tools that behave consistently across the services you connect — and you can swap the service behind a tool without changing how the agent behaves.

Each agent enables the tools it needs and provides any details the tool requires (which calendar to read, where notifications should land, which board to write records into). These details — including credentials — belong to each agent individually: every agent connects to a service under its own login, so one agent's access is independent of another's.

Secret values — API keys, webhook URLs, auth headers — are write-only. Once you save one, it is stored encrypted and not shown back to you: the console displays it as •••• set with a Replace action, and it does not appear in an exported definition. An exported definition (or an Agent Template) carries the agent's behavior, not its secrets.

Custom tools¶

Anychat's built-in tools cover common needs, but every business has systems of its own. A custom tool lets you give an agent a capability backed by your own HTTP endpoint. To the agent it looks exactly like a built-in tool — a named capability it can call mid-conversation; the difference is that you implement what happens when it's called.

You define a custom tool by giving it:

A name — the capability the agent calls, e.g. lookupOrder.
A description — what it does and when the agent should use it. This is what teaches the agent the tool's purpose, so write it the way you'd brief a new teammate.
Parameters — the inputs the agent should supply, described as a small schema (e.g. orderId is a string). The agent fills these in from the conversation.
An HTTP endpoint — the method, URL, and any authentication header Anychat should use to call your service. The header is write-only, like every other secret.

At runtime, when the agent decides the tool applies, Anychat calls your endpoint with the parameters the agent supplied, hands the response back to the agent, and lets it continue the turn. Built-in tools run as Anychat code; custom tools run as a call to your service, which is why the contract is an HTTP interface you provide.

A tool — built-in or custom — is only offered to the agent when its configuration is complete and the active Playbook (or one of its referenced Skills) calls for it.

Skills¶

A Skill is a reusable piece of instruction — a pattern of behavior worth writing down once and using in many Playbooks, the way "active listening" or "summarize and confirm" are techniques a human salesperson reuses across situations. A Skill is, at its core, named instruction text: when a technique is useful and how to apply it. Some Skills also reference a Tool the agent needs to act.

Skills are a convenience. They exist so you don't retype the same guidance into Playbook after Playbook. A Skill has no effect on its own; it becomes active only when a Playbook references it. You can use Anychat's catalog of Skills, author your own, and reuse them across any agents you build — but you can build a perfectly good agent without ever touching one. In one sentence: Playbooks reference Skills; Skills don't know about Playbooks.

Examples of Skills: Meeting Scheduling (propose times, handle counters, confirm a slot), Discovery (surface needs through open questions), Recap Before Closing (summarize and confirm before ending), Handle Pricing Objection (acknowledge, reframe, redirect).

System skills¶

Separately from the Skills you choose, 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.

Knowledge¶

The brand-specific facts the agent should ground its answers in: product catalogs, policy pages, marketing copy, pricing, FAQs, internal documents. You add this content to the agent's knowledge base, and from then on it is always available to the agent — on every turn, Anychat pulls in the most relevant material so the agent can ground its answers in your curated knowledge rather than improvising.

You don't have to hand-curate the knowledge base. Anychat can import content automatically: point it at a public website and it crawls the relevant pages, or connect an internal document store and it imports those documents the same way.

The agent grounds answers in this material and cites public sources where appropriate, but won't reveal internal file names or document identifiers.

Personality¶

The voice and tone the agent speaks in — distinct from what it does. Personality is part of the agent's identity and always applies, the same way Guardrails always apply; it isn't something you attach per-Playbook. (A Playbook or Skill 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.

People (CRM)¶

Most useful agents need to remember the human they're talking to across turns and across channels — name, contact info, company, status in your funnel, and whatever custom facts matter to your business. Anychat keeps a Person record per end-user per agent. This record is the agent's CRM: there's no external system to wire up, and it's the single source of truth your team and the agent both read from.

The heart of it is the set of custom fields you define — the facts about a person that matter to you (e.g. "target market", "budget", "renewal date"), on top of the built-in ones like name, email, and funnel status. These are what the agent can refer to during a conversation, and, when you allow it, what it can fill in.

Person records start populated from intake — form fields submitted at the start of a conversation, channel-provided contact details, or a bulk import. From there, you decide whether the agent may update People with what it learns. With that turned on, the agent saves facts as they come up naturally — never by interrogating the user to fill a form — writing only the fields you've declared and never overwriting a known contact detail unless it's correcting it. Turned off, the agent still reads the Person record as context but doesn't write to it.

Alongside the structured fields, each Person carries a memory journal — free-form notes the agent records as it learns, plus a one-line summary written automatically when a conversation ends, so the contact accumulates a readable history. The journal is compacted as it grows.

To mirror records into an outside system, point a custom tool at it; a working CRM does not require one.

For the practical side — defining the fields, importing contacts from a spreadsheet, and how product interest maps to your catalog — see People & Intake.

Outreach¶

By default an agent is reactive — it answers when a user messages it. Outreach lets an agent start the conversation: send the first message to a person on a supported channel (RCS today), then hand off to the normal conversational machinery.

The opening message is a Message Template — 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 first thing a person sees is copy you've reviewed, not improvised text.

Message Templates are general-purpose, reusable content — not just an outreach greeting. 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). Outreach is simply one consumer of a template; the same template library is available to your Playbooks.

After the greeting goes out, the conversation begins in the Playbook you've marked outbound (or, if you haven't defined one, the Default Playbook), and proceeds exactly like an inbound conversation — Playbooks, handoffs, Objectives, and tools all behave the same. Outreach is just a conversation that starts with a reviewed first message and a specific opening Playbook; there's nothing special to learn beyond that.

For the click-by-click guide — adding a person, sending them the opening message, and how your team is notified of booked calls — see Reaching Out to People.

Guardrails¶

The constraints that keep the agent on-brand and out of trouble. Guardrails always 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.

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.

Objectives — an optional layer¶

Objectives are an Anychat innovation layered on top of an agent to drive and measure business outcomes. They're powerful, but you don't need them to understand how an agent works — a fully functional agent has none. This section is a brief introduction; the Objectives guide covers authoring and analytics in depth.

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 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.

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 definition with identity omitted: it carries a Default Playbook, additional Playbooks, a Personality, Guardrails, Skills, and a starter outreach greeting — everything except the per-agent name, branding, and contact details. Creating an agent from a template copies that definition onto a fresh agent; from there it's yours to edit.

The Catalog is the library of reusable building blocks you draw on while shaping an agent — individual Playbooks, Skills, Objectives, Guardrails, and Personalities curated by Anychat. The Schedule Sales Call Playbook, the Meeting Scheduling Skill, the healthcare disclaimers Guardrail set: pull any of them onto an agent that needs it.

Catalog building blocks 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.

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.

Where to go next¶

How an agent runs — what Anychat does on each turn: how the building blocks are assembled into the agent's instructions, and how conversations move between Playbooks. See How an agent runs.
Building your first agent — a walkthrough of creating an agent in the Anychat console.
Playbooks — authoring Default and additional Playbooks, writing good when-to-use descriptions, and patterns for handoff behavior.
Channels — binding an agent to RCS, webchat, and the other supported messaging apps.
Objectives — choosing, ranking, and authoring Objectives, and reading per-Objective completion-rate analytics.
Skills — using catalog Skills and authoring your own.
Tools — built-in tools and authoring custom HTTP-backed tools.
Knowledge bases — uploading documents and tuning retrieval.
People — the per-agent CRM and how Person records are populated.
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.