Agent-based discovery and agentless discovery each fail in places the other covers. The useful question is not which one to buy, but whether your tool can run both against one data model.
If you are standing up a software asset management programme and shopping for a tool to support it, you will have to decide where you stand on agent-based versus agentless discovery. Some products offer only an agent. Others offer only agentless collection. Both will tell you their approach is the right one.
The honest answer depends on your circumstances, what the programme is meant to achieve, and how you want to run the environment you are managing. But it usually lands in the same place, and it is not one of the two options you were offered.
Before you can manage anything on a network, you need to know two things: what is there, and what each of those things actually is.
That sounds too obvious to state, except that a number of products effectively ignore it. How do you deploy an agent to something you do not know exists? How do you deploy an agent to a switch, which cannot run one?
You cannot. Which means an agent-only product is bounded by the list you already had. It will tell you a great deal about the machines you knew about, and nothing whatsoever about the ones you did not — and the ones you did not are usually the interesting ones.
Agent-only. Richer data, collected continuously, including things you can only see from inside the operating system: software usage metering, local configuration, patch state. But you have to know a device exists before you can deploy to it, some devices cannot take an agent at all, and there are parts of the infrastructure — data centres especially — where getting approval to install one ranges from slow to impossible.
Agentless-only. Finds things without prior knowledge, and reaches devices that could never run an agent. But it depends on the device being reachable at the moment you scan. If you have remote workers who rarely connect to the corporate network, you get intermittent, out-of-date information about what is on their machines — which is bad for SAM, where usage evidence and installation dates are the whole basis of a licence position.
Both approaches have strengths and weaknesses, and which weakness hurts more depends entirely on your organisation.
By now the answer to the question in the title is probably obvious: both.
Unless you already have a discovery capability you trust to find everything you own, you need agentless discovery first. It finds not just PCs, laptops and servers, but switches, printers and other connected devices — including the connected hardware that has quietly attached itself to the network without going through anybody’s asset process.
That last category matters increasingly for security rather than licensing. A great deal of connected equipment now sits on corporate networks with poor security and no patching story. Used without a policy governing it, and undiscovered, it is a genuine route in.
Once you know with confidence what is actually out there, you can plan and deploy agents to the devices that can take one, and get the full software inventory and usage picture SAM depends on.
There are also places where agentless collection is the better answer permanently, not just as a first pass:
So a hybrid of agent and agentless discovery is not a compromise. It is the correct design. It gives you the current, detailed inventory and usage information SAM requires, and the coverage that discovery requires, and it makes patching and software distribution possible where an agent is present.
CerteroX ITAM was built around this rather than adapted to it. There are ten discovery methods, and they all resolve into one schema, so there is no reconciliation step between them.
Finding what you do not know about. Network Discovery sweeps a class-C subnet in under five seconds across NetBIOS, SNMP and ICMP, then probes port 22 to establish where an agent could actually be deployed. Discovery runs ahead of deployment rather than after it. SNMP collection also brings back real detail from devices that will never run an agent: printer consumables and page counts, switch port and routing tables.
Where an agent works. The native agent covers Windows, macOS, Linux, IBM AIX, HP-UX and Oracle Solaris — one agent, six operating system families, the same inventory cycle and the same licence engine for all of them. Unix platforms are not an integration project here, which is usually where a data centre-heavy environment finds out whether a tool was designed for it or retrofitted.
Where an agent does not work. Agentless collection and a command-line collector (csinvcli) handle locked-down machines. Standalone inventory covers air-gapped and offline systems, which no scan will ever reach. Non-persistent VDI is handled as its own case rather than producing a new device record every morning.
Keeping the picture honest. Active Directory import brings in users, groups, computers, sites and subnets, and can be cross-referenced against an independent scan so AD is a source rather than the source. Duplicate system detection and stale device archiving stop the device count inflating, which matters when your licence position is calculated from it.
For SAM specifically, the agent is what earns its place: AppsMonitor file-based usage metering with first-used and last-used tracking, a % Used utilisation metric over a rolling 90-day window, and Terminal Server and RDS remote-usage tracking per device. That is the evidence you need before reclaiming a licence from somebody, and it is not available from a network scan.
Rather than asking whether a product is agent-based or agentless, ask three things.
How does it find a device nobody has told it about? What does it do about the machines where an agent cannot be installed, and about the ones that never touch the network? And when it has collected the same device by two different methods, which record wins, and where does that decision happen?
A product that has good answers to all three is one that will still be giving you an accurate picture in three years.
Name the coverage gap you cannot close today — the locked-down subnet, the air-gapped rack, the Unix tail — and book a demo. The session is built on whichever one you pick.
Other posts covering the same ground.
End of support is not really a patching problem, it is an inventory problem. Written ahead of the January 2020 cut-off, the argument holds for every deadline since: you cannot remediate the machines your asset register has never seen.
A working introduction to the hardware life cycle — plan, acquire, commission, maintain, retire — and what an ITAM platform has to do at each stage to be worth having.
Macs and iPhones arrived in the workplace one department at a time, and most management tooling still treats them as an exception. They should be inventoried, metered and licensed on exactly the same terms as everything else you own.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.