6.7 Compare agent vs. agentless orchestration tools

Automation tools need a way to reach the systems they manage. The big design question is simple:

> Does the managed device need an installed agent?

If yes, the tool is agent-based. If no, it is agentless.

For ENCOR, understand the tradeoff. Do not turn this into tool fanboy trivia. The exam wants you to reason about architecture.

Agent-based orchestration

An agent-based tool installs software on each managed node. The agent runs locally and talks back to a control system.

controller/server <
installed agent <-> managed node

Common characteristics:

• a daemon or service runs on the managed node;
• the agent checks in or receives instructions;
• the tool can maintain ongoing state;
• the agent may enforce desired configuration continuously;
• every managed node must support and run the agent.

Examples often associated with agent-based models include Puppet and Chef. Some platforms can support mixed models, but the concept is what matters.

Agentless orchestration

An agentless tool does not require a permanent agent on the managed node. It connects using existing management interfaces such as SSH, WinRM, APIs, NETCONF, or RESTCONF.

control node
SSH/API/NETCONF/RESTCONF -> managed device

Ansible is the classic example for ENCOR-style discussions. For network devices, Ansible commonly connects with SSH or APIs and runs modules from a control node rather than installing a long-running agent on the router or switch.

Why agentless is common in networking

Most routers and switches are appliances. You usually cannot install arbitrary daemons on them like you can on a Linux server.

Network devices already expose management interfaces:

• SSH CLI;
• NETCONF;
• RESTCONF;
• SNMP;
• controller APIs;
• platform-specific APIs.

That makes agentless automation practical. The tool uses what the device already supports.

Comparison table

Orchestration vs. configuration management

These terms overlap, but they are not identical.

Configuration management keeps systems in a desired state.

Orchestration coordinates multiple steps across systems.

Example orchestration workflow:

1. Get device inventory from Catalyst Center.
2. Back up running configs.
3. Push NTP config to routers.
4. Verify NTP associations.
5. Write a change report.

That is more than one command. It is a workflow.

Agentless example: Ansible inventory

Inventory file:

[iosxe]
R1 ansible_host=10.10.10.11
SW1 ansible_host=10.10.10.12

[iosxe:vars]
ansible_network_os=cisco.ios.ios
ansible_connection=ansible.netcommon.network_cli
ansible_user=admin
ansible_password=REPLACE_WITH_VAULTED_SECRET

The control node connects to the devices. The routers and switches do not need a permanent Ansible agent.

For a real inventory, pull secrets from environment variables, Ansible Vault, or a secrets manager instead of committing cleartext passwords.

Agentless example: Ansible playbook

This playbook collects facts and runs a show command.

---
- name: Check IOS XE devices
  hosts: iosxe
  gather_facts: false

  tasks:
    - name: Show IP interface brief
      cisco.ios.ios_command:
        commands:
          - show ip interface brief
      register: interfaces

    - name: Print output
      ansible.builtin.debug:
        var: interfaces.stdout_lines

Read the playbook:

• it targets the iosxe inventory group;
• it skips normal server facts;
• it runs show ip interface brief;
• it stores output in interfaces;
• it prints the result.

Agentless example: Nornir-style Python

Nornir is also commonly used for agentless network automation. A simplified example:

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_command

nr = InitNornir(config_file="config.yaml")
result = nr.run(
    task=netmiko_send_command,
    command_string="show ip interface brief"
)

for host, output in result.items():
    print(host)
    print(output[0].result)

The pattern is similar: control node, inventory, transport, command/API, result.

Agent-based example in plain English

An agent-based server workflow might look like this:

1. Install agent on server.
2. Agent registers with controller.
3. Controller stores desired state.
4. Agent periodically checks in.
5. Agent applies changes locally.
6. Agent reports compliance.

That can be excellent for servers. It is often less natural for routers and switches because you usually do not install arbitrary agents on network appliances.

Security comparison

Agentless is not automatically more secure. Agent-based is not automatically less secure. Each has tradeoffs.

Agentless risks

• credentials stored on the control node;
• SSH/API access must be reachable;
• broad credentials can affect many devices;
• failed playbooks can change many nodes quickly.

Agent-based risks

• agents must be installed and patched;
• compromised agent/controller trust can be dangerous;
• stale agents may drift or stop reporting;
• agent communication path must be allowed.

Strong automation design uses least privilege, logging, change control, backups, and verification either way.

Choosing the right model

Use agentless when:

• devices already support SSH/API/NETCONF/RESTCONF;
• you cannot install agents;
• tasks are push-based or on demand;
• you need quick adoption across network gear;
• you are working with routers, switches, firewalls, and controllers.

Use agent-based when:

• managed systems support an agent;
• continuous enforcement is valuable;
• node-local execution is required;
• the organization already operates the agent platform well;
• servers/endpoints are the primary target.

Lab: compare Ansible-style agentless automation with an agent model

Goal

Understand the operational difference, not just the definitions.

Part 1: agentless inventory

Create inventory.ini:

[iosxe]
R1 ansible_host=10.10.10.11

[iosxe:vars]
ansible_network_os=cisco.ios.ios
ansible_connection=ansible.netcommon.network_cli
ansible_user=admin
ansible_password=REPLACE_WITH_VAULTED_SECRET

Create show_version.yml:

---
- name: Collect version
  hosts: iosxe
  gather_facts: false

  tasks:
    - name: Show version
      cisco.ios.ios_command:
        commands:
          - show version
      register: version

    - name: Print first line
      ansible.builtin.debug:
        msg: "{{ version.stdout_lines[0][0] }}"

Run:

ansible-playbook -i inventory.ini show_version.yml

Write down what the router needed before the playbook worked:

SSH reachability:
  Username/password or key:
  Network OS setting:
  Permanent agent installed on router: no

Part 2: design an agent-based equivalent

Write this in your notes:

1. If this were agent-based, what would need to exist on R1?
2. How would the agent receive work?
3. How would it report status?
4. Who patches the agent?
5. What happens if the agent stops running?

You do not need to build the agent. You need to reason about the operational model.

Part 3: compare failure modes

Fill this out:

Agentless failure: SSH blocked -> Symptom: -> Fix: -> Agentless failure: wrong credential -> Symptom: -> Fix: -> Agent-based failure: agent not checking in -> Symptom: -> Fix: -> Agent-based failure: stale policy -> Symptom: -> Fix:

Exam traps

• Agentless does not mean no authentication.
• Agentless does not mean no software anywhere; the control node still runs automation software.
• Agent-based tools can be strong for servers but may be impractical for network appliances.
• Ansible is commonly discussed as agentless.
• Orchestration coordinates workflows; it is broader than one config command.
• Controllers such as Catalyst Center and SD-WAN Manager can also be automation targets through APIs.

What to memorize

Agent-based: software installed on managed nodes.
Agentless: control node uses existing access methods.
Network devices often fit agentless well because they expose SSH/API/NETCONF/RESTCONF and do not ...

Exam-ready summary

Agent-based orchestration depends on managed-node software. Agentless orchestration uses existing management paths from a control node. For enterprise networking, agentless tools are common because routers and switches already expose management interfaces and usually do not run third-party agents. Know the tradeoffs: setup, reachability, credentials, enforcement, scale, security, and failure modes.

Sources used

• Cisco ENCOR 350-401 v1.2 exam topics: https://learningcontent.cisco.com/documents/marketing/exam-topics/350-401-ENCORE-v1.2.pdf
• Ansible Community documentation: https://docs.ansible.com/projects/ansible/latest/getting_started/introduction.html
• Ansible installation guide, agentless control node model: https://docs.ansible.com/projects/ansible/latest/installation_guide/intro_installation.html