Home Tags How ClaudIA's Tag System (Tagger) Works

How ClaudIA's Tag System (Tagger) Works

Last updated on Aug 29, 2026

When to use

  • You want to understand how ClaudIA chooses the final tag for each ticket
  • You are seeing a lot of tickets with NO_TAG and need to diagnose why
  • You are modeling content and want to make sure it gets tagged correctly

Prerequisites

  • Access to the project's ClaudIA Panel
  • Basic knowledge of the content types (N1, N2, Interactive)

About this article

The Tagger is the mechanism responsible for selecting and assigning the final tag of each ticket. This article explains how it decides which tag to apply and why tickets can end up with NO_TAG.

How the Tagger decides the tag

The Tagger is based on an advanced detection mechanism for the content ClaudIA used during the conversation. From that detection, it follows these steps:

Step 1 — Sort content by relevance

The AI evaluates all the content used and identifies which one represents the main subject of the conversation.

Step 2 — Apply the tag by hierarchy

The Tagger chooses the tag following a priority order. It applies the first available option, from top to bottom:

  1. N2 content (escalation) → if the ticket used N2 content, its tag has top priority

  2. Specialist agent tag → if the conversation was handled by the "Agentes Especialistas" (Specialist Agents) and a specialist agent set a tag, that tag is used next

  3. "Fluxo Controlado" (Controlled Flow, interactive content) → if the conversation triggered a Controlled Flow, the tag of that content is used

  4. Most relevant N1 content → in the absence of the previous ones, the tag of the N1 content with the highest relevance is applied

  5. Default tag → if nothing above applies, the ticket receives the project's default tag (which can be NO_TAG or another configured tag)

The order is always this one: N2 → specialist agent → Controlled Flow → N1 → default tag. The Tagger stops at the first option it finds.

🎥 Detailed explanatory video

Troubleshooting: why does a ticket get NO_TAG?

ClaudIA always tries to assign a tag. NO_TAG shows up when it cannot identify clear content to classify the ticket. This happens in two scenarios:

1. No content was used in the response

Common in short tickets or incomplete interactions:

  • The customer sent only a greeting or a generic message

  • ClaudIA replied without using structured content from the knowledge base

  • The conversation was abandoned before it developed

In this case, the outcome depends on the project's configuration:

  • With a default tag configured → the ticket receives the default tag (it can be NO_TAG or another tag defined by the project)

  • Without a default tag configured → ClaudIA still tries to guess: it summarizes the conversation and looks for the most similar content in the knowledge base. It only ends up as NO_TAG if nothing relevant is found

2. The content used was filtered out by the configuration

Even when there is content, the ticket can end up as NO_TAG if the project's configuration filters the content types that are considered. For example: a project configured to consider only N2 content tags, but the conversation used only N1 content → since there is no N2, the ticket falls back to the default tag.

The default tag is configurable per project. By default it is NO_TAG, but the project can define another tag for these cases.

Features that commonly generate NO_TAG

These are common examples of responses without structured content — whether they turn into NO_TAG or not depends on the configuration explained above:

  • Clarification / Enlightenment — vague question; ClaudIA asks for clarification without using the retrieved content

  • Multiprompt — ClaudIA replies with custom prompts that do not use content

  • Out of Office N1 — an N2 section or a Controlled Flow would generate a transfer outside business hours, but with N1 closing active, the Tagger may disregard the section and apply NO_TAG

Notes