The Service Catalog Problem Isn't Backstage. It's the Catalog.

Multiple engineers. Forever maintenance. A moving target.

That's the Backstage story at most companies. Two or three people, six months of setup, and then a permanent tax on your platform team just to keep it running. Plugins to update. Integrations to maintain. YAML files to wrangle. PostgreSQL to operate. A React codebase to own. Core releases that break your plugins. Community plugins that go unmaintained. Spotify runs Backstage with a 96% internal adoption rate. Most companies land around 10%. That gap is not a coincidence. It reflects how much success depends on dedicated platform investment rather than the tool itself.

Backstage is genuinely hard to run. That's not a myth engineers tell to avoid doing the work. It's the consistent experience of the organizations that have tried.

So teams switch. Cortex. OpsLevel. Port. Something managed, something with a real support contract, something that doesn't require a platform engineer dedicated to keeping the lights on.

And the catalog still goes stale.

The system that was supposed to tell you who owns what requires someone to own the system.

That should tell you something. The problem was never Backstage specifically. The problem is the catalog abstraction itself. Backstage made it painful and expensive. Cortex and OpsLevel made it easier. But none of them changed what a catalog fundamentally is: a human-authored approximation of system state that starts drifting the moment someone forgets to update it.

The Maintenance Problem Is a Symptom

Backstage gets blamed for the wrong thing. Yes, it's hard to run. But even if it weren't, you'd still have the same underlying problem: service catalogs depend on humans keeping metadata accurate over time.

They won't. Not because engineers are lazy. Because updating a catalog is never the actual job. The actual job is shipping, fixing, responding. The catalog is a side effect of the real work, and side effects get deprioritized.

So the catalog drifts. Ownership records go stale. Services get renamed. Teams reorganize. The YAML file says one thing, the actual system does another. Eventually someone gets burned by wrong information at the worst possible time, and trust collapses. A catalog nobody trusts is worse than no catalog at all. It's confidently wrong.

Cortex and OpsLevel recognized this and built better tools for keeping humans accountable. Scorecards. Drift alerts. Ownership suggestions derived from commit history. They made the maintenance burden more manageable, and that's a real improvement over the Backstage experience.

But they didn't change the underlying model. The catalog is still a human-authored approximation of system state. It still depends on someone remembering to update it. It's still stale the moment reality diverges from what's written down.

The Abstraction Is Wrong

Backstage has gotten better at autodiscovery. Catalog providers can pull in repos from your GitHub org, services from Kubernetes, components from cloud providers. You don't have to manually register every entity anymore.

But autodiscovery tells you that things exist. It doesn't tell you how they relate. Ownership still lives in a YAML file someone has to write. Dependencies are declared, not discovered. Team mappings are manual. The relationships: which service calls which, what breaks when something changes, who actually owns what in practice. Those still require a human to interpret the system and write it down.

Entity discovery is the easy part. Relationship discovery is the hard part. And that's exactly where the catalog abstraction stops.

Then there's the augmentation problem. When your catalog doesn't match how your org actually works: when you need a custom entity type, a non-standard ownership model, a relationship kind that Backstage doesn't have a concept for. You're writing plugins. TypeScript, against an internal API, that you own forever, that breaks when Backstage ships a major release. In managed tools, you're bending your org to fit their schema rather than the other way around.

The catalog isn't just hard to keep accurate. It's hard to reshape. The data model resists the org, instead of reflecting it.

A live knowledge graph inverts this. The graph is built from your actual systems, not from documentation about them. GitHub knows who touches what. Kubernetes knows what's running. PagerDuty knows who gets woken up. The relationships are already there: they just need to be read, not authored. And when your org evolves, you add a connector to where the new truth lives, rather than extending a schema by hand.

It doesn't drift because it doesn't depend on anyone remembering to update it. It changes when the system changes, because it reads the system.

Why This Matters More Now

For human developers, a stale catalog is annoying. Wrong information costs time. You Slack someone, dig through code, figure out the truth. Frustrating, but recoverable. Humans cross-check. They know when something feels off.

For AI agents, stale context is a different kind of problem. An agent that asks who owns a service and gets back a team that reorganized three months ago doesn't know the information is wrong. It acts on it. Confidently. At the speed of software.

This is why Backstage's push toward AI-native features is interesting but incomplete. You can expose catalog operations as MCP tools. An agent can call them. But if the underlying data is YAML files that engineers maintain imperfectly, you've built a fast path to confidently wrong answers at agent speed.

Agents don't recover from wrong context the way humans do. They don't have the judgment to notice that the on-call rotation in the catalog doesn't match what PagerDuty actually shows. They trust the data they're given.

The context layer for agents needs to be authoritative. Not aspirationally accurate. Actually accurate. That means it has to come from the systems themselves, not from what engineers wrote about them.

So What Do You Actually Need

If you're evaluating options, here's a clean frame:

Backstage is a framework. It gives you a foundation to build a portal and a catalog at the cost of significant, ongoing engineering investment. The right choice if you have dedicated platform engineers and want full ownership of the stack.

Cortex and OpsLevel are managed catalogs. They solve Backstage's operational burden with a product you can actually run. The right choice if you want catalog functionality without the DIY overhead.

A live knowledge graph is something different. It doesn't replace your catalog. It eliminates the need for one. The graph is built from your actual systems, not from documentation about them. Relationships are discovered, not declared. It's always current because the source of truth is the infrastructure itself, not a YAML file someone wrote six months ago.

These aren't the same product at different price points. They're different answers to different questions. If your question is "how do I make it easier to maintain our catalog," Cortex or OpsLevel are good answers. If your question is "why do relationships keep drifting from reality even after we invested in a catalog," the answer is that you need a different abstraction.

The Conversation Is Shifting

Developers used to need a portal to browse their services. Now agents need queryable, real-time context to act on them. Those are different requirements. Different data models. Different freshness expectations. Different ways relationships need to be represented.

Building agent context on top of manually maintained records is going to produce the same outcome as building documentation for humans and hoping it stays accurate.

It won't.

The teams getting this right are skipping the catalog entirely and going straight to the graph.

---