> ## Documentation Index > Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt > Use this file to discover all available pages before exploring further. # Deploy & monitor > Deploy AI agents to Slack channels, test them in a sandboxed Testing Mode, then monitor conversations, results, and feedback to improve responses. Deploy agents to channels and monitor their performance through conversation logs, result categorization, and feedback tracking. Before going live, validate rules, tools, and forms in **Testing Mode** — a sandboxed chat that runs the agent end-to-end without writing tickets, sending messages, or triggering workflows. *** ## Testing Mode V3+ Testing Mode is a sandboxed chat panel for trying your agent without touching production data. The agent runs end-to-end — matching rules, calling tools, and choosing responses — but any action that would write or change something is simulated. No tickets are created, no messages are sent to Slack or Teams, and no workflows fire. Use Testing Mode to: * Validate a new rule before exposing it to real users. * Check that the right form is presented for a given request. * Confirm knowledge sources are being cited correctly. * Inspect which tools the agent called and what it passed to them. ### Open Testing Mode Navigate to **Agents** in the sidebar and select the agent you want to test. Use the chat panel on the agent page. A yellow **Testing Mode** banner confirms the session is sandboxed. Type a request a real user might send, then submit. The agent responds with the same rules, tools, and knowledge it would use in production. ### Forms and submissions When the agent presents a form, fill it out and submit it from within the chat. The values flow back to the agent so it can continue the turn, just like in production. Form submissions and ticket publishes appear as inline cards so you can verify what would have been created. After a terminal action (publishing a ticket or submitting a form), the session is frozen to mirror real-world behavior. Click **Start new chat** to reset and continue testing. ### Debug each turn Every agent response includes a collapsible **Debug** disclosure below the message. Expand it to inspect: * **Matched rules** — which rules fired for the turn and the reasoning behind the match. * **Tool calls** — every tool the agent invoked, with the input it sent and the output it received. * **Response type** — the classification the agent chose (KB answer, Chat, Asked for info, or Escalated). Use the debug view to diagnose unexpected behavior — for example, the wrong rule matching, a tool being called with bad inputs, or the agent escalating when it had enough knowledge to answer. Testing Mode sessions are client-owned and not saved to **Chat Logs**. To capture a regression for later review, copy the relevant inputs and outputs from the Debug disclosure before resetting the session. *** ## Connections Select which channels the agent should be deployed to. You can add or remove channels at any time after deployment. ### Deploy agents Open your agent's settings page. Locate the **Connections** section. Click **Add Channel** and select the channels where the agent should be active. Save your connection settings to deploy the agent. Agents can be deployed to multiple channels simultaneously. Each channel operates independently with the same agent configuration. Learn about [setting up and managing channels](/documentation/tickets/channels) *** ## Chat logs All interactions between users and the agent are logged and can be reviewed in the Chat Logs section. Monitor agent performance, review conversations, identify knowledge gaps, and track response quality. ### View conversations Access all conversations your agent participates in from the **Chat Logs** tab on the agent's page. Each conversation shows: * **Timestamp**: When the conversation started * **Requester**: User who initiated the conversation * **Channel**: Where the conversation took place * **Agent result**: How the agent categorized the conversation outcome * **Message count**: Number of messages exchanged * **Feedback**: Thumbs up or down reactions received ### Agent results Agent results categorize how the agent ended each conversation. This helps you understand agent behavior patterns and identify areas for improvement. The agent successfully answered the user's question using knowledge base articles or direct information. This indicates the agent found relevant documentation and provided a complete answer. The agent asked the user for clarification or additional information. This occurs when the initial request lacks sufficient detail for the agent to proceed. The agent created a ticket for the request. This happens when the agent escalates to human assistance or when the request requires a structured form submission. The agent provided help or guidance information. This typically occurs when users ask about the agent's capabilities or how to use the system. The agent could not find relevant information to answer the question. This indicates a potential knowledge gap in your documentation or a request outside the agent's scope. The agent engaged in conversational interaction without a specific categorizable outcome. This includes general conversation or exploratory questions. The agent initiated a form-based request process. This occurs when a rule or escalation instruction explicitly directs the agent to show a form. Forms are only shown when rules specifically require them, not based on the agent's judgment about structured information needs. The agent prompted the user to fill in a specific field on a form. This occurs while the agent is collecting structured information one field at a time during a form-based request. The agent triggered a workflow. This happens when the agent executes an automated process based on the conversation context. The agent detected sensitive information (passwords, API keys, tokens, or credentials) in its response and delivered it as a private DM to the requester instead of in the shared channel. Other participants see a placeholder message indicating a private message was sent. V3+ The agent encountered an error during processing. This indicates a technical issue that prevented the agent from completing its response. The agent created a custom ticket type. This occurs when the agent uses a specialized form or ticket template. The conversation was not published or remained in draft state. This typically happens when the agent prepared a response but it was not sent. ### Feedback tracking Track user reactions to agent responses through thumbs up and thumbs down feedback. This data helps identify knowledge gaps and improve agent effectiveness. **View feedback summary:** * Total positive reactions * Total negative reactions * Feedback rate (percentage of responses receiving feedback) * Trending issues (frequent negative feedback patterns) **Filter by feedback:** * View all conversations with positive feedback * View all conversations with negative feedback * View conversations without feedback When **Create ticket on negative feedback** is enabled in agent settings, thumbs down reactions automatically create support tickets for human follow-up. ### Filter chat logs Use the **Filters** button above the chat log list to narrow down conversations. Filters use AND logic, so a conversation must match every active filter to appear. Filter by the result type the agent returned, such as Answered, Clarification, Ticket Created, Missing Knowledge, or Error. Use this to isolate conversations by outcome — for example, view every "Missing Knowledge" result to find knowledge gaps, or every "Error" result to investigate technical issues. Filter conversations by the properties of the ticket the conversation produced. The **Tickets** folder groups all ticket-level filters in one place. Available filters include: * **Title** — filter by keywords in the ticket title * **Description** — filter by keywords in the ticket description * **Status** — filter by ticket status (open, in progress, resolved, closed, or any custom status) * **Priority** — filter by ticket priority * **Assignee**, **Requester**, **Followers** — filter by people on the ticket * **Channel** — filter by the channel the ticket lives in * **Form** — filter by the form used to create the ticket * **Tags**, **Category**, **Ticket Type** — filter by ticket organization attributes * **Custom fields** — filter by any custom field defined on your forms * **Created at**, **Updated at**, **Due date** — filter by date ranges The **Title** and **Description** filters perform substring matches against the ticket's title and description text. Use them to locate conversations tied to tickets about a specific topic — for example, every chat log that produced a ticket with "VPN" in the title. Combine filters to investigate specific patterns. For example: * **Find unresolved escalations**: filter by **Agent Response** = `Ticket Created` and **Tickets → Status** = `open` to surface every escalated ticket still waiting for a human. * **Audit a single team's load**: filter by **Tickets → Channel** = `IT` to see only chat logs that produced tickets in the IT channel. * **Investigate a custom workflow**: filter by **Tickets → Form** = `Access Request` to review every conversation that created an access request. * **Search by topic**: filter by **Tickets → Title** contains `password reset` to find every chat log whose ticket title mentions password resets, or use **Tickets → Description** to match keywords inside the ticket body. Ticket filters apply only to conversations that produced a ticket. Conversations the agent answered directly from the knowledge base will not appear when a ticket-level filter is active. To review knowledge-only conversations, filter by **Agent Response** = `Answered` instead. ### Explain a conversation with Copilot Use **Explain** to ask Copilot why the agent answered, asked, or escalated the way it did. Copilot inspects the run evidence — the response classification, the matched rule and its reasoning, the tools the agent called, the agent's configuration, and any cited documents — and gives a grounded explanation rather than a guess. **Open Explain in two ways:** * **Explain the whole conversation**: open a chat log and select the **Explain** button at the top of the panel. Copilot walks through every turn and the overall outcome. * **Explain a single response**: hover an agent reply in the chat log and select **Explain** on that message. Copilot scopes the explanation to just that turn. **What Copilot covers on the first reply:** * **Outcome** — the overall classification and the single reason the conversation landed there. * **What happened, turn by turn** — one bullet per agent reply, with the classification and a short description of what the agent did. * **Verification** — for Missing Knowledge or escalations, Copilot re-runs a knowledge search to check whether the gap is a real content gap or a retrieval miss. It also notes when a matched rule narrowed the agent's knowledge lookup to specific documents or folders, which can make an escalation correct even though relevant content exists elsewhere. * **Takeaway** — what this means for you, such as whether the escalation was justified or whether a rule or knowledge gap may need attention. Follow-up questions stay conversational and answer only what you ask. Copilot reuses the run context it already loaded instead of restating the full breakdown. Explain is read-only — it analyzes and recommends, but it cannot edit agents, rules, or knowledge from inside the chat. When you ask Copilot to make a change (for example "update this rule" or "fix the escalation instructions"), it surfaces a one-click button that carries the conversation into the full Copilot panel, which has the tools to apply the change. ### Analyze conversations Use chat logs to: Review conversations with "Missing Knowledge" results to discover missing documentation. Add these topics to your knowledge base to improve future responses. Analyze conversations where the agent asked for clarification or created tickets unnecessarily. Update rules to handle these scenarios more effectively. Track how often the agent escalates to human assistance. High escalation rates may indicate unclear instructions or insufficient knowledge base coverage. Compare agent results over time to measure improvement. Track metrics like answer rate, escalation rate, and feedback trends. After updating agent configuration, rules, or knowledge base content, review chat logs to confirm improvements in agent responses. *** ## Best practices Check chat logs weekly to stay informed about agent performance and identify emerging issues early. Review negative feedback promptly to understand user frustrations and address gaps in agent capabilities or knowledge base content. Monitor agent result distribution over time. Sudden changes in result patterns may indicate issues with agent configuration, knowledge base updates, or changing user needs. Use chat log insights to continuously improve agent configuration, rules, escalation instructions, and knowledge base content. Establish target metrics for agent performance: * Minimum answer rate (percentage of "Answered" results) * Maximum escalation rate (percentage of "Ticket Created" results) * Target feedback rate (percentage of responses receiving feedback) * Minimum positive feedback ratio (positive reactions vs negative reactions) ## Deployment model Agents are deployed to channels. Key behaviors: * An agent can be deployed to multiple channels simultaneously. * Each channel can have at most one agent. * All channels sharing an agent use the same configuration (rules, knowledge, escalation instructions, personality). * Adding or removing channel connections takes effect immediately. *** ## Result type reference Every agent conversation is classified with a result type. These types indicate what the agent did and help diagnose performance issues. | Result type | What happened | Diagnostic signal | | ----------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Answered | Agent answered using knowledge base content | Successful resolution. High rate indicates good knowledge coverage. | | Clarification | Agent asked for clarification | May indicate vague user requests or rules that need more specific triggers. | | Ticket Created | Agent created a ticket or escalated | Expected for requests requiring human help. High rate may indicate knowledge gaps or overly aggressive escalation. | | Help | Agent explained its own capabilities | Users are unsure what the agent can do. Consider updating channel messaging or agent introduction. | | Missing Knowledge | Agent could not find relevant information | Knowledge gap. Add documentation covering this topic. | | Conversational | General conversation without a specific outcome | Casual interaction. Not necessarily a problem. | | Form Response | Agent presented a form based on a rule | Expected when rules direct form creation. | | Form Field | Agent prompted the user to fill a specific form field | Expected during multi-step form intake. | | Workflow Form | Agent triggered a workflow | Expected when rules trigger workflow execution. | | Sensitive | Agent detected and handled sensitive information | Security measure activated. Review to confirm correct detection. | | Error | Agent encountered a processing error | Technical issue. Investigate logs for root cause. | | Custom Ticket | Agent created a ticket with a specialized form | Expected for custom form workflows. | | Unpublished | Response was prepared but not sent | May indicate a system issue or interrupted conversation. | *** ## Feedback signals User feedback (thumbs up/down) provides direct signal about response quality: * **Positive feedback** indicates the response was helpful and accurate. * **Negative feedback** indicates a problem. Common causes: incorrect information, missing information, wrong form selected, unhelpful response, or the agent should have escalated instead. When "Create ticket on negative feedback" is enabled (default), negative reactions automatically generate a support ticket for human review. This creates a built-in feedback loop. **Feedback rate** (percentage of responses receiving any feedback) indicates user engagement. Very low feedback rates may mean users are not aware of the feedback mechanism or do not find it convenient. *** ## Debugging patterns ### High "Missing Knowledge" rate The agent frequently cannot find relevant information. * **Likely cause:** Knowledge base gaps. The topics users ask about are not covered in connected knowledge folders. * **Fix:** Review "Missing Knowledge" conversations to identify missing topics. Add documentation to the knowledge base. Verify the correct knowledge folders are connected to the agent. ### High escalation rate The agent creates tickets or escalates to humans more often than expected. * **Likely causes:** Escalation instructions are too aggressive, rules do not cover common scenarios, or knowledge base coverage is insufficient. * **Fix:** Review "Ticket Created" conversations. If the agent could have answered from knowledge, add or improve knowledge content. If the agent escalated due to unclear rules, refine rule trigger conditions. If escalation instructions tell the agent to escalate too eagerly, adjust the thresholds. ### Frequent "ask user" responses The agent asks for clarification too often. * **Likely cause:** Rules lack specificity, so the agent cannot determine intent from the initial message. Alternatively, users are sending very short or ambiguous requests. * **Fix:** Make rule trigger conditions more specific. Add examples of common phrasings to rules. Consider whether conversational form filling might help collect structured data. ### Negative feedback on knowledge answers Users give thumbs down on answers that cite knowledge base articles. * **Likely causes:** Knowledge base content is outdated, inaccurate, or insufficient. The agent may also be citing the wrong article. * **Fix:** Review the cited articles for accuracy. Update or remove outdated content. Check if the agent's knowledge folder connections are correct. ### Wrong form selected The agent presents the wrong form for a user's request. * **Likely cause:** Rule trigger conditions overlap, causing the agent to match the wrong rule. Or a rule's trigger condition is too broad. * **Fix:** Make trigger conditions more distinct across rules. Ensure each form-related rule has specific, non-overlapping trigger criteria. *** ## Upgrade an agent Agents are versioned. When a newer agent version is available, the **Upgrade** action appears on each agent that's still on an older version — both in the agents list (row actions) and in the header of the agent's settings page. Upgrading creates a **new, upgraded copy** of the agent. The new copy is not connected to any channels or queues, so it doesn't respond anywhere until you connect it. Your current agent keeps running unchanged, which lets you review and test the upgrade before switching traffic over. ### When to upgrade * A newer agent version unlocks behavior or capabilities the older version doesn't support. * You want to consolidate on the current runtime so future improvements apply to your agent. * You'd like to retire an older agent but want to validate the upgraded copy in parallel first. ### Run the upgrade From the **Agents** list, open the row actions menu on an eligible agent and select **Upgrade**. You can also open the agent's settings page and click **Upgrade** in the header. The modal prefills a suggested name (the original name with an "Upgraded" suffix). Edit it if you'd like a different name for the new copy. The **Rules** section lists every rule attached to the agent and how it will be carried over: * **Unchanged** — the same rule is re-attached to the upgraded agent. Edits to the rule continue to affect both agents. * **Migrated** — a new copy of the rule is created on the upgraded agent because it needs changes to work on the new version. The original rule stays as-is on the original agent. The **Tool changes** section lists tools that don't exist in the new version but have a known equivalent (or are safe to remove). These are handled for you. Rules affected by an automatic change are flagged for review on the upgraded agent. The **Choose replacements** section appears when one or more tools used by the agent aren't available in the new version and don't have a known equivalent. For each one, pick a replacement tool from the list or select **Remove (no replacement)** to drop it. You can't complete the upgrade until every unavailable tool has a decision. Click **Upgrade**. Ravenna creates the upgraded copy and opens it so you can review the configuration. Add the upgraded agent to the channels and queues you want it to handle, then remove those connections from the original agent when you're ready to cut over. Only one upgraded copy of a given agent can exist at a time. If an upgraded copy already exists, finish reviewing or delete it before starting another upgrade. *** ## Optimization recommendations * **Track result distribution weekly.** A sudden shift in result types (e.g., spike in "Missing Knowledge" or "Error") signals a configuration or content issue that needs investigation. * **Review negative feedback conversations first.** These are the highest-signal data points for improving agent quality. * **Use "Answered" rate as a primary metric.** This directly measures how often the agent successfully resolves requests without human intervention. * **Monitor escalation rate as a secondary metric.** Some escalation is expected and healthy. The goal is not zero escalation, but appropriate escalation. * **After making changes, compare before and after.** Check whether rule updates, knowledge additions, or escalation instruction changes actually improved the result distribution.