How a turn is composed¶

This page describes what Anychat does when a user sends a message: how the sections of the Definition are composed into the agent's working instructions, turn by turn. It's the runtime mirror of The Agent Definition — same sections, same order. Read that page first for what each section is; read this one for what the runtime does with it.

What you author and what the model works from are two views of the same document. The Definition is the source; each turn, Anychat composes a working set from it: the always-on sections in full, the active Playbook in the foreground, and everything else pulled in only as the turn needs it.

A conversation turn¶

Once an agent is configured, every user message follows the same path:

User → messaging channel → Anychat gateway → agent runtime
                                                  ↓
                load the conversation context (history + memory)
                retrieve relevant knowledge (if a knowledge base exists)
                assemble the agent's instructions:
                  identity preamble
                  + personality
                  + guardrails
                  + objectives (ranked, if any)
                  + active Playbook body + examples + its procedures
                  + system skills (channel + configuration)
                  + Playbook index (other Playbooks' activation hints)
                  + a way to hand off
                generate the agent's reply
                (loop) carry out any actions the agent takes,
                       including Playbook handoffs
                save updates: history, memory, Person record
                                                  ↓
            agent runtime → Anychat gateway → messaging channel → User

This flow has the following properties:

Channel-agnostic in definition, channel-native in delivery. The agent's Playbooks don't know whether the user came in via RCS, webchat, or Slack. Anychat applies the appropriate channel system skills for the current conversation, then translates the agent's reply into the channel's native format (suggestion chips, rich cards, calendar prompts, dial actions).
It remembers. The conversation history — plus what the agent is tracking, like which Playbook is currently active and the switches made so far — is kept per user, so follow-up turns build on the last one.
Action-taking. The agent can take an action mid-turn — using a capability, looking something up, switching Playbooks, updating a Person record — and then continue with the result. The action is not shown to the user; only the final reply is.

What the agent works from on every turn¶

Every turn, the agent's instructions are assembled from:

The identity preamble — a short, system-generated agent-level prelude ("You are Acme Corp's sales agent…"), derived from the agent's identity. You don't author it.
The Personality — the agent's voice, applied on every turn.
The Guardrails — applied ahead of everything else; Anychat's baseline rules first, then yours.
The Objectives, if any — ranked, short, as a background frame.
The active Playbook's content — its body, examples, and its procedures (plus the system skills Anychat adds for this conversation's channel and from your configuration).
A Playbook index — the name and when-to-use description of every other Playbook on the agent. Enough for the agent to recognize when a different Playbook fits the next phase, without carrying content the current turn doesn't need.
A way to hand off to a different Playbook.
The relevant Knowledge for this turn, when a knowledge base exists.
The conversation history.

The active Playbook is foreground; the other Playbooks are headlines; Personality and Guardrails are constant; Objectives are the background frame.

How a conversation moves between Playbooks¶

How a handoff happens¶

When the agent decides another Playbook now fits better than the active one, it hands off to that Playbook by name, and Anychat:

Marks the new Playbook as the active one.
Records the switch in the conversation's history.
Reassembles the agent's instructions around the new Playbook and continues the same turn.
The agent replies from within the new Playbook, with the full conversation still in view.

The user sees a single, coherent reply. There's no "returning you to the main menu" — the seam is invisible. Nothing is lost across a handoff: the new Playbook takes over with everything the agent has learned — every prior turn, every Person-record update, every action's result. The user does not have to repeat themselves.

How leaving a Playbook is decided¶

You don't author exit rules. Because the agent always has every other Playbook's when-to-use in front of it (the Playbook index), it leaves the active Playbook as soon as another clearly fits the next phase, and returns to the Default Playbook when a task is complete. The Default Playbook is the home it comes back to.

What the conversation remembers¶

Alongside the message history, Anychat tracks which Playbook is active right now and the sequence of switches that have happened (and when). That's what lets the agent know where it is without re-reading the whole transcript, and what your analytics draw on to report how conversations move between Playbooks.

Preventing loops¶

If two Playbooks have overlapping activation contexts, an agent could switch back and forth. Anychat limits this and surfaces it in the console:

A single user turn can trigger only a small number of Playbook switches; beyond that, the agent finishes its reply from the Playbook it's in.
Within a turn, a Playbook can't hand straight back to the one that just handed to it. (Across turns it can — the user has said something new.)
The agent stays put unless another Playbook clearly fits the next phase. Switching is the exception.
When the same pair loops repeatedly, the console flags them with their when-to-use descriptions side by side so you can spot the overlap and revise one.

Asking instead of guessing¶

When it's genuinely unclear which Playbook applies, the agent asks rather than guesses ("Are you looking to schedule a call, or do you have questions about the product first?"). This is part of the Default Playbook's job.

Special-start conversations¶

Outreach. When the agent starts the conversation (see Outreach), the first message is a reviewed Message Template, rendered with each recipient's details. The conversation then begins in the Playbook the send selected (falling back to the Playbook you've marked default for outreach, then the Default Playbook), and everything downstream — handoffs, Objectives, capabilities — behaves exactly as it does for an inbound conversation.
Escalation. When a user asks for a human, the agent moves into the Escalate to Human Playbook through the same handoff machinery as any other Playbook switch.

How each section becomes behavior¶

Identity preamble — a thin agent-level prelude, applied regardless of which Playbook is active.
Personality — applied on every turn as the agent's voice.
Guardrails — placed ahead of everything as constraints that override Playbook instructions; baseline rules first, then yours.
Objectives — placed in priority order as the background frame. They shape judgment during the conversation and are evaluated afterward for completion-rate analytics.
Active Playbook — contributes its body, examples, and its procedures (plus the system skills Anychat adds for your configuration and the channel). The agent operates inside it until a handoff or the end of the conversation.
Playbook index — a compact list of the other Playbooks' names and when-to-use descriptions, so the agent knows what it can hand off to.
Handoff — moves the agent between Playbooks mid-conversation; each switch is recorded and surfaces in analytics.
Knowledge — retrieved on demand whenever a knowledge base exists: on each turn Anychat searches for the passages most relevant to what the user just said and supplies them as context. Internal sources stay internal — the agent cites public URLs where appropriate but won't reveal internal file names or document identifiers.
Capability actions — things the agent does mid-turn: booking a slot, searching knowledge, updating a Person record, calling a custom integration. Anychat carries the action out with that agent's configuration (including credentials), hands back the result, and lets the agent continue — all in the same turn, so the user sees only the final reply. A capability's actions are offered only when the active Playbook (or one of its procedures) calls for them and the capability is ready.
Person records — loaded at the start of a turn and saved at the end. The agent reads them as context and, when you've allowed it, writes new facts it learns.
Conversation memory — which Playbook is active and the history of switches — loaded at the start of each turn and saved at the end. It's what makes Playbook routing reliable and reportable.