AI Packet Investigation Agent · PacketSafari PacketSafari Agent · Autonomous packet investigation From question to defensible RCA. Give Agent a capture and the problem you need to explain. It returns labelled preliminary direction, tests the conclusion independently, and keeps every material claim tied to packet evidence. See a real investigationEvaluate with your capture Packet-grounded direction in minutes on qualified cases. Preliminary and verification outcomes remain separate milestones. Capture accepted: from packet upload to a Preliminary Report and Final Report 01CaptureAccepted 02RCA engineInvestigating 03Preliminary ReportReady 04Final ReportReady RCA engine · evidence passComparing the success path with the resets Investigating Successful baselineFRAME 29 · SUCCESSFUL CLIENT HELLOFRAME 31 · SERVER HELLO Affected attemptFRAME 56 · SNI CLIENT HELLOFRAME 57 · IMMEDIATE RST/ACK Candidate emergingReset occurs immediately after ClientHello12 matching attempts grouped for verification Preliminary ReportVerification continues → Root-cause direction readyImmediate reset after ClientHello Immediate TCP resets after ClientHello are the strongest supported cause—not packet loss. Affected sequence Frames 56–57 · representative ClientHello → RST/ACK Repeated pattern Frames 56–92, 174–190 · 12 affected attempts Successful baseline Frames 29, 31, 97, 115 · successful TLS baselines Frames 56–57 support the lead Packet loss rejected Verification completeFinal Report Verified conclusionClientHello-to-reset sequence verified across 12 attempts The preliminary finding is verified across the capture. The reset origin remains open because the packets cannot identify the responsible device or policy. Verified ClientHello → immediate reset Ruled out Packet loss as primary cause Open question RST/ACK hop + matched rule Actionable next stepCheck the service path to 198.51.100.80:443 Target flow192.0.2.24 → 198.51.100.80:443 Compare each matched rule and log event with successful baseline frames 29–31; attach the hop name, rule ID, and log event that aligns with the RST/ACK. The capture is accepted, the root-cause engine compares successful and failed TLS sessions, a clearly labelled Preliminary Report identifies immediate resets after ClientHello, and a Final Report verifies that sequence across 12 attempts while recording the reset source as an explicit open question and recommending the evidence-linked next action: inspect firewall, load-balancer, TLS-inspection, and service logs for the sanitized endpoint aliases and exact frame windows, identify the reset-generating device and rule, and attach that log event to the report. Public investigation samplePreliminary → targeted outcome → comprehensive final Preliminary Direction quickly, explicitly labelled Independent verification Adopted, rebutted, or left inconclusive Evidence contract Frames · filters · streams · fields Three evidence milestones, one investigation Useful direction first. Targeted checks and capture-wide adjudication follow. Speed and confidence are different product events. Agent preserves the Preliminary Report, Verification, and Final Report, so an early answer never hides what has—or has not—been tested. 01 Capture accepted The capture is admitted and made safe to inspect. 02 Preliminary evidence PacketSafari Core Engine surfaces the strongest current signals. 03 Candidate RCA Agent forms an explanation that cites those signals. 04 Independent verification A later pass adopts, rebuts, or leaves candidates inconclusive. 05 Defensible report The report preserves the result, uncertainty, and exact pivots. Compare Fast answer, Fast + verification, and Triage then report Preliminary direction Immediate TCP resets after ClientHello are the strongest supported cause—not packet loss. A strong current explanation—not a relabelled final report. Verified finding Verified finding: 12 attempts show the same ClientHello-to-RST sequence. The reset source remains an explicit open attribution question. Inspect the complete report Bounded evidence architecture The model never has to swallow the capture. From routine captures to multi-gigabyte investigations, PacketSafari sizes the processing and evidence workflow to the deployment rather than flattening the PCAP into an AI prompt. Large-capture capacity is deployment-defined and validated against the customer’s real capture profile. 01 · CAPTUREPCAP / PCAPNGDurable intake · capture ready derived facts 02 · CORE ENGINEPacketSafari Core EngineFrames · streams · fields bounded queries 03 · INVESTIGATIONAgent planHypotheses · correlation cited outcome 04 · HANDOFFDefensible reportEvidence · uncertainty · action PacketSafari Core Engine Decoded frames, fields, expert information, streams, and protocol statistics establish the facts. Bounded packet access Agent requests focused derived facts and packet pivots instead of treating the PCAP as model context. Large-capture workflow Durable intake, early capture readiness, deferred evidence work, cached artifacts, and memory controls keep work bounded. Reviewable report Findings preserve evidence, alternatives, uncertainty, and the next action another expert can inspect. Private AI and deployment Your packet boundary stays yours. Connect PacketSafari to customer-operated AI endpoints while packet storage, identity, model routing, and egress remain under customer control. Model compatibility, evidence quality, latency, and capacity are validated during deployment. Customer-controlled boundaryEgress / policy: enforced 01 / StoragePacket captureCustomer profile Bounded intake 02 / Protocol truthPacketSafari Core EngineFrames · streams · fields Approved route 03 / InferencePrivate AICustomer endpoint Identity / organizationExplicit egressBounded evidence only