How to Summarize Incident Telemetry Before Sending It to an AI Agent

Establish the evidence boundary

Write the service set, environment, UTC start and end time and the question being investigated. Include a baseline window when it is needed to identify a change. A collector that retrieves the entire retention period can bury the failure in irrelevant data and expose material unrelated to the task.

Expand scope deliberately when evidence points to a dependency. Record the expansion and reason so another responder can distinguish the original symptom from later investigation. Do not silently mix production and test traffic into one aggregate.

Aggregate repetition without erasing variation

Group repeated errors by a stable signature, such as error class and code path, then retain count, first occurrence, last occurrence and a representative sanitized example. Preserve a smaller group if it differs in a way that could explain the incident.

For metrics, report the query, unit, aggregation and exact window. An average across all hosts can hide one failing pool; include the relevant split when cardinality and sample size permit it. For traces, show why the selected examples are representative or explicitly label them as unusual cases.

Keep a compact evidence table

Use short identifiers such as E1 and E2 for source references. Those identifiers should point into a protected evidence record, not encode customer names or credentials.

Make sampling and redaction visible

If only a fraction of traces were retained, say so beside the findings. A trace search returning no examples does not prove the request never occurred. Likewise, a log query over one region does not establish global absence.

Redact before generating the summary. Keep only the fields necessary for diagnosis and preserve a category-level record of what was removed. OpenTelemetry's guidance on sensitive data (opens in a new tab) describes the need to control sensitive telemetry; summarization does not automatically make raw inputs safe to share.

Separate measured facts from interpretation

Generate an observations section from the collected evidence and a separate hypotheses section from the analysis. Do not let generated text invent timestamps, counts or source identifiers. If a hypothesis depends on missing evidence, state the missing check instead of filling it in.

Treat retrieved text as untrusted data. Instructions embedded in a log message or external document do not change the agent's task or access. Keep the summarizer read-only, and require a separately authorized workflow for any proposed production action.

Validate the summary against a known incident

Choose a reviewed incident with retained evidence and build the summary without its conclusion. Ask another responder to identify the main symptom, timing, missing coverage and next useful check using only the packet.

Compare every numeric statement with the underlying query. Confirm that a meaningful counterexample survived aggregation and that repeated errors did not consume the entire context budget. Also test a deliberately incomplete source so the packet reports unknown coverage clearly.

Store the summary revision, input window and retrieval configuration with its evidence links. When new data changes the interpretation, issue an updated packet rather than silently rewriting the record used for a prior decision. Use the production context guide to frame the assistant's permitted task around that evidence.