Claudia - Feature Requests

Current scenario Today, the Prompt Led Section allows you to include instructions between [] in the title of a content section, and these instructions act as contextual direction to the LLM (as documented in KB's public article Prompt Led Section). In scenarios where the instruction is a mandatory pre-validation - for example, “before guiding, validate the platform version with the client” - the AI probabilistically follows: in many cases it delivers the main guidance of the section before executing the validation described in square brackets. Observed Behavior AI identifies content that is semantically related to the customer's question. Prioritizes the main orientation of the section. Treat instructions between [] as contextual/behavioral targeting. In some scenarios, it uses the content before performing the validation/guidance described between [] . Prior validation does not work as a mandatory step before the response. Order Evolution of the Prompt Led Section to support mandatory precondition — a deterministic gate before using the section. Implementation suggestion: a dedicated “Pre-validation” field in the section, separated from the body of the guidance, with locking semantics — the AI cannot deliver the guidance without first executing (and confirming with the client, where applicable) the step described in the pre-validation. Motivation Content with critical prerequisites (platform version, customer profile, contract status, funnel stage) today depends on a natural language instruction between [] that the model may or may not respect. A deterministic gate would provide predictable control in scenarios where order matters (validate → orient), reduce the chance of inadequate guidance due to lack of context, and reduce rework/escalation caused by responses delivered without prior validation. Typical Use Case A section with the following instruction in square brackets: > [If you use this content, validate with the client what version of the platform is and use it only if it is NEW. If the version has already been identified before in the service, do not repeat the validation and continue to consider this information throughout the interaction. ] It should become a mandatory pre-validation configurable in the section - not a contextual orientation that the model follows in a probabilistic way. Expected Result Pre-validation takes place before orientation, in a guaranteed manner. When the information is already in the history/context, the gate considers the validation completed and proceeds to the orientation. The operation can design content flows with dependent steps without requiring increasingly imperative prompts to try to force order.

Today CLAudia is already able to interpret photos, audios and PDFs, but she is unable to do that. The only thing it can do is send links. The idea is that we allow CLAudia to also send files (for when a specific IDS session is used). This one will still depend on technical refinement. It is possible that it will only be able to be sent to that call chat. This will depend on the technical possibility of the API of the helpdesks with whom we integrate so that this can happen.

Requested by TecnoSpeed ( rodrigo.ramalho@tecnospeed.com.br ). Context: today CLAudia's content is created and edited exclusively through the Hub interface. For clients who maintain a large knowledge base and/or already managed in another system (CMS, spreadsheet, internal database), this generates rework - any change must be replicated manually in the Hub. Request: provide API endpoints to create and edit CLAudia content on the Hub, allowing the customer to: Create new content via API (title, body, triggers/keywords, settings) Edit existing content via API Ideally, activate/deactivate content via API Benefit: allow integration of CLAudia's knowledge base with the client's external systems (e.g., CMS, own database), ensuring automatic synchronization and eliminating manual maintenance rework on the Hub.

Today it is possible to register special dates (e.g. holidays) and the message of those dates is customizable, but it is a single and standard message for all. It would be useful to be able to configure a different message for a special date - for example, to leave a registered Merry Christmas message for December 25 and a Happy New Year message for December 31, without having to manually edit the message on the day and return to the default later. Since there is already a TIME exception for a special date, it would make sense to have a MESSAGE exception also, linked to the same date.

Today, in the CLAudia Agência multi-agent setup, each sub-agent loads its own instruction block (system prompt) completely independently. The supervisor has his own rules, but they are not propagated to the sub-agents — when the supervisor calls an expert, he sends only the client's question, and the specialist answers based solely on the client's prompt. Recurrent scenario in onboarding and post-launch adjustments: Customer wants to add a global behavior rule (“never answer X”, “if you don't know the answer, transfer it to a human with full context”, “always return in tone Y”) that must apply to ALL sub-agents. Today the only option is to edit agent by agent, manually copying the same instruction to each one. In supervisors with 5, 10, 20+ specialists, this is time-consuming, error-prone, and creates divergence between agents (someone forgets to update one). Adding the rule to the supervisor's description doesn't work, because that description is only for routing - it doesn't reach the sub-agents. Request: allow defining, at the supervisor level (or in an equivalent field above the sub-agents), a set of global instructions that are automatically injected/inherited by the system prompt of each linked sub-agent. Possible formats: “Global Rules” field in the supervisor, whose content is prepended/appended to the system prompt of each sub-agent at run time. Reusable prompt templates (a section can be referenced by multiple agents). “Apply to all” tool in the agent editor, which updates the settings of the selected sub-agents in batches. Motivation: reduce maintenance friction, ensure consistency of behavior among all specialists, and accelerate the iteration cycle when rules need to be revised after observing behavior in production.

Currently, the AI terminates the ticket abruptly when activating the N2 transfer trigger. In my scenario, we don't attend the weekend. In these cases, the AI must not transfer or close the ticket abruptly in the customer's face, after sending the message that it is going to transfer. The suggestion would be to block the N2 triggers during off-office hours and not send the transfer message, inserting a message at the beginning of the conversation or only when the customer requests a transfer, preventing escalation. Note: This is the biggest offender in our CSAT. 14%

When the AI needs to forward a complex case on the chat channel, the customer generally leaves the conversation before being answered by a human — the chat has a short window of activity and is not persistent. The request is for clickable buttons on the chat widget that allow the customer to choose to continue the service via WhatsApp or Email. Upon clicking, the customer would already be directed with the summary/context of the conversation with the AI: On WhatsApp: it would arrive directly for continuity with human In the Email: it would open a pre-filled message with the main information of the negotiation The objective is to reduce abandonment in the chat channel and eliminate the feeling of restarting service when being referred to another channel.

Have reports/dashs with customer satisfaction linked to the reason for contact (tag)

Possibility to create a tag segmentation, for mass alteration based on the categorization of the content. The idea is that the tag is composed of “standardized” parts, editable in bulk. Ex.: category “Product 1" with the tag" produto1.cadastro.novo "renamed to “Product 2" - the renaming should occur only in the part that refers to the product (” produto2.cadastro.novo “). Today, since the tag is unique, changing multiple tags is time-consuming. --- Consolidated from the post “Content Categorization” : Creation of a category/segmentation of subjects for subsequent selection, allowing mass editing by topic.

When the ticket must be transferred to N2 but is retained on N1 due to OOO, the input tag is that of OOO. This change would allow us to keep the record, which is OOO, but to keep the original content tag on the ticket.