The Problem Agentless Can’t See
Most IT management tools are built with an optimistic assumption: that the managing system can reach the managed device directly. In a flat, well-connected network, that assumption holds. SSH is available, the API is accessible, and polling works fine.
The assumption breaks the moment you introduce NAT.
IPv4 exhaustion means the majority of managed devices live behind network address translation — in remote offices, on client sites, behind corporate firewalls, at edge locations. The limitation surfaces immediately in practice. Your management server tries to initiate an SSH session to a device at a remote office or client site. The device is behind a NAT router — which means from your management server’s perspective, it has no routable address. The workarounds are predictable: set up a site-to-site VPN (requires network configuration on both ends, firewall rules, and ongoing maintenance), use a jump host (another device to provision and manage), or configure port forwarding on the remote router (requires access you may not have, and breaks when the device moves or the external IP changes). Each workaround is essentially building an improvised agent — something persistent on the remote side that maintains reachability — without the reliability engineering that goes into purpose-built agent software. You pay the deployment cost either way. The question is whether you want to pay it once, cleanly, or continuously, in patches.
This is the problem an agent solves at the architecture level. The agent runs on the managed host and initiates an outbound connection to the central manager — a pattern that works naturally behind NAT, through firewalls, and across network boundaries, without special firewall rules on the managed side.
Agentless Is Genuinely Simpler to Start
It is worth being honest about the tradeoff. Agentless is not a bad idea — it is a different set of constraints. If your infrastructure is on a single flat network, if the devices you manage are always reachable, and if your management needs are straightforward, agentless is legitimately easier. There is no software to install, no daemon to maintain, and the protocols (SSH, SNMP, REST) are already available everywhere.
The limitation shows up at scale and at distance. Polling every few minutes means you are always working with stale state. A managed device that goes offline and comes back with changes made in the gap is invisible to you until the next poll cycle. Complex multi-step workflows — rolling updates, coordinated deployments, sequenced configuration changes — are difficult to orchestrate reliably when you have no persistent connection to the host.
Agents address both problems: they maintain a persistent connection so state is current, and they can queue and execute work locally even when connectivity is intermittent.
Decades of Agent Design
The agent pattern ResorsIT uses is not new. Configuration management systems, endpoint monitoring tools, and enterprise IT management platforms have refined this architecture for decades. The lessons are well understood: keep the agent lightweight, have it initiate the connection rather than receive it, queue work locally when disconnected, and handle authentication carefully.
ResorsIT’s agent is a lightweight Go daemon. It maintains a persistent WebSocket connection to the Agent Manager, which gives the manager real-time visibility into host state and the ability to execute commands immediately rather than waiting for the next poll cycle. File transfers use time-limited tokens managed by the Agent Manager, so there is no persistent credential stored on the host. Commands and results are logged centrally, giving you a clean audit trail without depending on fragmented external logs.
The deployment concern is legitimate but narrower than it sounds in practice. ResorsIT’s agent is a single compiled binary — no runtime to install, no dependencies to manage. It gets deployed through whatever tooling you already use for provisioning: a startup script, a configuration management run, or a manual install on the first host while you are evaluating. Once an agent registers with the Agent Manager, it appears in the managed fleet. Subsequent updates to the agent itself are handled centrally — you do not log into each host to upgrade it. The genuine cost is the initial rollout across an existing fleet, which is a one-time project, not a recurring one.
What This Means in Practice
In a distributed environment — multiple client sites, remote offices, cloud instances, edge devices — agentless management requires solving the network access problem for every host. That is a recurring cost that compounds as the environment grows. Agent-based management solves it once, at the architecture level.
The relevant question is not whether agents are more complex than agentless. They are. The question is whether that complexity is front-loaded (deploy the agent, done) or continuous (maintain VPN tunnels, manage firewall rules, handle polling failures). For organizations managing infrastructure across network boundaries, the front-loaded cost is the better trade.
The ResorsIT platform uses an agent-based architecture to manage distributed infrastructure across network boundaries — remote offices, client sites, edge devices, and cloud instances behind NAT. See the platform overview or contact us to learn more.