Three distinct roles AI agents play in modern developer platforms

Engineering organizations are racing to embed AI agents into their developer platforms, but the ways teams deploy these agents vary significantly. Rather than a one-size-fits-all approach, organizations are discovering that AI agents operate in three distinct roles within the development ecosystem—each with different technical requirements and organizational implications.

Agents as platform end-users#

The most straightforward role treats AI agents as just another user consuming platform services. An agent accesses a developer platform to retrieve information, make decisions, and execute actions as part of its workflow. When an engineer asks an AI assistant to add a new endpoint to a payments service, for instance, the agent first queries the platform for service ownership details, dependency information, and applicable standards before writing code or spinning up preview environments for testing.

This approach requires agents to reason over accurate, current data about system architecture and governance. If context is stale or incomplete, agents risk becoming overconfident and making flawed decisions. Most teams currently solve this piecemeal, supplying localized information to individual agents—a fragile approach that lacks centralized governance. Platforms must expose their capabilities through APIs and Model Context Protocol (MCP) interfaces, paired with a unified, governed context layer that every agent can reliably draw from.

Agents embedded as workflow components#

A second role positions AI agents as active components within orchestrated business processes. Rather than responding to direct requests, these agents execute automatically when triggered by platform events, running alongside deterministic workflow steps. An example: a nightly scan identifies vulnerable dependencies across multiple services, and the platform invokes a remediation agent once per service. Each owning team then wakes to an open pull request ready for review.

This pattern demands several platform capabilities: an orchestration engine to schedule and run agents, a registry to retrieve the correct agent on demand, and individual agent identity so actions are audited against the agent rather than borrowed human credentials. When actions carry significant risk, platforms should enforce human-in-the-loop checkpoints before execution proceeds.

Agents as managed infrastructure#

The third role treats agents as first-class resources with their own provisioning and lifecycle management, much like databases, environments, or services. An engineer needing an on-call triage agent can self-serve: they specify the model, tools, and runtime environment through a form or natural language request, and the platform provisions a fully configured, governed agent—similar to a vending machine for AI capability.