To execute your pipeline, you need to use agents. Agents are the workhorse of Azure DevOps. When a task in a pipeline needs to be executed, a job is created and submitted to an agent queue to be completed by an agent. Microsoft provides hosted agents which live in the cloud and need to be able to access public endpoints like AWS or Azure. There is a variety of hosts you can select. Here is the current list. This will, of course, evolve over time. Depending on your pipeline, you may want to execute tasks at different locations, for instance, if you're using a cloud-hosted Azure DevOps instance but want to execute your pipeline tasks on your on-premise servers, the cloud agents have no line of sight to your target systems; you'll need to install a self-hosted agent. These agents will be able to talk to the cloud-hosted Azure DevOps and to the on-premise target servers.

If you need to execute these tasks in a private workspace, the Azure DevOps agent can be installed on a variety of platforms from Windows OS to macOS, Linux, and Docker, allowing for integrations into many different of environments. Agent pools allow you to group and create security boundaries for your agents. They are scoped to your DevOps organization, and agent pools can be shared across multiple teams and projects. This is because sometimes the infrastructure you're deploying to is used by multiple teams.

A queue is used to collect jobs for an agent pool, which can be backed by one or many agents. When you create your release, you can specify what queue you want to use. Queues are scoped to your team project collection, this is so that you can share them across multiple team projects.

In your release pipeline, you can organize groups of tasks into jobs. Every build or deployment pipeline has at least one job, but can also be made up of many jobs. A simple example could be you have a mixed OS environment and you have tasks you need run on a Windows machine and tasks you need run on a Linux machine. In this case, you would define multiple release jobs, targeting different agents, to help achieve the desired deployment result.

Azure DevOps has the ability to run server jobs, which run tasks on the DevOps server itself. This is also referred to as agentless jobs. Agentless jobs do not require an agent to execute the task. The list of tasks that can be executed this way are small and contain tasks like manual intervention or REST API tasks.

Containers are becoming more common in today's landscape. With a container, you can leverage existing containers built by vendors or by the community or by yourself. When you specify a container to run your tasks, the tasks will be executed inside that container.

Agents can be grouped together into deployment groups. Deployment groups are logical collections of agents that exist within an environment, for instance, Dev, Test or Production. Tasks that are targeted at a deployment group can run on some or all of the target servers, depending on the arguments you specify.

The last thing to cover in regards to jobs are Multi-configuration, and Multi-Agent. Typically, a task will run on a single agent, however, with multi-configuration, you can run the same set of tasks with different configurations. For instance, deploying the same website to different regions in Azure. With multi-agent, you can run the same set of tasks many times on a number of different agents. A good example would be a performance test, where you can run the same 10 tests on 20 different servers to validate the results.