What Is Agent in DevOps?

Think of an agent like a personal assistant who lives inside your computer. You give the assistant a list of chores, and the assistant does them on schedule or when you ask. You don't need to be in the room, the assistant handles everything.

For example, you might tell your assistant to check your email every morning and sort out spam. That same idea applies to IT: an agent is a program installed on a server or laptop that waits for instructions from a central controller. When the controller says "run these tests," the agent wakes up and runs them.

When the controller says "deploy this new version of the app," the agent downloads the files and installs them. The agent reports back what happened, success or failure, so you always know the status. Agents are used in many areas like monitoring (checking if a website is up), security (scanning for viruses), and DevOps (building and deploying code).

The key point is that agents run locally but are managed remotely. This saves you from having to log into each machine manually. Without agents, you would need to sit at every computer and type commands by hand.

With agents, you tell one central tool what to do, and the agents do the actual work on the target machines. This makes large-scale IT operations faster, more reliable, and less error-prone.

In the context of Azure DevOps and modern DevOps practices, an agent is a software runtime that executes jobs defined in pipelines. The agent runs on a target machine, either a Windows, Linux, or macOS host, and communicates with the Azure DevOps server or service using HTTPS. The agent listens for incoming job requests from the Azure Pipelines orchestration engine.

When a job is triggered, the agent downloads the job definition, which includes tasks such as running scripts, compiling code, running tests, or publishing artifacts. The agent executes each task within a sandboxed environment, captures logs, and streams output back to the Azure DevOps portal in near real-time. Agents can be configured as either Microsoft-hosted (managed by Microsoft, automatically scaled) or self-hosted (installed on your own infrastructure).

Self-hosted agents give you more control over the runtime environment, including custom software dependencies, network access, and security policies. The agent software itself is open source and written primarily in cross-platform runtimes like .NET Core.

It communicates via the Azure DevOps REST API and uses WebSocket-like channels for live logging. Authentication is handled through a personal access token (PAT) or OAuth. Agents support capabilities, metadata tags (e.

g., "Java", "Windows Server 2019") that help the pipeline match jobs to suitable agents. When a pipeline demands an agent with specific capabilities, the orchestration engine selects a matching agent from the pool.

Each agent can run only one job at a time, but you can install multiple agents on the same machine by using separate service accounts and deployment directories. The agent lifecycle includes installation, configuration, starting the service, and periodic updates. Azure DevOps automatically updates hosted agents, but self-hosted agents require manual or automated update handling.

Agents are also used outside of Azure DevOps, for example, Puppet agents, Chef agents, and Ansible agents (though Ansible is typically agentless). In monitoring, agents like the Azure Monitor Agent or Prometheus Node Exporter collect metrics and forward them to central systems. The core pattern remains the same: a lightweight daemon that executes work locally under remote orchestration.

In practical IT, especially in DevOps environments, agents are the backbone of automation. They allow teams to run thousands of builds, tests, and deployments every day without human intervention. This is critical for continuous integration and continuous delivery (CI/CD) because it means code changes can be automatically built, tested, and deployed to production in minutes.

Without agents, every step would require someone to log into a server and type commands, which is slow, error-prone, and does not scale. Agents also enable consistency. Because the same agent software runs on every target machine, the execution environment is predictable.

You can ensure that every build uses the same compiler version, the same dependencies, and the same test suite. This eliminates the "it works on my machine" problem. In monitoring, agents provide real-time visibility into system health.

The Azure Monitor Agent, for example, collects performance counters, event logs, and custom metrics from all your servers and sends them to a central Log Analytics workspace. This gives operations teams a single pane of glass to detect issues before users are affected. Agents also matter for security.

When you use self-hosted agents, you control where the code runs, inside your network, behind your firewall. This is essential for regulated industries that cannot send code to external cloud hosts. You can lock down the agent machine, restrict network access, and audit every job.

Agents support secure variable injection and secret management, so passwords and API keys never appear in logs. In short, agents are not just a convenience, they are a foundation for reliable, scalable, and secure automation. Any IT professional working with CI/CD, configuration management, or monitoring will encounter agents regularly.

On the AZ-400 exam, agent questions typically appear in three patterns: configuration, scenario, and troubleshooting. Configuration questions: You might be asked to select the correct YAML syntax to specify agent demands. For example, "Which YAML key-value pair would ensure the pipeline runs only on an agent with the 'Java' capability installed?"

Answer: the 'demands' key with 'java' in the pool section. Another configuration question could ask: "How do you add a custom capability to a self-hosted agent?" The correct answer is to edit the .

capabilities file in the agent directory or use the agent configuration tool. Scenario questions: A company has a security policy that requires all code to be built and tested on machines inside the corporate network. Which agent solution should they use?

Answer: self-hosted agents. Another scenario: A team has a pipeline that builds a .NET Framework application, but the Microsoft-hosted agent does not have the exact Windows SDK version required.

What should they do? Answer: use a self-hosted agent with the specific SDK installed, or create a custom image for a hosted agent (if using Azure Pipelines). Troubleshooting questions: A pipeline is stuck in a 'waiting for agent' state.

What are possible causes? The agent pool may have no available agents, all agents may be busy, or agents may be offline due to network issues. Another common troubleshooting pattern: a build fails with 'Agent is lost' or 'No agent found matching demands'.

The cause is often missing capabilities on the agent, or the agent service has stopped. You might also see questions about agent upgrades: "You notice that a self-hosted agent is not receiving new jobs. What should you check?"

Answer: verify that the agent version is compatible with the Azure DevOps server version, and update the agent if needed. Some questions ask about agent pools vs. deployment groups.

You need to know that agents in a deployment group are specifically for release management to multiple servers, not for build jobs. Overall, expect 3–5 questions related to agents on the AZ-400 exam, spread across multiple sections. Mastery of agent concepts, configuration, and troubleshooting is essential.

In practice, setting up and managing agents is a core DevOps skill. The most common scenario is installing a self-hosted agent on a VM or physical server that has specific software your pipeline needs. For example, a legacy .NET Framework app requiring Windows Server 2019 with Visual Studio 2019 Build Tools. You install the agent, configure it with capabilities like 'VS2019' and 'DotNetFramework', and then point your pipeline to use a pool that contains this agent.

One critical detail is agent isolation. If you have multiple pipelines running on the same agent machine, ensure they don't interfere. Each job runs in a new workspace folder, but environment variables and file system state can persist. To avoid contamination, set 'clean: true' in your pipeline steps or use containers. For self-hosted agents, you should also secure the machine: use a dedicated service account with least privilege, restrict network access to only the Azure DevOps URL, and enable Windows Firewall.

Another practical point is monitoring agent health. A common issue is the agent service stopping due to memory pressure or a crash. Set up a monitoring check that pings the agent or checks the service status. In Azure, you can use Azure Monitor to alert on agent offline events. Also, consider using agent pools for different environments: a 'Dev' pool for quick builds, a 'Test' pool for integration tests, and a 'Prod' pool for deployments. This prevents resource contention.

When scaling, you can install multiple agents on the same VM by creating separate directories and using different agent names. However, each agent consumes memory and CPU, so balance load. For high-availability, use multiple VMs in an agent pool with redundant agents. The Azure DevOps orchestration engine distributes jobs across available agents.

Professionals should also know how to replace an agent's PAT before expiry. If the PAT expires, the agent goes offline and stops accepting jobs. You can re-configure with a new PAT without reinstalling from scratch by running the configuration script again. Document all agent registration details in a secure vault. This practical knowledge is what separates a beginner from a seasoned DevOps engineer.