What agentless actually means

“Agentless” is the first thing anyone says about Ansible, and it is usually said as though it were a property of the tool’s cleverness. It is not. It is a statement about deployment: there is no Ansible software installed on the managed node, and no Ansible process running there between runs.

That is the whole claim. Everything people like about it and everything they get caught by follow from that one sentence, and this lesson works through both halves — because the second half is the one that determines how you have to operate.

What actually runs where

During a run, code from Ansible does execute on the managed node. Agentless does not mean nothing arrives; it means nothing stays.

The sequence, in outline — the next two lessons take it apart properly:

1. The controller connects over SSH.
2. It builds a self-contained Python payload for the task and transfers it to a temporary directory on the managed node.
3. The managed node’s own Python interpreter executes it.
4. The payload prints a JSON result to stdout, which travels back over the same connection.
5. The controller deletes the temporary directory.

The managed node needs a reachable SSH service and a usable Python interpreter. It does not need an Ansible package, a service unit, a listening port, a certificate, or an account for a management server to authenticate as.

What you gain

Nothing to install before you can manage a host

An agent-based tool has a bootstrap problem: to manage a host you must first install the agent on it, which means you must manage it before you can manage it. This is usually solved with an image, a provisioning system, or a script — that is, with the very manual step the tool was supposed to replace.

Ansible’s requirement is satisfied by any host you can already SSH into, which for most estates is all of them. Onboarding is adding a line to the inventory.

Nothing to patch

An agent is software on every host. It has versions, CVEs, upgrade paths, and a compatibility matrix against the server. Upgrading it is a fleet-wide change — one that you perform with the tool you are upgrading, which is a well-known source of interesting afternoons.

Ansible upgrades happen on the controller. One machine, one virtualenv, and if the upgrade is bad you have broken your ability to make changes rather than the hosts themselves.

Nothing running as root permanently

An enforcement agent typically runs continuously as root, because it must be able to change anything at any time.

Ansible escalates privilege only for the tasks that need it, only for the duration of those tasks, and only when a run is happening. Between runs there is no privileged process. That is a materially smaller standing exposure, and it is one of the strongest security arguments for the model.

No agent fleet to keep alive

Agents fail. They die, wedge, fill a disk with their own logs, or lose their certificate. Then you have a second reliability problem — monitoring the thing that manages the fleet — and a host whose agent is dead looks exactly like a host that is compliant, because it stopped reporting problems.

Ansible has the opposite property: a host it cannot reach is loudly unreachable in the recap of every run. There is nothing to silently die, because there is nothing running.

What you lose

Now the half that is usually omitted. Every item here is a direct consequence of the same design.

No continuous enforcement

An agent running every thirty minutes reverts an unauthorised change within thirty minutes, unattended, forever.

Ansible reverts it the next time somebody runs the playbook. If that is weekly, the change persists for up to a week. If nobody runs it, it persists indefinitely — which is precisely the failure mode lesson 7 of Part I described.

Scheduling a run gets you closer, and many estates do exactly that. But note what you have built: a scheduled push that approximates continuous enforcement, with the schedule living on the controller rather than the host. If the controller is down, enforcement stops everywhere at once, whereas a fleet of agents keeps enforcing while their server is unavailable.

No state between runs

This one surprises people, so it is worth being concrete.

Ansible keeps nothing on the managed node between runs. There is no database of what it did last time, no record of the previous run’s results, and by default no cached facts.

$ ansible-config dump | grep -E '^(CACHE_PLUGIN|DEFAULT_GATHERING)\('

CACHE_PLUGIN(default) = memory
DEFAULT_GATHERING(default) = implicit

The consequences follow directly:

• Every run rediscovers the state of every host it touches. That is why fact gathering costs time on every run, and why the performance part of this course spends effort on caching it.
• A run cannot say “this host has changed since last time” without something outside Ansible storing the previous answer.
• A task cannot depend on a previous run having happened. It can only depend on the state that run left behind, which it must inspect.

That last point is a feature disguised as a limitation. Because the tool remembers nothing, every run must determine current state from the host itself — which means it cannot be fooled by its own stale bookkeeping. An agent with a corrupted local database can report compliance it has not verified; Ansible has no database to corrupt.

Nothing happens unless something runs the controller

The most important item, and the easiest to underrate.

Ansible has no daemon. It is a command-line program that starts, does work, and exits. Between invocations there is no Ansible anywhere in your estate — not on the hosts, and not on the controller either.

Which means: automation that nobody or nothing invokes does not run. Not “runs late” — does not run. There is no component whose job is to notice. The scheduling, the triggering, the alerting when a scheduled run fails, and the monitoring of the thing doing the scheduling are all yours to build.

The honest comparison

The last row decides more architectures than any of the others, and the push-model lesson later in this part is devoted to it.

Read the table as a set of trades rather than a scoreboard. Rows three and six favour agentless; rows four and five favour agents; row seven is a genuine security trade in both directions — one controller holding keys to everything is a concentrated target, while distributed credentials are a larger surface with no single catastrophic prize.

Knowledge check