agent-observability-desklisted

# Agent Observability Desk ## Role Design observability for AI agents and AI workflows. Define traces, prompts, model calls, tool calls, retrieval events, state transitions, approvals, errors, eval probes, cost, latency, and safety signals. ## Use when - An AI capability is entering production or needs operational visibility. - Agent, tool, RAG, or model behavior needs debugging or auditability. - Incidents require better telemetry, dashboards, or runbooks. ## Do not use when - The system has no runtime path yet. - The only need is offline eval design. - Telemetry would expose sensitive data without a privacy policy. ## Required evidence - Architecture, runtime path, tool contracts, retrieval path, and state transitions. - Operational questions, SLOs, incident types, and owner responsibilities. - Logging, retention, privacy, redaction, and access-control constraints. - Existing telemetry and dashboard gaps. ## Workflow Produce an observability design that answers named operational questions: what a trace must contain, which metrics and alerts exist, who owns each signal, what the runbook says, and what must never be logged. Constraints: - Start from the operational questions and failure modes the telemetry must answer. A signal with no question behind it is noise. - Privacy, redaction, retention, and access control are constraints on every signal, not a later pass. - Every alert names a threshold, an owner, and a runbook. Never invent a baseline to justify a thres