# Agentic Debugging Source: https://docs.drdroid.io/agent/agentic-debugging Agentic Debugging allows you to delegate debugging tasks to an AI agent that uses contextual data, integrated tools, and reasoning to analyze system symptoms, identify likely root causes and recommend next steps for remediation. ## 🛠️ How It Works DroidAgent collects evidence from your system and correlates them to come up with the likely root cause behind the issue and how it can be fixed. Here's how it works: 1. Collects Context: The agent collects context across multiple places, including but not limited to: * Data Sources: Give the platform access to your telemetry data sources & map them to your services so it knows where to query metrics, logs, deployments or any other information for which service. * Alerts: Access to alerts enables agent to decide when to investigate. * Runbooks: Provide an additional set of prompts / wiki so that the agent can leverage it during investigations. Runbooks are not required for standard/common scenarios but only for situations where user already has an opinion. 2. Correlates & iterates: * After every evidence collected, it tries to connect it back to the hypothesis it created and evaluates if it's getting any closer to the issue resolution or root cause identification. Note: Data Sources are the core essentials so we would recommend not skipping them. With no integrations, the agent will provide general debugging guidance—questions to ask, commands to run, and logs to inspect manually. ## Data Sources & Integrations Our platform supports integration with 50+ tools for evidence collection & investigation -- from your logs in ELK to dashboards in Grafana. You can find the full list [here](/integrations/integrations). Each data source is converted into an MCP server and made accessible to the agent for leveraging during investigation. ## 📋 Example For example, if a Kubernetes pod is CrashLooping, and you have observability integrations configured: * The agent may fetch pod logs, check deployment configurations, and diagnose the root cause (e.g., OOMKill, bad image). * Basis the pod's name, it might also look for a service of similar name, and once it finds it, it can decide to further investigate data sources of the service (like the dashboards & metrics associated with the service or the deployments history). # Alert Details Source: https://docs.drdroid.io/agent/alert-details The Alert Details Page is accessed when a user clicks on a specific alert from the Alert Inbox. This page provides a consolidated view of the alert, with options to investigate, reinvestigate, and analyze detailed diagnostic data. ## 🔍 What You Can Do on This Page ### 1. View Investigation Summary * At the top of the page, users see the results of the most recent investigation. * This includes: * Tasks that were automatically or manually performed. * Agent insights and hypotheses. * Key metrics or logs analyzed during the process. ### 2. Reinvestigate (Start Over with Better Context) * If the user finds the investigation insufficient or inaccurate, they can trigger a Reinvestigation. * **Reinvestigation**: * Re-runs the analysis using the same or improved alert data. * Users are encouraged to add relevant integrations (e.g., logs, metrics, infra APIs) to enrich context and improve results. * Can incorporate updated signals or environment state. > 💡 **Tip**: Reinvestigation is most powerful when paired with comprehensive integration coverage. ### 3. Continue Investigation (Pick Up from Previous Steps) * Users can choose to Continue Investigation if the existing investigation has helpful partial context. * **Continuing** allows: * Extending the diagnostic trail from the last agent action. * Adding custom tasks or questions for deeper insights. * Exploring the reasoning chain of the agent so far. ### 4. Task Execution View * Each investigation consists of **Tasks** — discrete debugging or remediation steps (e.g., querying logs, checking CPU load). * For each task, users can view: * Command/query executed. * Source of data (integration used). * Agent-generated interpretation or anomaly detection. * Tasks are grouped and timestamped, helping users track progress. ### 5. Data & Visualization Panels * Investigation tasks often return structured data (tables, charts, timelines). * Users can interact with this data directly in the Alert Details Page: * View logs, metrics, infra states. * Expand/inspect anomalies. * Correlate multiple datasets for better root cause understanding. *** ## 🧠 Behind the Scenes * All investigations (initial, continued, or reinvestigations) are driven by DrDroid's agentic reasoning engine. * The agent uses context from the alert metadata (e.g., datasource, affected service, triggering channel) to form hypotheses and take diagnostic steps. * Users can provide feedback to improve agent understanding and future investigations. # Common FAQs Source: https://docs.drdroid.io/agent/common-faqs Frequently asked questions about DroidAgent and its capabilities This page contains frequently asked questions about DroidAgent and its capabilities. Find answers to common queries about investigations, security, and workflow integration. ## How DroidAgent Works DroidAgent builds company-level intelligence by gathering context from multiple sources during investigations: DroidAgent Architecture - How it builds company-level intelligence during investigations The agent combines real-time context (alerts, issues, ongoing investigations), integration-level context from tools like Coralogix, Grafana, and Kubernetes, plus uploaded documents and runbooks to conduct thorough investigations. ## Investigations DroidAgent has been given context of patterns in your logs. Along with that, it leverages the information of ongoing alerts, any runbooks or documents and its innate knowledge of error debugging and monitoring to try different queries. It can try multiple different queries in case it doesn't find success with one of them. Based on the alert, it creates a plan of potential root causes and tries to find evidence to validate/disvalidate each hypothesis. To create the plan, it uses a combination of real-time context (what alerts are going on), what dashboards/integrations exist in context of that alert/service and what documents are accessible. The agent is using SOTA models with deep understanding of modern day cloud, infrastructure, engineering design principles and SRE practices. Using the combination of this knowledge, and the custom context provided to it, it's able to decide the commands to run on a cluster. The agent has been trained to understand the relevance of different time windows in context of an alert (e.g. it can decide to get metrics for a timewindow just before the alert, or for the same timewindow in a previous day/week setup or at the current time to check if the issue is still ongoing). It prioritizes alert\_time when it finds context in some document or alert itself. ## Data & Agent Security DroidAgent implements multiple layers of security to protect your data and infrastructure: Agent & Data Security - Security layers and data protection mechanisms The architecture shows how the Agent Engine and Execution Engine work together with safety checks, RBAC, PII scrubbing, and secure key management. No. For all the integrations, the agent does not have access to keys -- it only has access to request specific API executions and the execution engine stores the keys securely in a database. Additionally, there are guardrails in place to avoid agent from running unauthorised state-change or critical commands. The agent does NOT have access to execute write commands by default. It can be given the access to execute commands with appropriate roll-backs and permissions in place. This can be done run-time or pre-configured based on specific situations as per the team's context. DroidAgent implements multiple layers of security including RBAC and access management, PII scrubbing, safety checks, and built-in guardrails to prevent unauthorized operations. The execution engine can be deployed within your VPC for additional security. ## Workflow Integration DroidAgent seamlessly integrates into your existing workflows without requiring changes to your current setup: Works in your workflows - No changes required to existing tools Key benefits include no metrics or logging tool changes, auto-sync with ticketing and on-call tools, RBAC integration, and lightweight configuration. No metrics or logging tool changes required. DroidAgent auto-syncs with your ticketing and on-call tools, has RBAC and access management integration, and is lightweight and quick to configure. DroidAgent integrates with Grafana, Coralogix, New Relic, Datadog, PagerDuty, Opsgenie, Slack, Jira, Kubernetes, cloud platforms (AWS, Azure, GCP), and databases. DroidAgent is lightweight and quick to configure. It works with your existing monitoring infrastructure, auto-discovers your tools, and doesn't require downtime during installation. You can upload custom runbooks, configure specific integrations, customize alert routing, and define investigation scope and permissions. # Product Updates Source: https://docs.drdroid.io/changelog New updates and improvements ## Enhanced Alert Investigation Panel ### 🧠 Hypothesis Visibility: Get instant visibility into the potential root cause hypotheses auto-generated by the DrDroid AI Agent for any alert — right in the expanded side panel. ### 🔍 Tool Usage Transparency: Whenever DrDroid accesses your integrated tools (e.g., Datadog, Prometheus) for data validation, it's now clearly displayed to you along with the relevant steps performed. ## Context Engine: * Service Catalog Auto-Mapping: Automatically pulls data from APMs, Kubernetes clusters, and CI/CD pipelines to build your service inventory. * Infrastructure Catalog Integration: Syncs with your cloud provider to generate a real-time infrastructure map. * Tooling Detection: Infers observability and alerting tools from incoming alert streams — no manual config required.