What the Agent Sees and What It Misses

Endpoint agents are good at a narrow set of things. Knowing the boundary prevents the common error of treating the dashboard as a picture of the day.

The question in “What the Agent Sees and What It Misses” is easier to answer when teams combine system evidence with the time and hand-offs involved in completing the work. An organisation evaluating the full guide can make that operational effort visible by project and team, while direct observation and employee feedback remain necessary to explain why the friction occurs.

For an independent benchmark, compare this approach with CISA Secure Our World guidance; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

What it sees well

Boot and login duration, broken into phases.

Application launch times and crashes.

CPU, memory and disk pressure, with history.

Network latency from the device to named destinations.

Battery health, driver versions, patch state, disk encryption.

Which applications are installed and which are actually used.

That last one is genuinely valuable and underused.

What it sees partially

Whether a web application is slow. The agent sees the browser and the network to the edge; what happens inside somebody else's cloud is inferred.

Whether a meeting was poor. Packet loss and jitter are visible; whether people could hear each other is not.

Whether the device is in use. Presence of input is not presence of work.

What it does not see at all

Waiting for a person: an approval, an answer, a callback.

Process steps: a form with seven fields that should have two.

Duplicate entry across systems.

Finding things: the twenty minutes looking for a document.

Knowing who to ask.

And whether the task was achieved at all, which is the only outcome anybody cares about.

The proportion problem

Nobody has a trustworthy figure for how much lost time is technical and how much is process, and anybody quoting one is quoting a vendor.

What is reliably reported in organisations that look at both: process friction is substantial and routinely larger than expected.

Which means a programme that measures only the device is measuring a part of unknown size.

Using telemetry properly

For what it is good at: finding the devices and applications that are genuinely failing, which is real and worth fixing.

As a signal that prompts a question rather than as an answer.

And alongside at least one source that sees outside the machine — tickets, sentiment, or observation, each with its own note.

The honest summary

Telemetry tells you about the machine. It is accurate, scalable and cheap once deployed.

It is one input to experience and not a measure of it, and treating it as the whole picture is the most common structural error in this field.

What to check

List the last ten complaints your service desk received. How many would an agent have detected?

Does your dashboard show anything that happens outside a device?

Do you know your most-used and least-used applications?

And what is the longest wait in any of your common processes?

The point

Telemetry tells you about the machine: accurate, scalable and cheap once deployed.

It is one input to experience and not a measure of it.

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.