The 3 Roles AI Agents Play in Your Developer Platform — and What Each Demands

The New Stack published a synthesis on August 29, 2026 from a platform team (the article's authors) who, after hundreds of calls with their customers, identified three distinct roles AI agents play in a developer platform: the agent as a user of the platform, the agent inside a workflow, and the agent as a provisioned resource. The value of the piece is that it breaks the fuzzy question "how do agents use the platform" into three clean patterns and shows each demands different platform capabilities — an MCP-first context layer, an orchestration engine with per-agent identity, or a golden path for self-service provisioning. Confuse the roles and you invest in the wrong places.

1. Role One: The Agent Is a User of the Platform

In this role, an agent is basically a user of the platform: it uses the platform as part of its task to read context and run actions. The article notes that when agents first showed up, many companies said they treat their AI agents like employees — and in a development platform that makes the agent just another engineering resource consuming it. A typical case: an engineer asks Claude Code to add an endpoint to the payments service. Before writing any code, the agent pulls the service owner, dependencies, and the standards it must meet from the platform, then spins up a preview environment via a self-service action and runs the tests. This role requires the platform to provide: an API and MCP-first interface, a governed context layer the agent reads from, and a set of self-service actions it can call.

// Role 1: the agent is a USER of the platform. Before
// writing code it pulls service ownership, dependencies,
// and standards from the platform -- via MCP, not scraping.
// From The New Stack: engineer asks Claude Code to add an
// endpoint to the payments service; the agent reads the
// service catalog, then spins up a preview environment.
{
  "tools": [
    {
      "name": "get_service_context",
      "description": "Return ownership, dependencies, and standards for a service. Server-verified.",
      "input": { "service": "string" },
      "output": {
        "owner": "team",
        "dependencies": ["string"],
        "standards": ["string"],
        "state": "current | deprecated | archived"
      }
    },
    {
      "name": "provision_preview_env",
      "description": "Create an isolated preview environment from a branch.",
      "input": { "branch": "string", "service": "string" },
      "output": { "url": "string", "expires_at": "date" }
    }
  ]
}
// "If you get the context wrong, there's a good chance an
// agent will get overconfident and do the wrong thing."

2. Role Two: The Agent Runs Inside a Workflow

In the second role, the agent is no longer "requested" — it is triggered by an event. The agent runs within the platform, sits in the orchestration engine next to the deterministic steps, and becomes part of a full business process. The example from the article: run a nightly scan that flags vulnerable dependencies across 40 services. The platform pulls the remediation agent from the registry and runs it once per service, so every owning team wakes up to an open PR awaiting review. This role requires: an orchestration layer to run the agents, a registry to pull the right agent from, an identity per agent so the action is logged against the agent rather than a borrowed human credential, and a human-in-the-loop step where the risk is significant.

// Role 2: the agent runs INSIDE a workflow, triggered by
// an event, next to deterministic steps. The platform
// pulls the right agent from a registry and runs it per
// unit of work -- e.g. a nightly vulnerable-dependency
// scan across 40 services, one remediation agent run per
// service, so each owning team wakes to an open PR.
const WORKFLOWS = {
  "nightly-dependency-remediation": {
    trigger: { type: "cron", schedule: "0 2 * * *" },
    steps: [
      { type: "scan", tool: "dependency-scan", scope: "all-services" },
      { type: "agent", agent: "remediation-agent", per: "service" },
      { type: "human", gate: "risk == high", approver: "service-owner" },
      { type: "pr", create: true, assign: "owner" },
    ],
  },
};
// The agent sits in the orchestration engine next to the
// deterministic steps -- it is part of a business process,
// not a chat.

3. Role Three: The Agent Is a Provisioned Resource

In the third role, the agent is a resource like any other — along with the LLMs, MCP servers, and skills that come with it. The platform provisions them, governs them, and hands them back, just as it does with a service, a database, or an environment. Example: an engineer needs an on-call triage agent. They pick the model, the tools, and the environment it runs in, either through a form or by describing what they need, and the platform provisions everything — "a bit like a vending machine, with the addition of a well-governed agent." The article's key framing: that makes it a golden path problem — the route that, by default, gets a team a resource the right way. The agent lifecycle needs one: request it, get it provisioned and registered, publish it for the next team.

// Role 3: the agent is a RESOURCE, provisioned like a
// database or an environment. The engineer picks the
// model, tools, and environment; the platform provisions,
// governs, and registers it. "A bit like a vending
// machine, with the addition of a well-governed agent."
async function provisionAgent(request) {
  const spec = {
    model: request.model || defaultModel(request.useCase),
    tools: filterToolsByPolicy(request.tools),
    environment: request.env || "sandbox",
    identity: await createAgentIdentity(request.owner), // per-agent, not borrowed human creds
    quota: { monthlyTokens: request.budget || 1_000_000 },
  };
  await registerAgent(spec);   // agent registry
  await grantPermissions(spec.identity, request.scopes);
  return spec;
}
// The golden path: request it, get it provisioned and
// registered, publish it for the next team.

4. What Each Role Demands of the Platform

Side by side, the demands are starkly different. Role one demands "context correctness": the agent reasons over real, current information from the service catalog — ownership, dependencies, standards, current state — because "if you get the context wrong, there's a good chance an agent will get overconfident and do the wrong thing." Role two demands identity and approval: each agent has its own identity, and significant risk requires a human gate. Role three demands a golden path: self-service provisioning, governance, registration, publication. The article also shares a telling data point: an agent and skill registry was raised by 47% of the organizations they spoke with through early 2026 — the most-requested capability.

5. Code Walkthrough: MCP Context, Event Workflows, Provisioning

The five code blocks in this post map to those demands. Block one defines Role one with MCP tools: get_service_context returns owner, dependencies, and standards; provision_preview_env spins up an isolated environment. Block two declares Role two: the nightly dependency-remediation workflow as an event-driven array of steps, with the agent as one step running per service and a human gate on high risk. Block three implements Role three: provisionAgent() builds a spec — picks the model, filters tools by policy, creates a per-agent identity, registers, and grants scoped permissions. Block four is the governed context layer: policy per agent, every read audited. Block five is the agent and skill registry structure.

// The governed context layer (Role 1 requirement): one
// place agents read from, instead of local context wired
// to each agent in fragile ways. None of them governed.
class GovernedContext {
  async read(agentId, resource) {
    const policy = await this.policyFor(agentId, resource);
    if (!policy.allowed) {
      audit.deny(agentId, resource);
      throw { code: "FORBIDDEN", hint: "no access to " + resource };
    }
    const data = await this.source.read(resource);
    audit.read(agentId, resource, data.version);
    return data;
  }
}
// Same information, connected to agents the governed way:
// one context layer, policy per agent, every read logged.

6. How to Choose: Which Role Is Your Platform Today

Most platforms do not "pick one role" — they evolve in order. Start with Role one (agent as user), because it is the cheapest to bootstrap: add a few MCP tools and a context layer. Then move agents into workflows (Role two), from "called" to "triggered." Finally productize self-service provisioning (Role three). The closing warning is important: many teams solve Role one "one agent at a time by providing local context" — and the same information ends up connected to agents in fragile ways, with none of them governed. The right answer is what that 47% of customers were asking for: one registry, one golden path, every agent governed.

// Agent and skill registry: requested by 47% of the
// organizations the platform team spoke with through
// early 2026. Publish once, reuse across teams.
{
  "registry": {
    "agents": [
      {
        "id": "oncall-triage",
        "version": "2.3.1",
        "owner": "platform",
        "model": "claude-sonnet-5",
        "skills": ["incident-triage", "runbook-lookup"],
        "approved": true
      }
    ],
    "skills": [
      { "id": "incident-triage", "version": "1.0.0", "owner": "sre" }
    ]
  }
}
// "That makes it a golden path problem. A golden path is
// the route that, by default, gets a team a resource the
// right way." -- The New Stack