Blueprints

A blueprint is the reusable intake flow behind an agent: the questions it asks, the criteria that qualify or disqualify a caller, its mandatory scripts and disclosures, and the tools it’s allowed to use. One blueprint can back several agents, so editing it can affect every agent built from it, though not immediately, and not without a check first.

​

What a blueprint is made of

• Gates: the individual things the agent needs to determine before moving on, such as a fact to capture, a question that qualifies or disqualifies the caller, or a consent to confirm. Gates run in sequence, and a gate can branch to a different next gate depending on the answer.
• Disqualifiers: the specific answers that end a caller’s case-worthiness, each with its own spoken reason so the agent can close the call respectfully instead of continuing to ask questions that no longer matter.
• Scenarios: a handful of variations on how the call opens, matched to the caller’s situation, for example a first-time inbound caller versus someone calling back, or an outbound dial. The gates and criteria underneath stay the same; only the opening changes.
• Mandatory scripts: disclosures and other fixed language, such as the recording notice or crisis-safety language, that must appear regardless of how the rest of the conversation goes.
• Tools: the actions available at each gate, such as transferring to a human or sending a retainer. See Tools.

​

The builder

Build blueprints at Blueprints in the Command Center. The gallery lists every blueprint in your organization, with how many agents currently use each one. Opening one takes you into the composer, where persona, scenarios, gates, scripts, and tools each have their own tab, plus a Test bench for dry-running gate logic with sample answers before you save. See Testing. Duplicating a blueprint with Duplicate & edit gives you an independent copy, with a fresh id and every internal reference remapped, so you can experiment without touching the original or the agents running on it.

​

How publishing works

Saving a blueprint in the composer saves the shared template, but it does not immediately change any agent already running on it. That agent keeps its last compiled version until it’s refreshed. Before a blueprint, or an individual agent-level edit, can take effect, it has to clear a publish gate:

• Compliance: every mandatory disclosure and required script has to be present in the compiled flow, verbatim enough to survive the substitutions a real call makes (for example, a caller’s name dropping in).
• Naturalness: a deterministic check that the agent won’t narrate its own process, leak internal scaffolding, or read like an automated phone tree instead of a conversation.
• Regression cases: for blueprints with a registered test corpus, a set of prior scenarios is replayed to confirm the change didn’t break an existing path.

A failing check blocks the change. You get back exactly what failed, whether that’s a missing script, a line that tripped the naturalness check, or a regressed case, and the agent keeps running its previous, last-good version rather than a half-applied one. An organization admin can override the gate for an urgent change; a manager cannot.

​

Applying a change to a live agent

After you save a blueprint, the composer tells you which of its agents are now out of date and offers to refresh them on the spot, or you can leave it for later; the agent’s own editor carries the same reminder until you do. Refreshing re-runs the publish gate for each agent, preserving whatever per-agent overrides that agent already had. Once an agent is refreshed, calls that start after that point use the new version. A call already in progress keeps running on the version it started with. Every save to a blueprint is kept in its version history, so you can review or restore a prior version if a change doesn’t work out the way you expected.