Why developer portals matter more in the age of AI agents

There’s a growing narrative in the platform engineering community that internal developer portals (IDPs) are "dead." That AI models are so good now, developers don’t need a portal to find things, scaffold projects, or understand their environment. That agents like Cursor, Claude, and GitHub Copilot have made the "alt-tab to a portal" workflow obsolete.

I get the appeal of that argument. It’s clean, it’s provocative, and it contains a kernel of truth. But it also misses something fundamental about why developer portals exist in the first place—and why the agentic era makes them more important, not less.

The kernel of truth

Let’s start with what the skeptics get right, the portal-as-destination model has real friction. Developers don’t want to context-switch out of their IDE to look up a service, find a template, or check who owns what. That user experience (UX) problem is real, and it’s been a legitimate source of frustration since the early days of Backstage.

But here’s the mistake—conflating the UX problem with a value problem. The fact that developers don’t love visiting a portal doesn’t mean the information inside it is valueless. It means the delivery mechanism needs to evolve.

The real value was never the UI

Think about what a well-implemented IDP actually contains—a catalog of every service, API, model, and component in your organization. Golden path templates that encode your architecture decisions, compliance requirements, and security policies. Documentation that’s tied to living systems rather than stale wikis. Plugin integrations that surface real-time data from your CI/CD pipelines, monitoring tools, and infrastructure.

That’s not cognitive overhead. That’s enterprise context. And it’s the single most important input for any agent trying to do useful work in a complex organization.

Agents without context are just confident hallucination machines

Here’s the scenario the “IDPs are dead” crowd doesn’t account for—a developer asks Cursor to deploy their service to production, but without access to enterprise context, the agent has a few options—all bad. It can improvise infrastructure, spinning up resources that don’t follow your architecture standards. It can skip compliance checks because it doesn’t know they exist. It can deploy to the wrong environment because it has no concept of your organization’s deployment topology.

Now contrast that with an agent that can query a developer portal programmatically. It discovers the golden path template for production deployment. It checks the catalog for approved Amazon Machine Images (AMIs) and model versions. It applies compliance controls automatically. The developer never leaves their IDE, but the agent is operating within enterprise guardrails—invisibly.

The difference isn’t the agent’s capability. It’s the context the agent has access to.

The dual-purpose IDP

This is where I think the industry is heading—the IDP evolves to serve 2 audiences simultaneously.

The first audience is the one we’ve always served—developers who visit the portal through a browser. They browse the catalog, scaffold projects, check documentation. This use case isn’t going away. For many organizations, especially large enterprises with heterogeneous environments and hundreds of teams, the portal-as-UI remains a critical onboarding and discovery tool.

The second audience is new—AI agents that consume the same context programmatically. Through protocols like the Model Context Protocol (MCP), agents can query the catalog, discover templates, and invoke plugins—all without a human ever opening a browser tab. The portal becomes infrastructure that agents call, not a website developers visit.

Over time, the balance between these 2 audiences will shift. How fast depends on your organization’s size, complexity, and AI maturity. But the important thing is that both audiences need the same underlying platform—a governed, curated source of enterprise development context.

Agentic portal

Why enterprise complexity is the key variable

The “IDPs are dead” argument tends to come from a particular vantage point, small to mid-size teams with homogeneous stacks, single-cloud deployments, and engineers who all sit in the same Slack channel. In that world, maybe an agent with a good model and some documentation can wing it.

But that’s not the world most enterprises live in. A Fortune 500 company might have 200 teams, multicloud infrastructure, regulatory requirements that vary by region, 15 years of accumulated services, and compliance frameworks that change quarterly. No agent figures that out from first principles. The more heterogeneous and regulated the environment, the more you need a curated context layer—and the more dangerous it is to let agents operate without one.

This is the part of the conversation that often gets lost. We’re not just talking about developer productivity. We’re talking about risk at scale. An agent deploying to production without knowing your compliance requirements isn’t productivity. It’s a very fast way to create very expensive problems.

3 roles of the evolved IDP

As I think about where Internal Developer Platforms are heading, 3 roles emerge:

Catalog of record. The IDP becomes the single source of truth for everything in your development ecosystem—software components, APIs, models, agents, teams, dependencies. This isn’t just a static registry. Through integrations with model registries and infrastructure providers, it stays current. When an agent asks, “what models are approved for production use?,” the catalog has the answer.

Paved paths for AI. Golden path templates have always been about encoding best practices. In the agentic era, they become the instructions agents follow. Compliance requirements, security policies, architecture decisions—all encoded into templates that agents can discover and execute. Humans set the guardrails, agents follow them.

Agent gateway. This is the new role. The IDP exposes its catalog, templates, and plugin ecosystem to external agents through standard protocols. Any agent—whether it’s Cursor, Claude, GitHub Copilot, or a custom-built agent—gets the same governed access to enterprise context.

Context is everything

Here’s the way I’ve come to think about it—humans and AI are equally useless without context. The IDP’s job has always been to provide that context. What’s changing is who consumes it and how.

The developer portal knows where your code lives. It knows your APIs and documentation. It knows your best practices, policies, and development preferences. It knows your systems and processes. And through its plugin ecosystem, it has real-time signals from your infrastructure, CI/CD pipelines, monitoring tools, and incident management systems.

That context is what makes the difference between an agent that’s helpful and one that’s dangerous. Easy access to development context accelerates the entire development process—for humans and agents alike.

What this means for platform engineers

If you’re a platform engineer investing in an IDP today, the good news is that you’re building exactly the right foundation. The catalog you’re curating, the golden paths you’re defining, the plugins you’re integrating—all of that becomes the context layer that agents will consume.

This evolution isn’t about throwing away what you’ve built. It’s about adding a programmatic access layer on top of it. Think of MCP as the API that turns your portal into a platform—one that serves developers through the browser today and agents through protocols tomorrow.

At Red Hat, we're actively pursuing this evolution with Red Hat Developer Hub—we've built an MCP server that exposes the catalog and golden path templates to external agents like Cursor, Claude, and Copilot, with plugin ecosystem access coming next. Red Hat Developer Hub already uses tool-calling to invoke attached tools, and we're exploring how it can delegate complex tasks to customer-built agents. The governance platform engineers have always relied on stays the same, but the audience expands. But this isn’t a Red Hat-specific insight. It’s an industry pattern that every IDP—whether it’s built on Backstage, a commercial platform, or a homegrown solution—will need to address.

The portal isn’t dying. It’s becoming infrastructure.

The skeptics are right that the portal-as-destination model is evolving, but the conclusion that IDPs are dead gets the story exactly backwards. In a world where AI agents are making decisions at machine speed, the need for governed, curated, enterprise-scale development context doesn’t decrease. It becomes the most critical layer in your platform engineering stack.

The portal isn’t dying. It’s serving 2 audiences now—developers and agents. And the organizations that figure this out first will be the ones whose agents operate with enterprise-grade context while everyone else’s agents are confidently hallucinating their way through production deployments.

Try Red Hat Developer Hub.