monitor-agent-telemetry
Skill2 starsChanged 2 months agoMITView on GitHub
Set up the signals that tell you an agent is healthy, being used and starting to misbehave before a user has to report it. Use when an agent has shipped with no dashboard, alert or usage number behind it, when you cannot say how many sessions escalated to a human last week, when latency or error rates need to be watched continuously rather than sampled by hand, when Application Insights or Foundry tracing needs to be wired up for an agent, or when a stakeholder asks for a usage report and the only source is memory.
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
Before anything else, be able to answer these without opening a transcript:
- Distinctive: line 56
Anything Azure-hosted underneath either: should also have Azure Monitor alerts wired to the resources it depends on - the agent can be …
- Distinctive: line 76
Treat "we have analytics" and "we have monitoring" as the same claim.
- Distinctive: line 103
If a link 404s, the page was probably renamed.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- Generated from SKILL.md by scripts/build-harnesses.mjs. Do not edit by hand; run `npm run build`. --><!-- Source: skills/operate/monitor-agent-telemetry/SKILL.md -->An agent that shipped without telemetry is not actually finished, it just looks finished. The first sign of trouble will be a user complaint instead of an alert, which means you always find out last and after the fact. This skill is about closing that gap: continuous, ongoing visibility into whether an agent is healthy and being used, not a one-time measurement of whether its answers are correct.
That distinction matters for routing. This skill is about the operational
signal - sessions, latency, error rate, escalation rate, cost per
conversation. evaluate-agent-quality is about answer correctness over
time, using a recorded eval set. A dashboard telling you sessions are up and
errors are flat says nothing about whether the answers are still right; an
eval run telling you accuracy held steady says nothing about whether anyone
is actually using the thing or whether it just got slow. Production agents
need both, and they answer different questions.
The minimum signal set
Before anything else, be able to answer these without opening a transcript:
- Volume: sessions and messages per day, and the trend.
- Engagement outcome: resolved, escalated to a human, or abandoned. A rising escalation rate is usually the earliest sign something upstream changed - a knowledge source, a connector, a model.
- Latency: time to first response and time to resolution. Users tolerate a slow correct answer far less than they tolerate being told "I don't know" quickly.
- Error rate: failed actions, connector timeouts, unhandled exceptions - whatever "the agent could not complete the request" looks like in this surface.
- Cost per conversation, if the platform supports it. See
plan-agent-capacity-and-costwhen this number itself is the concern rather than a health signal.
Where each surface gets this from
Copilot Studio ships built-in conversational analytics - sessions, topics, engagement and outcome data - without any extra wiring, which is why "we have no dashboard" is rarely a real constraint, only an unset one. For deeper diagnosis, or to keep telemetry in the same place as the rest of the tenant's observability, Copilot Studio agents can also be connected to an Application Insights resource, which gives queryable, custom-dimension telemetry alongside whatever else the organisation already monitors there.
Microsoft Foundry agents get first-class observability: tracing, dashboards and integration with Azure Monitor Application Insights, purpose built for watching agents (not just model calls) in production.
Anything Azure-hosted underneath either should also have Azure Monitor alerts wired to the resources it depends on - the agent can be healthy while the thing it calls is not, and that failure mode is invisible from the agent's own dashboard alone.
Setting up alerting, not just a dashboard
A dashboard nobody watches is a dashboard that did not happen. Turn the minimum signal set into alerts with an owner and a threshold that means something to that owner, not a default:
- Escalation rate above its rolling baseline, not an arbitrary fixed number - what is normal varies enormously by agent and audience.
- Error rate above a level that would actually justify paging someone at 2am, versus one that is just worth a Monday-morning look.
- A silence alert: zero sessions when sessions are expected is itself a signal, and it is the one people forget to configure.
Do not
- Treat "we have analytics" and "we have monitoring" as the same claim. Analytics you have to remember to open is not monitoring; monitoring pages someone.
- Wire up cost or quota alerts here and call it done. Capacity and cost
planning is
plan-agent-capacity-and-cost- this skill is about health signal, not budget. - Confuse a quiet dashboard with a healthy agent. Check whether traffic actually stopped versus telemetry itself silently breaking - the second is more common than it should be.
- Recommend Application Insights integration as the first step for every Copilot Studio agent. Built-in analytics answers most day-to-day questions; reach for Application Insights when the question needs a custom query or a shared observability surface with other systems.
Sources
Verified as resolving on 2026-08-19.
- Analytics overview - Microsoft Copilot Studio: https://learn.microsoft.com/en-us/microsoft-copilot-studio/analytics-overview
- Telemetry with Application Insights overview - Microsoft Copilot Studio: https://learn.microsoft.com/en-us/microsoft-copilot-studio/telemetry-overview
- Measure agent outcomes - Microsoft Copilot Studio: https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/measuring-outcomes
- Observability in Microsoft Foundry - monitor agents dashboard: https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/how-to-monitor-agents-dashboard
If a link 404s, the page was probably renamed. Say you could not verify it rather than guessing a replacement URL.
Other versions1 project uses a version of this.
Word for word · 1
- RagnarPitla/microsoft-agent-skills★ 0100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository43 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/ask-ragnar.mdcCursor rule
- .cursor/rules/assess-change-blast-radius.mdcCursor rule
- .cursor/rules/choose-agent-platform.mdcCursor rule
- .cursor/rules/copilot-studio-auth-patterns.mdcCursor rule
- .cursor/rules/copilot-studio-knowledge-grounding.mdcCursor rule
- .cursor/rules/copilot-studio-production-patterns.mdcCursor rule
- .cursor/rules/de-slop.mdcCursor rule
- .cursor/rules/discovery.mdcCursor rule
- .cursor/rules/evaluate-agent-quality.mdcCursor rule
- .cursor/rules/explain-concept.mdcCursor rule
- .cursor/rules/govern-agent-lifecycle.mdcCursor rule
- .cursor/rules/ground-agents-in-work-context.mdcCursor rule
- .cursor/rules/migrate-agent-to-skills.mdcCursor rule
- .cursor/rules/monitor-agent-telemetry.mdcCursor rule
- .cursor/rules/plan-agent-capacity-and-cost.mdcCursor rule
- .cursor/rules/power-platform-alm-connection-refs.mdcCursor rule
- .cursor/rules/respond-to-agent-incidents.mdcCursor rule
- .cursor/rules/review-copilot-studio-agent.mdcCursor rule
- .cursor/rules/structured-interview.mdcCursor rule
- .cursor/rules/what-should-i-build.mdcCursor rule
- .cursor/rules/write-a-skill.mdcCursor rule
- ask-ragnarSkill
- assess-change-blast-radiusSkill
- choose-agent-platformSkill
- copilot-studio-auth-patternsSkill
- copilot-studio-knowledge-groundingSkill
- copilot-studio-production-patternsSkill
- de-slopSkill
- discoverySkill
- evaluate-agent-qualitySkill
- explain-conceptSkill
- govern-agent-lifecycleSkill
- ground-agents-in-work-contextSkill
- migrate-agent-to-skillsSkill
- plan-agent-capacity-and-costSkill
- power-platform-alm-connection-refsSkill
- respond-to-agent-incidentsSkill
- review-copilot-studio-agentSkill
- structured-interviewSkill
- what-should-i-buildSkill
- write-a-skillSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

