Common warning signs include unexplained latency, token spend that cannot be attributed to specific calls, rate limit errors that are hard to reproduce, and poor visibility into retrieval or tool behaviour. If teams cannot see the prompt, retrieved context, and response together, they usually lack enough telemetry to diagnose why an application is slow, expensive, or inconsistent.
When tracing is too thin to explain the model’s behaviour
If LLM tracing is under-instrumented, the first sign is usually that the team can describe symptoms but not the sequence that caused them. You may see slow or inconsistent responses, but still be unable to tell whether the delay came from prompt assembly, retrieval, tool execution, model latency, retries, or post-processing. That gap turns routine debugging into guesswork.
Another sign is that the trace records individual events but not enough context to reconstruct the call path. A useful trace should let you correlate the prompt, retrieved content, tool calls, response, and timing in one place; when those elements are fragmented, it becomes hard to explain variance or compare one run to another. For broader AI observability, the NIST AI Risk Management Framework and the NIST AI 600-1 Generative AI Profile both reinforce the need for traceability and measurable oversight of GenAI behaviour.
That same visibility problem shows up when teams cannot attribute cost to a specific request pattern. If token usage, retrieval volume, tool invocations, and retries are not linked to the same trace, billing spikes and performance regressions become difficult to localise. In practice, the most useful traces are the ones that make it possible to ask, “Which step consumed the budget?” and get a concrete answer instead of a generic service metric.
Operational signals that point to missing context
Some warning signs are less about failure and more about ambiguity. Rate limit errors that are hard to reproduce, inconsistent retrieval quality, or tools that appear to behave differently across similar prompts often indicate that the trace is missing the state needed to explain the difference. If the system uses retrieval or external tools, tracing should capture enough metadata to distinguish “the model answered differently” from “the upstream inputs were different.”
When teams cannot inspect prompt, retrieved context, and response together, they usually cannot determine whether an issue is caused by the model, the orchestration layer, or the supporting services around it. That is especially important in agentic systems, where tool selection, retries, memory, and routing decisions can materially change the outcome. The OWASP Top 10 for Agentic Applications 2026 is useful here because it emphasises tool misuse, privilege issues, and other control failures that become much harder to diagnose without sufficient telemetry.
Another practical indicator is that incidents are only visible after user reports. If tracing is strong enough, operators should be able to spot abnormal latency, unusual tool sequences, repeated fallback behaviour, or unexpected retrieval patterns before they become customer-facing. If they cannot, the instrumentation is probably too coarse for production support.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST AI 600-1 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — Govern | GenAI tracing needs governance and measurable oversight of model behaviour. |
| Recommendation — Define required traceability signals and review them as part of AI governance. | ||
| NIST AI 600-1 | MAP — Map AI System Context | LLM tracing must capture system context, inputs, outputs, and dependencies to support observability. |
| Recommendation — Capture end-to-end request context so behaviour can be reconstructed and analysed. | ||
| OWASP Agentic AI Top 10 | A3 — Tool Misuse | Poor tracing hides tool calls and makes agent behaviour hard to diagnose. |
| A4 — Identity and Privilege Abuse | Tracing gaps obscure who or what exercised authority through the agent path. | |
| Recommendation — Log tool selections and outputs so misuse and abnormal action paths are visible. Record privileged action paths so authority use is attributable and reviewable. | ||
| CIS Controls v8 | 8 — Audit Log Management | Tracing is an auditability problem requiring sufficient event detail for investigation. |
| Recommendation — Ensure logs capture the fields needed to investigate latency, cost, and control failures. | ||
Practitioner Guidance
What to verify: A useful LLM trace should let you reconstruct one request end-to-end, including the exact prompt that was sent, the retrieved context, the tool calls made, and the timing of each step. If any of those elements are absent, treat the trace as diagnostic-supporting rather than diagnostic-complete.
What practitioners underestimate: Partial telemetry often looks adequate during happy-path testing because the system still returns an answer. The real test is whether the trace explains failures, cost spikes, and variability without needing to reproduce the issue under live conditions.
Practitioner takeaway: The threshold for “enough detail” is not whether you have logs, but whether the trace can answer why a specific run was slow, expensive, or inconsistent without requiring guesswork or re-execution.
Related resources from NHI Mgmt Group
- What are the signs that LLM observability is not working well enough?
- What are the signs that an LLM gateway is not giving security teams enough visibility?
- What are the signs that LLM guardrails are not giving teams enough operational visibility?
- What are the signs that CSPM is not providing enough protection for LLM workloads?
