The Internal Developer Portal in the Age of AI

Context is the constraint, not intelligence

Models are remarkably and increasingly smart. The bottleneck in AI is no longer intelligence - it is context. Give a model the right information at the right time and it will do extraordinary work. Give it too much, or the wrong information, and it will confidently produce garbage.

In large organizations, the context AI systems need is spread across hundreds of repositories, thousands of infrastructure resources, complex dependency graphs, layered ownership structures, and compliance requirements that vary by team and environment. You cannot give all of that to a model. The hard problem is context selection: surfacing the right information, at the right granularity, at the right time. Whoever solves this for a given domain unlocks the actual value of AI in that domain.

The software catalog is the context layer

For software engineering, the catalog inside an Internal Developer Portal (IDP) is the answer. A modern catalog is a curated, authoritative model of the engineering organization: services, dependencies, ownership, infrastructure, deployments, vulnerabilities, compliance posture.

An agent remediating a vulnerability does not need to read your entire codebase. It needs to know which services are affected, who owns them, how they are deployed, and what depends on them. That information lives in the catalog.

As agents become more autonomous, catalog accuracy matters more. Before agents, a wrong service owner was an inconvenience - a misdirected Slack message. With agents acting at scale, bad catalog data becomes a vector for incorrect automated action at scale.

The IDP enriches the ecosystem, it does not replace it

Developers already have AI tools. They use Claude Code, Cursor, Copilot. They work in their IDEs and terminals. They are not going to switch to doing individual coding work from inside a portal.

The IDP's role is to provide context, enforce standards, and offer self-service actions to the tools developers already use. Purpose-built agent products live inside the IDP because they are tightly integrated with catalog data and governed by standards. Third-party tools reach into the IDP for context and guardrails. That is the natural architecture.

Not all agent problems deserve a platform project

In the AI era, "build" looks deceptively cheap - a prompt plus some data sources. The real cost is discovering edge cases the hard way, maintaining brittle integrations, and having no one investing in continuous improvement. For a problem hundreds of other organizations also face.

Universal problems deserve purpose-built products, built by a vendor who has seen them across many organizations and invests continuously in improvement. Organization-specific problems deserve composable platform primitives. Both matter. The IDP needs to deliver both.

What this means for the IDP

The three pillars of the IDP - catalog, standards, and developer self-service - do not need to be reimagined. They become more important:

• Catalog becomes the context layer for AI systems.
• Standards become critical guardrails for both humans and agents. "All services must have an owner" becomes a precondition agents check before acting.
• Self-service becomes a shared action layer. The same building blocks that power a developer clicking "provision a new service" are available to agents programmatically.

What we are building

Maintenance Agent is our first purpose-built agent product: dependency upgrades, security patches, framework migrations, and vulnerability remediation at scale across hundreds of repositories.

Why this problem first? Because it is the canonical universal problem. Every engineering organization of meaningful size deals with it, and the workflows are strikingly similar across companies. It is also deeply tied to the catalog - effective maintenance requires understanding package ecosystems, ownership, CI/CD pipelines, and risk tolerance.

For everything else, the platform is there: APIs, CLI, MCP, custom integrations, data import and export. Solve 80% of customer problems directly. Make the remaining 20% solvable through the platform.

Our view is simple: AI increases the importance of the IDP. The systems that provide context, governance, and operational structure become even more critical when software is increasingly developed and maintained with AI assistance.

‍