Tags

Tags are labels Fini applies to every conversation automatically, in real time. They’re how the system understands what each conversation is about: what state it’s in, and whether the agent behaved correctly, and they’re how you turn that understanding into routing logic, analytics, and quality control.

Tag Groups page showing a list of group cards. Each card has a tag icon, a group name, optional badges (Rulebook, Default, Mandatory), and a description. The top-right shows an agent selector set to All, and a New Group button.

The page header reads Tag Groups because tags don’t exist on their own, every tag belongs to a group: and each group represents one classification dimension. A group like Sentiment contains the tags Positive: Neutral: Negative; a group like Type of Issue contains the tags for whatever issue categories you want tracked. Fini evaluates one decision per group, per conversation.

What tags are for

Tags do three jobs at once. Understanding which job a tag is doing tells you how to configure it.

Job	What it looks like	Example
Observability	Tag fires; you filter and report on it. Doesn’t change agent behavior.	Type of Issue = billing: used to find all billing conversations in the Inbox or chart the issue mix in Analytics.
Routing	Tag is consumed by a Rulebook condition that branches the conversation. Requires the Tag Group available in Rulebooks toggle.	Action Confirmation = user_confirmed → Rulebook proceeds with the cancellation; user_denied → Rulebook sends apology and offers alternatives.
Reply behavior	Tag suppresses or modifies the reply itself via Reply Behavior.	Sentiment = spam-like → skip reply entirely rather than engage.

A single tag can only do one job at a time, but a single group can drive different jobs depending on how its toggle is set and which downstream systems read it.

How tags get applied

After each message exchange, Fini evaluates every active tag group against the conversation. For each group, it reads the group’s AI Instructions (the decision rules you’ve written) and picks the tag, or tags, that match. This happens automatically. You don’t trigger it, customers don’t see it, and tags accumulate on the conversation as it progresses. They’re visible on every conversation in the Inbox and queryable via filters and Analytics. The quality of your AI Instructions directly determines the accuracy of your tags. Vague instructions produce inconsistent tagging. A specific instruction, “apply escalated if the agent used the FALLBACK HATCH phrase or said ‘let me connect you with our team’; apply resolved if no follow-up is pending”: produces reliable, actionable tags.

Write AI Instructions as if you’re briefing a teammate on how to label transcripts manually. The model follows your wording closely, so be explicit about edge cases (“if the customer asks a clarifying question after the agent’s answer, still apply resolved”) and provide example phrases the agent says or the customer says that should trigger each tag.

Types of tag groups

Two orthogonal dimensions classify every group:

Dimension	Values	What it controls
Origin	Default (Fini ships it) vs. Custom (you create it)	Whether the group is editable. Default groups are read-only; Custom groups are fully editable.
Behavior	Mandatory (always-on, no opt-out) vs. Optional (you assign to specific agents)	Whether you can disable the group or scope it per-agent.

The cards on the Tag Groups page surface these as badges. A group with no badges is a fully editable Custom group. A group with Default is Fini-shipped but optional. A group with both Default and Mandatory (currently just one: Conversation Status) is Fini-shipped and always on. The Rulebook badge is independent of all of this, it indicates the group’s tags are usable as Rulebook conditions.

Default groups

Default groups are pre-built by Fini and available to all accounts. They cover the classifications most teams need out of the box.

Tag Groups list highlighting Default-badged groups including Knowledge Gap, Escalation Reason, Type of Issue, and Sentiment, alongside the Mandatory Conversation Status group.

Group	What it captures
Conversation Status	The state of the conversation, Resolved, Escalated to Human Agent, Waiting for Customer. The system tag that drives the Inbox status badge, Reply Behavior decisions, and resolution analytics. See Conversation Status below.
Sentiment	The customer’s reaction to the agent’s most recent reply, Positive, Neutral, Negative. Useful for satisfaction tracking and identifying conversations where the agent is failing the customer.
Escalation Reason	When the agent escalates, why. Eleven tags split across Knowledge gaps, Action failures, User-driven requests, and Policy triggers. The diagnostic backbone for “what is my agent struggling with?”
Type of Issue	The category of issue the customer is asking about. Used for triage and prioritization.
Knowledge Gap	Whether knowledge was missing from the knowledge search results, surfaces gaps in your knowledge base.

Default groups aren’t editable in their core configuration, title, description, AI Instructions, tag list, Tag Selection mode, and Rulebook availability are all locked. The group detail page shows a “This is a default tag group and cannot be edited” note in place of the Edit Overview button. What you can control is which agents each Default group is active on: see Assigning groups to agents.

Mandatory groups, Conversation Status

There is exactly one Mandatory group, and it’s load-bearing: Conversation Status. Conversation Status is the tag the rest of Fini depends on to understand what state a conversation is in. The Inbox status badge, Reply Behavior rules, “Fini Touched” filters, and resolution analytics all read from this tag. That’s why it’s both Mandatory (always on, every agent) and Default (Fini-controlled, can’t be edited).

Conversation Status group detail page showing the Mandatory and Default badges, the AI Instructions field with the four-step decision rule, Tag Selection 'Exactly one tag is selected', and the three tags Resolved, Escalated to Human Agent, Waiting for Customer.

It has three tags, applied via an explicit four-step decision rule the model follows in order:

Tag	When it applies
Escalated to Human Agent	Either: the agent has explicitly handed off (used the FALLBACK HATCH, said “let me connect you with our team,” or otherwise confirmed a human will take over); or the agent says a request was forwarded, passed on, or handed off to an internal team and indicates the team will follow up with the customer directly.
Waiting for Customer	The agent asked for specific required info or action necessary to proceed, and the conversation can’t move forward without it.
Resolved	None of the above. The agent gave a complete answer (or a complete acknowledgment of background work) and no follow-up is pending.

Because Conversation Status drives downstream systems, its instructions are written defensively, they encode specific phrases the agent uses (e.g. “I have forwarded your request to our specialist team” → Escalated to Human Agent vs. “Our finance team will process your payment automatically within 1-2 business days” → Resolved). When debugging why a conversation got the “wrong” status, read the AI Instructions on this group, the rules are explicit.

Conversation Status is not available as a Rulebook condition (the toggle is off and locked), its job is to describe what already happened, not to gate what happens next.

Custom groups

Custom groups are ones you create from scratch for your specific business. Fully editable: you set the title, description, AI Instructions, individual tags, multi-select behavior, and Rulebook availability. Three patterns cover almost all custom groups in practice. Match your use case to a pattern, and the configuration decisions follow.

Rulebook-driven (intent routing)
Observability (classification)
Guardrails (QA)

Read the user’s intent and feed the result into a Rulebook condition that branches the conversation.

Setting	Recommendation
Tag Group available in Rulebooks	ON: this is the defining choice
Tag Selection	Typically “Exactly one tag is selected”, the Rulebook condition expects a single value
AI Instructions	Must be tight, errors here cause the Rulebook to fire the wrong branch

Examples from real workspaces:

Action confirmation: Did the user confirm or deny a destructive action (cancel subscription, account closure)? Tags: user_confirmed, user_denied, not_applicable. Rulebook uses this to either execute the action or send an apology.
Background check status request: Is the user asking for a generic update or a specific check’s status? Tags: not_clear, specific_progress_update, generic_progress_update, query_not_related_to_check. Rulebook routes each to a different reply flow.
Role Confirmation: Has the agent confirmed the user’s role, and what role? Drives access-gated flows.

Rulebook-driven groups are the “control plane” tags, their job is to be read by downstream logic: not to be reported on.

For tags that capture something the agent did (confirmation, role check, action outcome), adopt the naming convention <Subject> by 'Finibot', Role Confirmation by Finibot: Action confirmation by Finibot. It signals to anyone reading a Rulebook condition that this tag describes the agent’s behavior, not a property of the customer or message.

Categorize conversations so you can filter, segment, and report on them. The tag is the destination, not an input to behavior.

Setting	Recommendation
Tag Group available in Rulebooks	OFF: you don’t need it; turning it on adds noise to the Rulebook condition picker
Tag Selection	”Multiple tags can be selected” is common, a single conversation can be about multiple topics
AI Instructions	Can be looser than routing tags, minor misclassifications hurt reporting accuracy but don’t break behavior

Common examples (fintech context):

Issue Category: what the customer is asking about: transactions, account_access, card_issues, transfers, kyc_verification, disputes. The single most common observability tag, drives the bulk of triage and reporting.
Product Area: which feature or surface the conversation touches: debit_card, savings_account, investments, lending, crypto. Lets you see conversation mix by product line rather than by issue.
Customer Lifecycle Stage: new_signup, active, dormant, churned, reactivation. Useful for understanding what support load looks like at each stage of the funnel.
Transaction Type Referenced: when a conversation references a transaction, what type: ach, wire, p2p, card_payment, refund, chargeback. Multi-select, since one conversation can reference several.

Build whatever observability groups make your conversation data queryable for your business. The pattern is the same: name the dimension, list the values it can take, write AI Instructions that pick the right value from the conversation.Observability groups are the “reporting plane”, their job is to make your conversation data queryable.

Detect when the agent does, or fails to do, something it should have. Used for compliance auditing, behavior review, and catching regressions.

Setting	Recommendation
Tag Group available in Rulebooks	Typically OFF: guardrails report on behavior after the fact and don’t usually need to gate live behavior
Tag Selection	Binary Pass/Fail is the common shape, so “Exactly one tag is selected”
AI Instructions	Specific, the model needs to identify whether the agent itself crossed the line, not whether the customer did anything wrong

Examples from real workspaces (the Guardrail | ... naming convention is a Fini convention worth adopting):

Guardrail | PII Redaction: did the agent reveal personal data it shouldn’t have?
Guardrail | Tone & Compliance: did the agent use neutral, non-accusatory language on sensitive topics?
Guardrail | Vendor / Product Claim Safety: did the agent make unsupported performance or accuracy claims?
Guardrail | Regulatory Accuracy: did the agent imply regulatory approval, compliance status, or legal outcomes?
Guardrail | Prompt-Injection Detection: did a user attempt to jailbreak the agent, and did the agent comply?
Guardrail | Knowledge Restriction Compliance: did the agent hallucinate beyond approved knowledge?

Guardrail groups are the “audit plane”, apply them to every agent and review flagged conversations in Inbox regularly.

For regulated industries, prompt-injection-detection and PII-redaction guardrails are particularly valuable: they create an auditable record of where the agent’s behavior diverged from policy. Pair these with the Test Suite so you can prove your agent’s behavior over time.

Anatomy of a group

A tag group has six configurable fields, visible on the group detail page.

Tag group detail page showing the Group Title, Group Description, AI Instructions, Tag Selection, and Tag Group available in Rulebooks fields, plus the Tags section below with the per-tag editor.

Field	What it does
Group Title	Short, descriptive name (e.g. “Type of Issue”: “Guardrail \| PII Redaction”). Shown on the page list, used by your team to find the group.
Group Description	Human-readable context for your team, what this group classifies and why. Not used by the model.
AI Instructions	The decision rules the model follows to pick a tag. The single most important field, accuracy comes from here.
Tag Selection	”Exactly one tag is selected” (mutually exclusive options) or “Multiple tags can be selected” (a conversation can carry multiple tags from the group).
Tag Group available in Rulebooks	Whether this group’s tags can be used as conditions in Rulebook rules. Off by default; turn on for Rulebook-driven groups.
Tags	The individual values the model can apply. Each tag has a name (machine-readable, e.g. `user_confirmed`) and a description (which doubles as the per-tag decision rule).

Creating a group

Click + New Group

Opens the create form on the page.

Fill in the group details

Set Group Title: Group Description: and a first pass at AI Instructions. The instructions can be refined later, focus on getting the decision logic written down, including edge cases and example phrases.

Set Tag Selection

“Exactly one tag” for mutually exclusive options (most cases). “Multiple tags” when a conversation can legitimately belong to more than one category.

Decide on Rulebook availability

Turn Tag Group available in Rulebooks on if you plan to use this group’s tags to gate Rulebook rules. Leave off for observability and guardrail groups. You can change this later.

Click Create Group

The group is created and you land on the group detail page. The tags section at the bottom is where you add the individual tag values.

Adding tags to a group

In the Tags section at the bottom of a group’s detail page:

Enter a tag name: short, machine-readable (e.g. resolved, user_denied, billing_dispute). This is what you’ll reference in Rulebook conditions and see in Inbox filters.
Enter a description: this doubles as the decision rule for when to apply this specific tag. Be explicit. Include example phrases the customer or agent uses that should trigger it.
Click + Add.

Repeat for every tag in the group. Use the edit and delete icons on each row to refine later.

Writing effective tag descriptions

The description on every tag doubles as the decision rule the model uses to apply it. A description that just labels the tag (“refund-related conversations”) leaves the model to guess at edges; a description that teaches the decision produces consistent tagging. The pattern that works:

What the tag means. A one-sentence definition the team would agree on.
When to apply it. The signals, phrases, customer behaviors, conversation states, that should trigger the tag.
When not to apply it. The lookalike cases the model will over-classify into this tag unless you rule them out explicitly. This is the part that separates good descriptions from drifting ones.
Example phrases. One or two real or representative messages that should and shouldn’t trigger it.

A worked example for a cancel_request tag in a Type of Issue group:

Section	Content
What it means	The customer is asking to cancel their subscription or close their account.
When to apply	The customer explicitly states intent to cancel (“I want to cancel”: “please close my account”: “how do I unsubscribe”), or asks the next step in cancelling. Apply even if the message is phrased as a question (“can you cancel my plan?”).
*When not* to apply**	The customer is asking about the cancellation policy without stating intent (“what’s your refund policy if I cancel?”: apply `cancellation_inquiry` instead). The customer is venting about wanting to leave but hasn’t asked (“this product is terrible”: apply `negative_sentiment`, not this tag). The customer mentions cancellation as context for an unrelated issue (“after I cancelled last month, I noticed…”: apply the relevant follow-on tag, not this).
Example phrases	”I want to cancel my subscription.” / “How do I close my account?” / “Please cancel and refund me.”

A few additional principles:

Distinguish between similar tags in the same group. When two tags could plausibly fit, the description must say what makes this one the right pick. “Apply this tag, not general_complaint, when…” removes ambiguity the model can’t resolve on its own.
Avoid internal jargon. Acronyms and product shorthand your team uses won’t translate to model behavior. Write the description as if onboarding a new teammate who has the AI Instructions for context but doesn’t know your specific terminology.
Use the model’s mistakes to refine. When you find a mis-tagged conversation in the Inbox, read the AI Steps reasoning (see Debugging tags with AI Steps below) and update the description’s “when not to apply” section to handle the case the model got wrong.

The “when not to apply” section is the highest-leverage part of a tag description. Models default to over-applying tags that sound roughly right, being explicit about lookalike cases is usually what moves a tag from “mostly correct” to “reliable enough to drive Rulebook conditions.”

Assigning groups to agents

Default and Custom groups must be explicitly assigned to each agent before they become active on that agent’s conversations. Mandatory groups (Conversation Status) are always active and don’t need assignment.

Tag Groups page in assignment mode with an agent selected from the top-right dropdown, showing checkboxes on each tag group card.

Pick the agent

Click the agent selector dropdown in the top-right of the Tag Groups page and select the agent you want to configure.

Check the groups to activate

Checkboxes appear on every group card. Check the groups you want active on this agent’s conversations.

Click Save

The selected groups become active. From this point forward, every conversation handled by this agent will be evaluated against these groups.

Group assignment is per-agent. If you have multiple agents (e.g. Support-Billing and Support-Onboarding), each carries its own set of active groups. Switch agents in the selector to configure each independently.

Tags in Rulebooks

Tags become control-plane data the moment the Tag Group available in Rulebooks toggle is on. The tags then appear in the Rulebook Check step’s condition picker, where you can branch flow based on the value. Common patterns:

Pattern	Example
Confirmation gate	`IF Action Confirmation = user_confirmed` → execute the cancellation; `IF user_denied` → send apology, offer alternatives.
Topic routing	`IF Type of Issue = billing` → route to billing specialist queue.
Guardrail escalation	`IF Guardrail \| PII Redaction = fail` → escalate to compliance team immediately.
Intent-specific reply flow	`IF Background check status request = specific_progress_update` → call the check-status action; `IF generic_progress_update` → use the generic reply template.

A concrete example. The rule below uses a Rulebook-driven tag (Account Tier) to gate whether a premium-only flow proceeds. The Check step asks: “Is the customer on the premium tier?”: and only if the tag value equals premium does the rule continue. Other tier values fall through to whatever the Fallback block defines (typically a reply explaining the feature isn’t available on their plan).

A Rulebook rule named 'Verify Premium Account Holder' showing a Check step with the condition 'Account Tier Equals premium'. The Check is wrapped in a Steps block called 'Check account tier, premium' which sits inside a Fallback block called 'Account tier gate'.

Two things this example illustrates. First, tag-driven Checks pair naturally with Fallback blocks: the Check defines the positive case (Account Tier = premium → proceed); the Fallback catches the negative (any other tier value → fall through to the alternative reply). Second, for tags that capture something the agent itself did or confirmed (rather than a property of the customer), the naming convention <Subject> by 'Finibot': Role Confirmation by ‘Finibot’: Action confirmation by ‘Finibot’: is worth adopting. It tells the reader instantly that this is an observable state of the agent’s behavior, not a customer attribute.

Tags are the most reliable input to Rulebook conditions. They’re set before the Rulebook rule runs (during the tagging phase), so the value is stable. Compare with Read step extractions, which run as part of the rule and can fail or return unexpected values. When you have a choice between branching on a tag versus extracting the same information mid-rule, choose the tag.

Mandatory tag groups (Conversation Status) are not available as Rulebook conditions. Their job is to describe the conversation’s final state, not to gate routing decisions. Only Default groups with the toggle enabled (e.g. Escalation Reason) and Custom groups with the toggle on appear in the condition picker.

Troubleshooting

Debugging tags with AI Steps

Every conversation in the Inbox carries the model’s full tagging reasoning. Open any conversation and click the AI Steps panel, under Output Tag Selection you’ll see the reasoning the model used to choose every tag from every active group, plus the Chosen Tags list with the exact value picked from each.

AI Steps panel for a conversation showing the Output Tag Selection section. The Reasoning text explains the model's tagging choice in natural language. Below it, Chosen Tags lists each active group (Checks, Errors, Sentiment, Knowledge Gap, Type of Issue, Check Sub item, Escalation Reason, Conversation Status) with the specific tag value applied to this conversation.

This is the primary debugging surface for tags. When a tag fires unexpectedly, the reasoning text tells you exactly why: what signal the model latched onto, what it weighed against, and how the AI Instructions led to the chosen value. Use it as a feedback loop:

Find a conversation where the tag was wrong

Filter the Inbox to the suspect tag value, or open a specific conversation you know was mis-tagged.

Read the AI Steps reasoning for that group

The reasoning paragraph reveals what the model was thinking. Look for misinterpreted signals, “the conversation was already escalated by the assistant” might explain why a downstream tag fired the way it did.

Update the AI Instructions to handle that case

Add an explicit rule covering the missed edge case. If the model thought the customer’s frustration about the product was frustration with the agent: your Sentiment instructions need to disambiguate the two explicitly.

Save and verify on the next conversation

Changes take effect for new conversations. Run the same kind of message through and confirm the AI Steps reasoning now produces the right value.

The reasoning text isn’t visible to customers, it’s an internal trace meant for you. When a stakeholder asks “why did the bot tag this as escalated?”: the AI Steps panel is the answer. Treat it the way you’d treat logs in a system you operate.

Why a tag isn’t being applied correctly

The group isn't assigned to this agent

Default and Custom groups must be explicitly activated per-agent. Open the Tag Groups page, select the agent, and confirm the group’s checkbox is on. Mandatory groups (Conversation Status) are exempt.

The AI Instructions are too vague

“Apply this when the customer is unhappy” gives the model nothing to anchor on. Rewrite with specific phrases, example messages, and explicit edge-case handling. Use the model’s mistakes as your guide, read the conversations where it got the tag wrong and update the instructions to cover those cases.

Tag descriptions are missing or generic

The model uses each tag’s description as its per-tag decision rule. Empty or one-word descriptions force the model to guess. Write every tag’s description as a specific rule (“apply this if X happens AND Y is true”).

Tag Selection mode doesn't match the use case

“Exactly one tag” forces a single choice, if a conversation legitimately falls into two categories, the model has to pick one and may not pick consistently. Switch to “Multiple tags can be selected” if your tags aren’t mutually exclusive.

The Rulebook toggle is off but you expected a tag in the condition picker

Tags only appear as Rulebook conditions when the group’s Tag Group available in Rulebooks toggle is on. Mandatory groups (Conversation Status) can never appear in the picker, that’s by design.

You're inferring from totals, not from the conversation

Tags are applied per message exchange and recorded per-conversation. Don’t infer behavior from analytics totals or filter counts, open the specific conversation in the Inbox and read the AI Steps panel (see Debugging tags with AI Steps) to see exactly which tags fired and why.

Rulebook

Use tag values as Check step conditions to route, branch, and escalate conversations.

Reply Behavior

Use tags to suppress replies entirely, for example, skipping conversations classified as spam.

Inbox

Filter and review conversations by tag. Conversation Status drives the status badge on every row.

Analytics

Chart tag distribution over time. Track topic mix, escalation reasons, sentiment trends, and guardrail violations.

Getting Started

Agent Configuration

Deploy

Test & Ship

What tags are for

How tags get applied