Procedures: enforce a checklist while the AI keeps the conversation¶

Last reviewed: 2026-09-24

A successful search can still return no records. A procedure can require a returned record ID before completing its lookup step, so an empty result keeps the step open for its retry or no-match instructions. After a successful tool action, the runtime can remind the agent of the next required step without running that action automatically. An empty lookup instead carries the current step's retry or no-match instructions. Write the retry limit explicitly in that step. The reminder numbers empty results so the agent can distinguish the first miss from an exhausted retry. An empty search does not undo completed identity verification. These reminders support the instructions you write; a retry limit in prose still depends on the agent following it.

A step's completion check should cover every detail that its instructions require. For a flow that collects information and then asks the customer to confirm it, use separate collection and confirmation steps before the final write. This lets the background checker catch missing information before the agent treats a partial read-back as permission to proceed.

A Procedure is a checklist the platform enforces while your agent keeps its natural conversational style. Use one where a Smart (prompt-driven) agent must reliably follow a sequence — verify the caller, confirm an amount, then take payment — but a fully scripted Guided flow would feel too rigid.

While the call runs, the platform ticks steps off as they complete, blocks locked actions (like a payment tool) until their earlier steps are done, and quietly nudges the agent back on track if it skips ahead or claims something happened that didn't.

The background checker uses recent conversation and retained outcome evidence. It leaves a requirement incomplete when evidence is missing or contradictory. An AI assessment cannot replace a required tool result or verified application state.

For asynchronous work, distinguish request started from work completed. Sending a payment request does not mean the payment succeeded. A procedure can track the accepted request as one milestone and require a confirmed payment before recording it. Similarly, showing a different card should not complete an appointment-card step.

Steps live inside the prompt¶

Procedure steps are blocks in the prompt itself — the step's instructions are ordinary prompt text you type inside the block, exactly where the model reads them. Open the agent's stage → Behavior tab.

To insert a step, type {{ (or @) at the spot in the prompt where the step belongs and pick Procedure step from the menu. The block appears at your cursor with its settings dialog open; type the step's instructions inside the block, between the teal STEP and END STEP pills.

The prompt editor's header row (next to Copy full prompt) shows the procedure summary:

• Generate steps — AI reads the instructions you already wrote and weaves named procedure sections and step blocks around them in place, without changing a word of your prompt (any steps you added by hand are kept, and each generated procedure gets a description). A toast confirms how many steps were added; review each STEP pill's settings. If the AI can't annotate without altering your text, nothing is changed and the toast says why — just try again. Shown when your tenant has AI generation enabled.
• A step counter and a warning badge when something needs attention.
• A Clear hidden steps button if steps are configured that no longer have blocks in the prompt — they'd still enforce on live calls, so the editor names them and lets you remove them in one click.

The same controls appear on each Smart subagent's tab for a procedure scoped to that subagent. Guided flows don't take one: their step script already is a procedure.

Steps run in the order they appear in the prompt. Reorder by moving the blocks; delete a step by deleting its block.

Multiple procedures and references¶

An agent can carry several named procedures in one prompt. Pick Procedure section from the {{ menu to insert a {{#procedure name}} … {{/procedure}} section, then add steps inside it. Each named procedure is its own checklist, and clicking its PROCEDURE pill opens its settings:

• Name — renaming updates the section and every reference to it.
• Description — one sentence on what the flow is for. The AI reads it when deciding which procedure to follow, and it shows in the reference picker.
• Applies when — a variable condition that arms or skips the whole procedure (e.g. intent == "refund" for a refund flow the agent only follows when the caller wants their money back).
• Enabled / Background checker toggles for the whole group.

A named procedure is active in the prompt where it's written, and its progress carries across subagents — a step completed before a hand-off stays completed after it. To make a procedure active in another prompt too (for example a subagent that should follow a flow defined on Main), type {{ there and pick it from the Procedure category — that inserts a {{PROCEDURE:name}} reference which renders the procedure's steps into that prompt at runtime and arms its checklist there. Steps outside any named section form the prompt's own default checklist, scoped to where they're written.

Step settings¶

Click a STEP pill to open its settings:

• Title — short and imperative ("Confirm the amount"). Shown in the live checklist and in the messages the agent sees when an action is blocked. The step's ID (used by conditions and variables) derives from the title.
• Done when — how the platform knows the step is complete:
• automatic (default) — if the step contains exactly one tool pill ({{TOOL:…}}), the step completes the moment that tool succeeds; if it shows one component, it completes when that component renders; otherwise a fast checker verifies the step's own instructions were carried out. Zero setup.
• a variable is set — a condition over session variables, built with the usual condition builder. Completes instantly, no AI involved.
• a tool succeeds — pick one of the stage's tools; the step ticks when that tool returns successfully.
• a custom AI-checked sentence — your own plain-English criterion ("The agent stated the amount aloud and the caller agreed.").
• Applies when (IF/THEN) — make the step conditional:
• always (default);
• a variable condition holds — e.g. region == "eu"; checked instantly as the call runs;
• the AI judges it applies — plain English ("The caller mentioned financial hardship."); the checker decides from the conversation. A step that doesn't apply is skipped — it shows dimmed in the checklist and never blocks later steps.
• In order — on by default: the step requires the one above it. Turn it off for steps that can happen any time.
• Irreversible (tool steps only) — locks the tool until every earlier required step is done. The agent physically cannot call it early; it gets a message naming the steps still open instead. If the checker can't answer in time chooses block (safe default) or allow.

Watching it work¶

Test the agent in Preview. A Procedure panel appears beside the phone the moment the checklist arms, ticking steps live as the call progresses — with a lock icon on gated steps, dimmed rows for steps that don't apply, and a short log of any corrections the checker issued. The same events are stored with the conversation, so the checklist survives into the post-call record.

The checker model¶

Judge steps, "applies when" AI assessments, and drift-checking use a small, fast "logic checker" model. It defaults per stack (for example Nova Micro on an AWS stack) and can be changed — or pointed at your own self-hosted OpenAI-compatible endpoint — under the stage's Auxiliary services section or Settings → Tenant Settings → Auxiliary Services. Its usage is metered separately in cost reporting, and cost forecasts include it automatically when an agent has procedures or extraction variables.

The logic checker section shows the selected default model in the normal model selector. Expand Procedure checker prompt or Entity extraction prompt to view and override its instructions. Use default prompt restores the inherited text. AI judge criteria remain on each individual condition.

Tips¶

• Prefer variable and tool completion — they are instant and free. The default AI check is great for conversational obligations; save custom judge sentences for criteria the step text doesn't state directly.
• Keep AI-checked sentences verifiable from the transcript ("the caller agreed"), not internal states ("the agent intended to…").
• Publishing checks your procedure: unclosed or duplicated step blocks, circular ordering, steps gating a tool the stage doesn't offer, and judge steps with the monitor switched off are all flagged before the agent goes live. An empty procedure just warns — it enforces nothing until it has steps.

When an action is blocked by an unfinished step, the agent receives that step’s instructions with the refusal. Include the exact tool or component to use in those instructions so the agent can recover without repeating the same mistake. For a checklist with several required answers, use smaller completion checks when a single broad assessment accepts partial answers.

Use clear step titles: the agent sees prerequisite titles in the tool descriptions before choosing an action. When a current background check identifies missing facts, the blocked action can pass those facts back as a recovery hint; older assessments are not reused after the conversation changes.

The background checker also listens to your caller's answers. When an action requires confirmation, it can wait briefly for that assessment before proceeding. A check still in progress is different from a missing answer; the agent should preserve an existing confirmation instead of asking for it again.