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.