Deep Research

Deep Research doesn’t search your logs. It investigates them. Ask a question in plain English, and the agent works through it in the steps below. The output is a citation-backed report with root cause, evidence, and actionable recommendations.

Before you start: make sure your file is in an accepted format. See Supported file types.

Watch a real investigation

What Deep Research does

Deep Research works through a problem in steps:

• Hypothesis-driven planning: breaks your question down, forms theories, tests them with multi-step searches, and pivots when a lead is a dead end.
• Parallel agents: pursue different angles of your question at once, each chasing its own hypothesis, consolidated into one report.
• Cross-layer correlation: traces causal chains across kernel, framework, drivers, and app layers.
• External lookups: CVE entries, vendor documentation, and other references when relevant.
• Citation-backed reports: every claim links to the log line or reference behind it, and on supported platforms to the line of platform source that emitted the log line. See Source-grounded findings.
• Multi-source scope: bugreport sections, logcat, dmesg, and telecom or automotive logs in one investigation.

Deep Research vs Quick Search

Running an investigation

1. Upload a log file at console.logcat.ai: bugreport zip, logcat, or dmesg. Wait for analysis to finish.
2. Open the Research tab from the left navigation.
3. Switch to Deep Research using the mode toggle at the top of the search input.
4. Type your question in plain English.
5. Watch the investigation unfold: the agent streams its plan and each step as it runs.
6. Review the report.

Writing good prompts

Grounded prompts produce better reports. Anchor your question to a symptom, subsystem, or time window:

• “Why did this device reboot during video playback?”: a symptom anchored to its trigger.
• “Find the root cause of battery drain”: open-ended but grounded; the agent tests hypotheses such as wakelocks, runaway services and modem activity.
• “Why did com.example.app keep getting killed after 14:30?”: one app, one time window.

Less effective prompts:

• “What’s wrong?”: too broad, no anchor.
• “Fix this bug.”: too vague to investigate. Ask why the bug happens: a candidate fix follows once the investigation has found and read the code responsible.

Reading the report

A completed investigation opens on its verdict and reads down from there:

• Verdict: one sentence that answers your question, with its outcome and a confidence beside it, the direct answer under it and up to three key figures. The confidence is read from the findings the verdict rests on, and a finding or figure whose citations point to nothing the investigation read is marked low. When no test told the cause apart from the others or confirmed it, the confidence reads medium at most, or low when a test’s result went against it, with the reason beside it. In a comparison, the captures compared sit at the top with their type and device, and the figures are paired across captures.
• Location: once established, a line under the verdict and each finding names where the failure sits, each name labelled with its level: file (one you uploaded), package, process, component, source file, function, event, or a configuration file, section and setting. A finding’s location names only what its cited lines show; the verdict’s names every level the investigation concluded, marking one the capture does not print as placed by the investigation. Code that only printed the record read is named apart, under Reported at. A process carries the name and number the capture’s own process records give it. A stack trace’s class fills or narrows the component. A kernel cause’s component is its subsystem, with its function apart; a hardware fault’s is the device its error lines name.
• Outcome: Cause found names the kind of fault, such as a deadlock, with a causal chain from the symptom you saw to the root, each step with its kind of fault, location and sources. Ranked causes lists the causes the report weighs. Not determinable from this capture means your capture does not record the cause of the behavior you asked about; the report lists leads, each with what it rests on and what would settle it. No fault found means nothing failed, or an event you asked about is not recorded in a window your capture covers in full; the report names no leading hypothesis and shows the term it searched for and where: a file of a several-file capture, a time window, or a whole one-file capture, with its sources. If the behavior you asked about is expected, the verdict says so. A verdict that commits further than the investigation could establish is shown at low confidence.
• Your questions: each further question sent with the investigation, as you wrote it, with its answer, its sources and how the value is known: printed in the capture, computed from cited lines, or stated by the investigation. A question the capture cannot answer reads as not determined, and one that does not apply says so.
• Findings only: when the report cannot be written, you get the findings the investigation established instead of a failed investigation, with no verdict or direct answer: where the verdict would be, the report says it has findings but no conclusion. See Investigation units for how it is charged.
• A report cut short: when the report grows too long to finish after its verdict and direct answer are complete, it keeps both beside the findings the investigation established.
• Findings: ranked by impact, each with a severity, its kind of fault where one was named, the evidence it rests on and the sources it cites. A finding the verdict rests on is marked as supporting it. Open a finding for its analysis and the excerpts read from the capture. In a comparison, a finding names the captures it rests on.
• Evidence stops, next steps and the leading hypothesis: the parts of your captures holding lines at error level or above that the investigation did not read, and any capture it read nothing from, taken from its own record of what it read; facts about the capture that limit the answer; what to do next; and the explanation the evidence supports, or the leads, each with what would disprove it. When the report states several hypotheses, they are listed together: the one stating the verdict’s cause first, then the others ranked among themselves by the evidence for each, with ties marked and whether the tests left each one standing, ruled it out or never reached it; the verdict above them stays the report’s answer.
• Proposed fix: on supported platforms, when the investigation read the platform code behind a finding, the report includes a candidate change written against that code, with what it changes and any upstream change that already fixes the problem. It appears only when real source was read, never as a guess. See Candidate fixes.
• Device and networks: the device and build the capture states and, from a SIM’s or modem’s records, its home and serving networks with their carriers, per SIM slot.
• An OS version stated for a capture: named in the report’s context as yours or as the capture owner’s, with what its source was matched on. See An OS version you state.
• Web research: whether the investigation or the report’s claims check searched the web, and the web pages cited.
• Technical details: stack traces, long tables and other raw material the findings rest on, collected at the end and linked from the finding that uses it.
• Sources: every citation the report makes, numbered. Hover a source to read the passage it was taken from. Where the exact line quoted is known, the source names its file and line with the line beneath, and opening it jumps to that line; any other source opens at its passage. A figure the investigation computed cites its own source: hover it for what it measures and the sources it was computed from. It is shown as computed, and a claim resting on one is at medium confidence at most. In a comparison, sources are grouped by capture.
• How it got here: every step the agent ran, for auditing the reasoning.
• Follow-ups: ask deeper questions from the panel beside the report; each answer cites into the same sources list and builds on what the investigation already found.
• The panel: hide the sources and steps for a full-width report; the same button, or opening any source, brings them back.
• Feedback: thumbs-up or thumbs-down on the report and on each follow-up answer.

Sharing and history

• Share: a public link lets teammates view the full investigation, including citations, without an account (not for a decoded vehicle bus trace).
• Export: download a PDF for incident write-ups or tickets.
• History: past Deep Research runs are saved per file, and the Research tab filters Deep Research from Quick Search history, so you can revisit an investigation without re-running it.