How do you set up self-hosted agents vs Microsoft-hosted, and when do you use Kubernetes agent pools?

Think of the three agent types like different approaches to staffing a bank. Microsoft-hosted agents are like hiring temp workers from a staffing agency for each task: they arrive ready to work with standard skills, complete the job, and leave. You never worry about managing them, but they cannot access the bank's internal vault and they bring only generic tools. Self-hosted agents are like permanent employees: they have security clearances, know where everything is, have specialized tools at their desks, and can access restricted areas. But you must hire, train, and manage them yourself. Kubernetes agent pools are like an automated staffing department: when work arrives, it instantly creates perfectly skilled workers from a template, they complete the job, and they disappear. You design the template once and the system handles scaling.

Microsoft-hosted agents are the default and simplest option. Each pipeline job gets a fresh virtual machine from Microsoft's agent pool, provisioned with a standard image containing common development tools, SDKs, package managers, and container runtimes. After the job completes, the VM is destroyed, ensuring clean builds with no contamination from previous runs. Microsoft-hosted agents are ideal for open-source projects, standard build workloads, and organizations that want zero agent maintenance. Their limitations include no persistent state between runs (requiring fresh package downloads each time), no access to on-premises networks or private endpoints, limited customization of installed tools, and job time limits.

Self-hosted agents run on infrastructure you control: physical servers, VMs, or containers in your data center or cloud VPC. You install the Azure DevOps agent software, configure it to connect to your organization, and register it in an agent pool. Self-hosted agents maintain their state between runs, meaning cached packages, downloaded tools, and workspace files persist. This dramatically speeds up builds that have large dependencies. More importantly, self-hosted agents can access internal resources: private container registries, databases for integration testing, internal APIs, and on-premises infrastructure that is not internet-accessible. For banking environments, self-hosted agents often run inside the corporate network or VPC with access to production AWS accounts, internal Kubernetes clusters, and private artifact stores.

Kubernetes-based agent pools represent the evolution of self-hosted agents for cloud-native organizations. Using KEDA (Kubernetes Event-Driven Autoscaling) or the Azure DevOps Kubernetes agent, the system monitors the pipeline queue for pending jobs and dynamically creates agent pods when work is available. Each agent pod runs from a custom container image containing exactly the tools needed for the pipeline, starts within seconds, executes the job, and is terminated. The agent image is built with your organization's specific tools, certificates, and configurations, providing the customization of self-hosted agents with the clean-slate freshness of Microsoft-hosted agents. Scaling is automatic: during peak hours the pool might run 50 concurrent agents, scaling to zero during quiet periods.

The decision framework for choosing agent types considers five factors: network access requirements, tool customization needs, build performance requirements, cost model, and maintenance burden. If your pipelines need to access private VPCs, internal databases, or on-premises systems, you need self-hosted or Kubernetes agents. If builds require specialized commercial tools like mainframe compilers or proprietary SDKs, self-hosted agents with those tools pre-installed are required. If build speed matters and dependency caching provides significant improvement, self-hosted agents with persistent workspaces win. Microsoft-hosted agents have a per-minute cost model while self-hosted agents have infrastructure costs regardless of utilization. Organizations with variable workloads benefit from Kubernetes pools that scale to zero.

The production gotcha is agent security and maintenance. Self-hosted agents that build code from multiple teams create a lateral movement risk: a malicious pipeline in one repository could read secrets cached by a previous pipeline from another team. Mitigation includes running agents in ephemeral mode (fresh workspace per job), using separate agent pools per security boundary, and running agents with minimal OS privileges. Kubernetes agents mitigate this naturally since each pod is fresh. Maintenance is another concern: self-hosted agents must be patched, agent software must be updated, and tool versions must be maintained. Organizations running 20+ self-hosted agents need automation for provisioning and updating agents, typically using Terraform, Ansible, or Packer for image management.