Procedures

A procedure is an ordered workflow the agent must follow: verify the order, check the return window, then — and only then — issue the refund.

TIA Agents catalog with red callout boxes around the Agents tab, a capability group, and a capability card.

TIA Agents catalog with red callout boxes around capability enable actions.

The important word is must. Most platforms render workflow steps into the system prompt and ask the model to comply. TIA scopes the toolset instead. Each step declares which tools it may use, and the runtime filters the assembled toolset down to that list before the model ever sees it.

The agent cannot call issue_refund during a "verify the order" step because the tool is not in the object it received. Skipping a step is impossible, not discouraged.

Plan: the Procedures module is included from Growth.

When to use one

Procedures are for the conversations where the order matters and getting it wrong is expensive:

Refunds and returns where eligibility must be checked before money moves.
Warranty claims that need proof of purchase before a replacement is promised.
Account changes that need identity verification first.
Any regulated intake with a required disclosure.

If a conversation just needs good instructions, put them in the system prompt. Procedures cost you flexibility on purpose; spend that only where the enforcement is the point.

Anatomy

A procedure has a name, a trigger — plain language describing when it should start — and an ordered list of steps.

Step kinds

instruction — what the agent must do, plus the tools it's allowed to use while doing it. An empty tool list means "talk only": the agent can ask questions but can't act.

branch — a decision point with labelled options. Each option jumps to a named step or ends the procedure. The model picks the first option that applies.

finish — the end, with an optional closing instruction.

A worked example

Procedure:  Refund request
Trigger:    The customer asks for a refund or says they want their money back.

1. instruction  "Ask for the order number and look it up."
                tools: [ order_status ]

2. branch       "Is the order within the 30-day return window?"
                → Yes  : go to step 3
                → No   : go to step 5

3. instruction  "Confirm the refund amount with the customer."
                tools: []                       ← cannot refund yet

4. instruction  "Issue the refund and tell them when it lands."
                tools: [ issue_refund ]

5. instruction  "Explain the policy and offer store credit instead."
                tools: [ create_ticket ]

6. finish       "Thank them and ask if there is anything else."

At step 3 the agent physically cannot issue a refund. At step 1 it cannot either. Only at step 4 does issue_refund exist in its toolset.

Escape hatches

Enforcement that traps people is worse than no enforcement, so four tools survive any step's scoping:

Tool	Why it's always available
`request_human_handoff`	A visitor who asks for a human mid-procedure must be able to get one.
`procedure_complete_step`	How the agent advances.
`procedure_choose_branch`	How the agent takes a branch.
`procedure_abandon`	Leaving is an explicit, recorded act rather than silent drift.

If the visitor changes the subject, the agent abandons the run with a reason instead of dropping it quietly — so the audit trail shows what happened.

Validation

A malformed procedure doesn't just render badly, it strands a live conversation in a step with no exit. So the editor refuses to save a graph that can break:

A branch option pointing at a step that doesn't exist.
A branch option pointing at its own step.
A branch with no options.
A procedure that ends on a branch (add a finish step after it).
Any graph where some path can never reach an end.

That last check is a breadth-first walk with a visited set, so a deliberate cycle is reported rather than hanging the editor.

What gets recorded

Every run writes an audit trail: the steps actually walked, the branch choices made, and anything the agent collected along the way. That's what makes "did the agent verify the order before refunding?" a question with an answer, months later.

If a procedure is deleted or its steps are edited while a conversation is mid-run, that run is auto-abandoned on the next turn rather than deadlocking with a step that no longer exists.

How it reaches the model

The list of available procedures — name, id, trigger — is part of the agent's prompt, and the agent calls procedure_start as soon as a trigger matches.

The running procedure renders into the volatile part of the prompt, not the cached stable prefix. The current step changes every turn, and caching it would serve a stale step for the rest of the session. It sits above retrieved knowledge, because while a procedure is running it's the most binding instruction present.

Best practices

Write triggers in the customer's words, not yours. "The customer asks for a refund or says they want their money back" beats "refund intent detected".
Give a step the smallest toolset that lets it finish. The empty list is a real and useful choice.
Put verification before action, always. That ordering is the whole reason to build a procedure rather than write a longer prompt.
Branch on things the model can actually observe from the conversation or a tool result.
End every branch. Each option must reach a finish step or end the run.
Test in the playground before enabling. Walk the happy path and at least one refusal path.

Limits

Limit	Value
Plan	Growth and up (Procedures module)
Branch options	Bounded per branch — the editor states the maximum
Steps	Bounded per procedure — the editor states the maximum

Not yet shipped: {{variable}} interpolation from contact fields, starter templates, and a UI for browsing past runs. Run history is recorded today; only the viewer is missing.

Next steps

Chat Agents — custom HTTP tools, the things a step scopes to.
Helpdesk & Tickets — a common final step when a procedure can't resolve something.
Live Handoff — the escape hatch every procedure keeps open.