Scout vs the Machine Agent
Why there are two collectors and one estate — target device, footprint, activity ceiling, deployment and the authentication models, which now differ: Scout is enrollment-only while the Machine Agent still supports an ingest api_key.
scoutmachine-agentcomparisoncollectorsestateserversworkstationsenrollmentapi-keyx-agent-kind
One estate, two collectors
A deliberate part of the design: the same inventory capability exists in the Machine Agent (the server agent) through its optional inventory module. There are two collectors because there are two classes of device, not because there are two places the data lives.
- VerOps Scout is the lightweight, low-footprint agent for user endpoints — desktops, laptops, workstations. It adds the signals that only make sense there: foreground focus (activity level 3) and per-application bandwidth.
- The Machine Agent already runs on servers for logs, metrics, and command execution. Enabling its inventory module lets it additionally report inventory into the same governed estate, using the same VerOps Scout v0.4 inventory contract (report schema v2) and driven by the same central config — reporting as a server, with activity capped at level 2 (no foreground).
A server's nginx and a designer's photoshop.exe land in the same Products grid, the same utilization analytics, and the same dashboards.
Comparison
| VerOps Scout | Machine Agent inventory | |
|---|---|---|
| Target device | Desktops, laptops, workstations | Servers (Linux / Windows) |
| Reports as | Workstation | Server |
| Footprint | Standalone lightweight agent | A module inside the existing server agent (off by default) |
| Activity signals | Foreground (3), CPU (2), network (1), idle (0) + bandwidth | CPU (2), network (1), idle (0); no foreground, tops at level 2 |
| Deployment | Preconfigured setup wizard or generic installers — the service is registered and started automatically | Enable the inventory module in the agent's config on an existing agent |
| Auth | Enrollment only from v0.6.0 — a limited-use token exchanged once for a revocable per-device key. No org-wide ingest key, no user login; a config naming one refuses to start | The same enrollment flow with agentKind=server (recommended), and an ingest api_key still works — the Machine Agent is unchanged here. The platform connection key cannot authenticate inventory either way |
| Reports into | The shared governed estate | The same shared estate |
Which collector?
| Device | Collector |
|---|---|
| Desktop / laptop / workstation | VerOps Scout |
| Server already running the Machine Agent | Enable the Machine Agent inventory module |
| Tablet / iPad | Ingest via MDM |
Note: The Machine Agent is documented under VerOps Machine Agent. Enabling its inventory module requires its own inventory credential — an enrollment token (preferred) or an ingestapi_key, which the Machine Agent still supports — because the platform connection key cannot authenticate inventory. The platform distinguishes the two products by theX-Agent-Kindheader they send, which is why API-key auth is refused for Scout and accepted for the Machine Agent.