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.
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’scontext 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.
Fetched from your own systems. Your CDP is not the only live source. You can
give the agent a tool that calls one of your own HTTP endpoints — an order lookup,
an account status — and it will call it mid-conversation when the question calls for
it. You define the endpoint, the arguments the agent may fill in, and, importantly,
exactly which fields of the response the agent is allowed to see: everything
else is discarded before it reads the answer, so a record carrying an email and a
phone number does not put them in front of the agent because you needed a status.
Authentication belongs in a stored credential rather than a header you type: a
credential is encrypted, resolved per environment when the tool runs, and its value
is never shown back to you or to the agent.
The same screen runs the tool against your real endpoint before any customer sees
it, and lets you save a canned response for testing — including a failure response,
which is the one worth writing. It is how you check the agent says it could not look
something up instead of inventing an answer.
Fields that must ride along with a search hit
A CDP search answers which object matched — id, display name, type, relevance — and nothing about it. That is usually right: the agent reads the object when it needs details. But some attributes are ones an answer cannot be assembled without, and the classic case is a URL slug. Given a product’s name and no slug, a model can produce a link that looks plausible and resolves to the wrong page, or to nothing. Name those attributes and every search hit carries them:attributes object with just those keys. The
selection is replaced on each call, and {"attributeKeys":[]} clears it.
Keep the list to two or three. Every named key is fetched for every result, so
this is a way to close a specific gap — not a projection API for pulling a whole
record through search. Keys must already exist in the type’s attribute catalog,
which is built from data you have actually sent; a key you have never upserted is
rejected rather than silently ignored.
This changes what the agent is given, not what it is told. It is the more
reliable of the two: an instruction to look a field up can be skipped, whereas a
field present in the result cannot be missed.
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.
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.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.Related
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.