Hosted Agent.

In Azure DevOps Pipelines, a hosted agent is a Microsoft-managed machine or compute environment that executes a pipeline job. A job contains one or more steps, such as checking out source code, restoring dependencies, compiling an application, running tests, or publishing build output. The pipeline specifies those steps, while the agent provides the environment in which they run.

The term describes who manages the execution environment, not what the pipeline is designed to do. A hosted agent is assigned work through an agent pool and runs within the capabilities and configuration of that pool. Its operating system, installed tools, and access to other systems can affect whether a job succeeds. Teams remain responsible for configuring the pipeline, protecting credentials, and ensuring that the job’s dependencies and access requirements are appropriate.

When a pipeline runs, Azure DevOps schedules each job to an eligible agent from the selected pool. The agent prepares the job, carries out its steps in order, and reports status and diagnostic information back to the pipeline. If a pipeline contains multiple jobs, they may run separately or in parallel, depending on how the pipeline and available resources are configured.

The job may use tools already present in the selected environment, install dependencies during execution, or consume artifacts produced by another job. These choices affect both reliability and troubleshooting. For example, explicitly restoring a package or specifying a tool version can make the pipeline’s requirements clearer than relying on an assumed machine state. The available images and tools can vary by pool and service configuration, so teams should check that the environment still matches the needs of their workflow.

• Infrastructure management: Microsoft manages the underlying compute environment, which reduces the need for a team to provision and maintain its own build machines.
• Job execution: The agent performs the steps defined in the pipeline. It does not determine whether the build or deployment logic is correct.
• Environment-specific tools: Operating systems, preinstalled software, and tool versions depend on the selected pool or image and may change over time.
• Controlled access: Connectivity to repositories, package feeds, internal services, and deployment targets depends on network design, identity, permissions, and pipeline configuration.

The main difference is who operates the machine that runs the job. With a hosted agent, the service manages the underlying environment. With a self-hosted agent, the organization manages the machine or environment, including its setup, maintenance, security controls, and capacity. The choice affects more than infrastructure effort: it can also shape network access, control over installed software, and how teams investigate job failures.

Hosted agents may suit workflows that can run in the environments and network paths available through the selected pool. A self-hosted agent may be a better fit when a job depends on specialized hardware, custom software, persistent local resources, or direct access to systems that a hosted environment cannot reach. Greater control also creates operational responsibility. The organization must keep the agent environment supported, limit access to it, and plan for maintenance and troubleshooting.

Use a short validation process before relying on an agent type for an important workflow:

1. Describe the job’s requirements. Identify its operating system needs, tool and dependency requirements, expected workload, and any hardware-specific steps.
2. Map access requirements. List the repositories, package sources, internal services, deployment targets, and credentials the job must use.
3. Select a candidate pool. Check whether a hosted or self-hosted option can meet those requirements within the organization’s configuration and security boundaries.
4. Run a representative pipeline. Test the build, tests, artifact handling, and any required connections. Include the failure and diagnostic paths that operators would use.
5. Review results and maintain the configuration. Examine logs, permissions, and dependency handling. Revalidate the workflow when its requirements or the agent environment change.

A development team uses an Azure DevOps Pipeline to build a software change, run automated tests, and publish a build artifact for later review. The team selects a hosted agent pool that supports the workflow’s operating system and tools. It defines the needed steps in the pipeline and makes dependency restoration part of the job, rather than relying on packages left on a particular machine.

The tests also download a package from an internal source. During validation, the team checks whether the selected agent can reach that source and whether the pipeline identity has the required permissions. If the connection is unavailable or conflicts with the organization’s security requirements, the team may need to adjust the access design or choose a self-hosted agent with an appropriate network path.

A hosted agent is not automatically a fit for every workload. The available operating systems, tools, network routes, resource limits, and other conditions depend on the selected pool, service configuration, and service updates. Jobs that assume a specific tool version or undocumented machine state can fail when the execution environment differs from what the pipeline expects. For specialized workloads, teams should test the actual job rather than infer compatibility from the agent type alone.

Pipeline execution also involves access to source code, artifacts, credentials, and deployment targets. Treat those items as sensitive: grant the job only the permissions it needs, avoid printing secrets in logs, and review how artifacts and credentials are handled across jobs. Organizations with strict security, compliance, or operational requirements should evaluate the full execution path, including network access and responsibility for maintaining the environment, before selecting an agent.

In Azure DevOps Pipelines, a hosted agent is Microsoft-managed compute that executes the steps in a pipeline job. It can reduce the work involved in maintaining build machines, while giving teams a way to run common build, test, and deployment tasks through a configured pipeline.

The choice depends on the job’s software, network, security, and hardware requirements. Teams should validate the workflow in its intended pool, make dependencies explicit, review permissions, and account for changes in the environment or service configuration that could affect execution.