Vitaly Gariev. Photo by Vitaly Gariev on Unsplash. Source: https://unsplash.com/photos/woman-working-on-laptop-in-modern-office-space-XWBULKvaLZ4 (Unsplash License).

Executive Summary

Platform engineering keeps sliding into the same two failures. Onboarding drags because nobody can find the owner, the docs, or the deploy. Change stays risky because nobody knows the blast radius. Internal developer portals are the current answer, and the catalog underneath them decides whether the answer works.

Cortex builds that catalog first. It pulls metadata from running systems, version control, and incident tools, and keeps the map current. The assistant answers from that source of truth rather than from a model improvising. The difference shows. A chatbot trained on stale documentation repeats a wrong service owner with confidence. Ask who owns a microservice, who to page when it goes down, which services depend on it, and which had the most incidents this quarter, and the reply has to match reality. Watch the metadata. A stale portal is worse than no portal, because it teaches people to trust the wrong answer. Ownership stays a human decision.

Every engineering org has the same pain. The answers about a service live in six different places and none of them agree. Cortex is building an internal developer portal with an AI assistant designed to end that confusion.

An internal developer portal is a catalog. It maps your services, their ownership, their dependencies, and their health into one searchable place. Cortex puts that inventory behind a natural language assistant so a developer can ask what the team owns and how it is doing, instead of digging through a wiki.

The catalog is the foundation, not the chat

The piece that often gets overlooked is the data underneath. An AI assistant is only useful if it has something accurate to draw on. Cortex pulls metadata from your systems, your version control, and your incident tools, and it keeps that catalog current. The assistant sits on top and answers questions from that source of truth.

That architecture matters. A chatbot trained on stale documentation will confidently repeat a wrong service owner. A portal that is synchronized against live systems can hold a team to account because the answer has to match reality.

Ask it who owns a given microservice and who to page when it goes down. Ask it which services depend on that service, or which have had the most incidents this quarter. The answers come from the catalog, not from a model improvising.

Why platform teams are pushing on this

Platform engineering keeps collapsing into the same two problems. Onboarding is slow, because a new engineer cannot find the docs, the owner, or the deploys. And change is risky, because nobody knows the blast radius of a modification.

A portal with a working assistant attacks both. Onboarding gets faster when a search finds the answer. Risk drops when the impact of a change is visible before it happens. Both are exactly the metrics platform teams are measured on, which is why the category is getting attention.

It also gives platform teams a way to be more useful without writing more templates. Instead of building yet another document, they point the catalog at the systems that already exist and let the assistant search them.

The catalog also creates a useful audit trail. When a service is missing an owner, it shows up. When a dependency goes undocumented, it gets surfaced. That visibility drives the cleanup work that makes the portal more useful over time, which is a real improvement over docs nobody updates.

The honest limits

Everything hinges on the metadata being clean. A portal that is out of date is worse than no portal, because it gives people confidence in a wrong answer. The work of maintaining ownership and dependencies is the real cost, and it does not disappear just because an assistant answers the questions.

The assistant also does not fix org structure. If service ownership is genuinely ambiguous, the AI will surface that ambiguity, not dissolve it. You still have to decide which team owns what, and that is a human conversation.

Expect some scaffolding work at the start. The first deployments require mapping what you have, and that takes effort on the platform side. Teams that skip the cleanup and wire the catalog directly to noisy sources just move the mess into a better search box.

Expect the churn that always comes with developer experience tooling. A portal works when people use it, and people use it when it answers their question faster than a search engine. That is a habit, not a feature, and building it takes more than shipping the product.

Still, the direction is sound. The question of what a team owns, how healthy it is, and who to ask, should be answerable in seconds. Cortex is betting that the catalog plus an assistant is the way to get there, and platform teams are starting to agree.

Agent infrastructure is the development layer of the AI Infrastructure report, which covers how a model becomes a service with an owner, an evaluation gate and a cost line.

Related reading. Agentic Resource Discovery Wants to Give Agents Their Own DNS. Sovereign Cloud Puts a Border Around Your Data. Treat Your AI Agent Rules Files Like the Code They Replace. AI Infrastructure Runs on Four Layers. Most Break Below the Model..

By Ivan Tarin

Ivan Tarin is a Principal Product Marketing Manager at SUSE, where he owns go-to-market strategy and positioning for a seven-product cloud-native portfolio spanning Kubernetes, virtualization, storage, security, and observability. A former full-stack developer who shipped production code for enterprise and public-sector clients including U.S. national laboratories, Ivan translates complex infrastructure and AI technology into messaging that lands with developers, platform teams, and enterprise buyers. He has presented at KubeCon, SUSECON, and AWS Developer Week, and is currently pursuing an MS in Artificial Intelligence at the University of Colorado Boulder.

2 thoughts on “Cortex Builds an Internal Developer Portal That Answers Your Own Questions”

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the next one before it is old news

Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.