Skip to content

How an agent runs

This page describes what Anychat does when a user sends a message and how the building blocks combine at runtime. It's a companion to The Agent Framework — read that first for the concepts; read this when you want to know how they become behavior.

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
                  + referenced Skills (incl. system skills for the
                    channel and your 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 — invoking a tool, 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 the bodies of any Skills it references (including 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:

  1. Marks the new Playbook as the active one.
  2. Records the switch in the conversation's history.
  3. Reassembles the agent's instructions around the new Playbook and continues the same turn.
  4. 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 tool 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 you've marked outbound (or the Default Playbook if you haven't defined one), and everything downstream — handoffs, Objectives, tools — 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 block 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 the bodies of its referenced Skills (yours 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.
  • Tools — actions the agent takes during a turn. When it uses one, Anychat carries it 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 tool is offered only when the active Playbook or a referenced Skill calls for it and its configuration is complete.
  • 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.