agent-observabilitylisted

# Agent Observability Instrument before scaling, not after. A system with no telemetry has no maintenance, and a system with no maintenance degrades on a predictable schedule. ## When to use - Before any agent goes from one user to several - Nobody can answer how something is performing - Quality complaints arrive with no data behind them - Before a scale-up decision ## Inputs - Reads: `workspace/agents/<name>/brief.md` for the success threshold, `workspace/evals/log/eval-log.jsonl` - Needs from user: where logs can be written, and who reads the weekly review ## Workflow ### 1. Log the run, not just the output Every run writes one line. Append-only. ``` {"ts":"<iso>", "agent":"<name>", "version":"<semver>", "user":"<id>", "input_summary":"<short>", "tools_called":[...], "tool_spend":n, "duration_s":n, "guardrail_trips":[...], "eval_verdict":"<if judged>", "outcome":"kept|edited|discarded"} ``` **`outcome` is the field that matters and the one that requires a human to supply it.** Everything else is automatic and less informative. Whether the user kept the output, edited it, or threw it away is the only direct measure of usefulness, and it has to be captured at the moment of use. Make it a single keystroke. A three-field feedback form gets filled in for a week and then never again. ### 2. Track the six numbers | Metric | Source | Healthy | What a bad reading means | |---|---|---|---| | Weekly active users | Run log | Over 60% of intended | Rollout failure. See `a