There are two ways to find out what a machine is doing. Ask it from outside at intervals, or run something on it that watches continuously. They are usually presented as a procurement choice between agentless and agent-based products. They are better understood as two different kinds of truth, each of which is unavailable to the other.
The interval decides what exists
A poll captures the state at the instant it arrives. Between polls, nothing is recorded, and anything shorter than the interval either vanishes or appears with the wrong shape.
A thirty-second poll cannot describe a ten-second saturation. If the sample happens to land during it, the graph reports a plateau lasting thirty seconds, which is also wrong. Nothing failed. The sampling rate decided what was allowed to exist, and the resulting graph is not a lower-resolution picture of events so much as a different set of events.
This is the same mechanism as the rollup described in the retention article, applied at the moment of collection rather than afterwards, and it is worse because there is no original to go back to.
What each one can see at all
An external check sees the surface: does the port answer, does the page return, what does the device report through its management interface. That is exactly what a user experiences, which is a genuine advantage rather than a limitation.
An agent sees the inside: per-process resource use, file descriptors, queue depths, the application's own instrumentation, the log stream before it leaves the machine. Questions of the form "which process" or "why" are usually only answerable from in there.
Network hardware settles this for itself. Most switches and appliances cannot run anything, so polling their management interface is not a preference, it is the only option.
Failure means different things
When a poll fails, something between the collector and the target failed, and the target is only one of the candidates. Agentless monitoring measures the path as much as the destination, which makes it excellent for answering "can it be reached from here" and unreliable for "is it alive".
When an agent stops reporting, the result is silence, and silence looks identical to a healthy quiet period unless something is specifically watching for the absence. A monitoring system that only alerts on bad values will never alert on no values, which is how a host disappears for a fortnight without anyone noticing.
The agent is a cost with several names
It has to be installed everywhere, kept upgraded, and it consumes resources on the machine it is measuring. It usually runs with high privilege, which makes it part of the security surface: a compromised monitoring agent is a compromise of everything it runs on, and the same argument applies with more force to workforce agents.
And it dies with its host. The final seconds before a machine goes down are the interesting ones, and they are the ones that never leave. This is the practical reason serious setups keep both: the agent for depth, an external check for the moment the agent stops being able to speak.
Push and pull are a different question
These two axes get conflated constantly. Whether collection is agent based is a question about where the code runs. Whether data is pushed to a collector or pulled from an endpoint is a question about who initiates the connection.
Agents commonly expose an endpoint that a central server pulls from, which is agent-based and pull. Applications commonly push measurements to a local daemon, which is agentless from the host's point of view and push. The distinctions matter for firewalls, for ephemeral workloads and for what happens when the collector is unavailable, and treating them as one decision produces an architecture argument in which the two sides are discussing different things.
Short-lived workloads break polling
A container that exists for forty seconds cannot be discovered, polled and reported by a system with a one-minute discovery cycle. It will simply never have existed. Environments that create and destroy workloads continuously need collection that registers on start rather than collection that goes looking, and this is the practical reason service discovery sits at the centre of modern setups.
The same choice, on the other side of this site
Workforce monitoring has exactly this split. An endpoint agent sees applications, windows, input and files. Collection from the interfaces of services the company already uses sees calendars, message metadata and document activity, and nothing else.
The trade is the same in shape and much sharper in consequence: the agent sees more, costs more to deploy, and is what triggers most of the legal and cultural questions covered in the workforce section. Choosing it because it collects more, without asking which question needed answering, is the most common expensive mistake in that market.
What we cannot verify
Overhead figures for agents are published by their vendors, measured on hardware and workloads they do not describe, and we reproduce none of them. Polling intervals and discovery cycles are configurable and their defaults differ between products. Whether a given interval is fast enough is a question about the duration of the events you care about in your own system, which is answerable from your own history and from nowhere else.
The short version
- A poll records the instant it arrives; between polls nothing exists.
- Events shorter than the interval vanish or appear with the wrong shape.
- An external check measures the path as much as the target.
- An agent stopping produces silence, which looks exactly like quiet.
- The agent dies with the host, so the interesting final seconds never leave.
- Agent versus agentless and push versus pull are two separate questions.