Operations | Monitoring | ITSM | DevOps | Cloud

You've set up the Cortex MCP and connected it to your AI assistant and IDE. You ask about service ownership, check a Scorecard or two, and it works. You're impressed by how much faster this is than clicking through the web UI. Now you're wondering what else you can do with it. I'm willing to bet we've hit a nerve with that "hypothetical" scenario. The Cortex MCP works exactly as designed, but it's deceptively difficult to know which questions to ask and when to ask them.

For decades, engineering leaders have struggled to measure the productivity of their developers. Metrics such as number of PRs merged, lines of code changed, hours worked, and tickets closed were always flawed. They incentivized the wrong behaviors and ignored code quality and best practices. Ultimately, they were the perfect formula to make Goodhart's Law a reality. Measures became targets, which meant they ceased being good measures.

Every December, Spotify launches its infamous Wrapped campaign, which sends millions of users into a frenzy about their listening habits. They become pseudo data scientists and analyze how frequently they listen to their guilty pleasures, their kids' terrible playlists, or the music they love that nobody else has heard of yet. We love this tradition, so we're bringing it to Cortex.

For many engineering teams, an incident is a chaotic, all-hands-on-deck event. Once the incident is resolved, everyone returns to their regular work and the valuable lessons from the incident are often lost. The result is a cycle of repeated failures and engineer burnout, where incidents are something to be survived, not learned from. At Cortex, our mission is to help engineering organizations build a culture of continuous improvement.

Modern engineering teams are shipping more services, managing more complex infrastructure, and moving faster than ever. But this velocity often comes at a cost to the developer experience. Engineers are frequently bogged down by infrastructure complexity, inconsistent tooling, and a lack of clear standards, which leads to cognitive overload and slower cycle times.

The holiday shopping season is a familiar ritual for many. We spend hours researching the best deals, comparing features, and reading reviews to make sure we’re investing in the right things. As we all come to grips with the fact that 2026 is right around the corner, engineering leaders are doing the same thing, but largely in response to the explosion of AI developer tools.

Every growing engineering organization eventually faces the seemingly impossible decision between building a custom solution or buying one off the shelf. It’s a debate that often (and incorrectly) ends by choosing whichever option is less expensive. However, it’s become clear that solving the build vs. buy puzzle boils down to understanding what you want to be good at and whether your internal build is actually unique.

Engineering leaders face a constant barrage of questions that pull them away from strategic work. A team lead asks about scorecard compliance. A PM wants a status update on a migration. Someone needs incident trend data for a quarterly review. Each question is reasonable. Each requires context switching, digging through dashboards, or pinging someone on your team for a report. What if you could just ask?

Everyone's talking about how AI is transforming software development. Teams are shipping more code, deploying more frequently, and getting features to market faster than they could a year ago. The productivity gains are real. But we kept hearing a different story from engineering leaders. Yes, velocity is up. But incidents are climbing, resolution times are getting longer, and code review processes are struggling to keep up.

Businesses today have more access to information about their products and engineering teams than ever before, and the push to be data-driven is also at an all-time high. Engineering metrics can provide actionable insights that help accelerate technology and business impact.