Skip to main content
Boom runs one agent per organization, not a separate bot per use case. The agent that runs a win-back campaign is the same agent that staffs a support line, runs a research round, handles onboarding, qualifies a lead, or collects a document from a customer. Whatever the mission, it carries your organization’s voice and what it knows about your business into the conversation. Treat it like a teammate you brief, not a workflow you have to feed a prompt to on every step. You set your refund policy, your tone, and the facts about your business once, and the agent applies them in every conversation it runs, regardless of which mission that conversation belongs to.

​
How you brief it

The knowledge base is how you brief the agent. Each organization has its own, organized into areas:
  • Brand voice: how the agent should sound.
  • Policies: what it can promise, refund, or has to escalate.
  • Data schemas: the people, objects, and events it can reason about.
  • Company information: the facts about your business it can draw on.
The agent reads from this knowledge base to answer in your voice and stay inside your rules, no matter which initiative the conversation is part of. You don’t edit the knowledge base through this API. You prepare its content and hand it to Boom, and the build-knowledge-base skill runs that as a guided interview: it asks what it needs, researches your own site, and hands you a structured bundle to pass along. On top of the knowledge base, each initiative carries its own per-initiative context and guiding questions, the specifics of that one mission. The knowledge base is the constant across every conversation; the per-initiative layer is what changes from mission to mission.

​
What it knows about the person it is talking to

An initiative’s context is a briefing, not a template. Nothing in it is interpolated, so writing a placeholder there gets you the literal text and no value. Facts about the individual reach the conversation two different ways, and the difference matters when you are designing around them. Pushed in, on every turn. Whatever you supplied when you enrolled that person, plus anything the trigger carried, is part of the agent’s context from the first message onward. This is the dependable path: no lookup, no decision, nothing to enable. Use it for anything that should shape how the conversation opens. Fetched, if the agent decides to. The agent can also read live data from your CDP mid-conversation, which is what makes it useful for questions that only come up because the conversation went there. Three things gate it, so do not design an opener around it: the CDP read tools are entitled per organization and are not on by default, only the first few person attributes are listed for the agent up front, and naming a field in your briefing does not compel the agent to go look it up.
If a value matters to every conversation, pass it at enrollment. If you do want a live lookup, write the instruction as an imperative that names the tool and the field, rather than mentioning the field and hoping the agent infers it.

​
How it improves from feedback

When someone on your team gives a thumbs-down to an agent message and says what was wrong, an internal agent reviews the reasoning behind that message, patches the knowledge base, and writes a new evaluation case that reproduces the failed conversation.
The new version of the agent only ships if it passes that new evaluation case, alongside every evaluation case written before it. A correction that regresses a past fix never reaches your organization.
Each correction your team makes is locked in as a permanent test, not a one-time patch. The agent you have after a month of use is meaningfully better than the one you started with, because every mistake anyone corrected along the way is now a case it has to keep passing.

​
When it hands off to a person

The agent handles a conversation end to end when it can, and escalates the ones it shouldn’t handle. Escalated conversations land in a shared inbox where a person can take one over: reply, leave internal notes, and send or receive files. The customer’s attributes sit alongside the conversation, so whoever picks it up has context without asking the customer to repeat themselves.

​
Guardrails while it talks

Before the agent responds, the conversation is checked for prompt injection. Before a response goes out, it’s reviewed to stop it from sharing personal data it shouldn’t.
If a customer asks to stop, that’s respected: the contact is not messaged again, even if someone re-enrolls them into a later initiative. Do Not Contact is enforced by the platform, not by whoever built a given flow.

​
Reliability

Messages are queued and retried with spacing rather than sent in a burst. If the primary model provider goes down, Boom falls back to another one so conversations don’t stall.

Journeys

The workflow behind an initiative, and how you author and publish one.

Extraction

The typed fields the agent pulls out of a conversation, and how you read them back.

Customer Data Platform

The people, objects, and events behind the data schemas in the knowledge base.

Use MCP

Connect an AI tool to the same organization and capabilities.