Name: Cortex Demo: An Overview of the Engineering Operations Platform
Uploaded: 2026-04-22T15:01:06.649Z
Duration: 39 min 36 s
Description: Cortex Demo: An Overview of the Engineering Operations Platform

Transcript for "Cortex Demo: An Overview of the Engineering Operations Platform": Hi, everyone. Good morning, good afternoon, depending on where you're dialing in from. We'll give everybody about thirty seconds to get settled, and then we'll get started. Looks like we got some people on the East Coast. Great. Cool. Well, we'll get started here. By way of introduction, my name is Becca Weemhoff. I am a principal sales engineer here at Cortex. I've been with the company about three years and, have worked with a lot of our various customers across different industries. So I'm really excited to walk you all through Cortex today. And I wanna start with something that has been, top of mind for a lot of engineering leaders recently. As you all probably aware, AI coding assistants are writing more and more code, which is rapidly accelerating the software development life cycle. And so writing code is no longer, the primary bottleneck that people are seeing. It's becoming almost a near zero cost. And so the metrics that we're looking at on this page are from the engineering in the age of the AI 2026 benchmarking report. And so what we're seeing is a shift with development velocity being accelerated. And teams are shipping faster than ever, but speed is introducing more and more challenges. And so one of the things that we've started to see or a few of the things we've started to see is that quality is getting harder to maintain. Incidents are also increasing, and governance is inconsistent. But the one piece that is really a true differentiator is the foundational practices are really emerging as that differentiator. So having those true foundations in place are proving to be that differentiator for folks. So as teams are delivering more code, but the engineers are still spending a lot of time on operational overhead. Right? Ticketing, infra, compliance, and governance is something that was sort of a thought in the back of the mind is now really front and center. And as these AI tools are introducing new risks, right, an agent could open 40 PRs overnight, and so now the question is, who owns this code? Does it meet our standards? Is it secure? Am I gonna get paged at 3AM because of this? And so the key takeaway here is to know that operational complexity is rising faster than ever. Before we keep going, I wanna do a quick poll, and you can use the poll on the right to cast your vote to understand kind of where you are today in your AI engineering journey. Give people a couple of moments to take their votes. Alright. Looks like we've got some votes. People are still in the early phases. We've got some folks that are using the tools, but, and tracking the adoption. That looks great. Cool. So as we keep going here, you know, traditionally, engineering orgs are split across different functions. You've got SRE and platform and developer experience. And each of those teams functions, you know, with their own metrics and their own tools and their own sort of focus points. But the reality is is they're all really trying to solve the same underlying problems, and a failure in one area impacts all of the others. And so what we're starting to see is a shift in bringing all of these functions together under what we're calling engineering operations. So treating engineering as a single system and not these separate disciplines. And so Cortex really acts as the mission control for engineering operations. And the way that we break this down is into three pillars. So the first, with providing clarity. Right? Giving you a view into your current state, understanding what's happening across your engineering organization, who owns this, where is it deployed, how are teams doing. That's really the foundation of engineering operations. And then the second pillar focuses on the improvement. Now that we understand the state, how do you actually make it better? What are the shared definitions of what good looks like, and how do we actually help people drive towards that? How do we help you get better at getting better? And the third pillar is really focused on removing friction, making the right thing easy to do. And so providing your developers golden paths that have been preconfigured and help reduce the bottlenecks and the reliance on teams like platform teams and maybe some other folks that are feeling those, ticket queues. And so the key idea here is to measure engineering operations as a whole and not by separate disciplines. And so before we hop into the demo, I wanna take a second poll here and understand what is your biggest operational headache today. Give everybody a couple of moments to vote here. And you may find that multiple of these responses are sort of top of mind. Generally, they kind of all go hand in hand, but if you were to pick one that's really driving your interest in Cortex. Alright. It looks like we're fairly split across all of these, which is great because we're gonna touch on, all of these items today. Cool. So now we're gonna hop into the demo, and I'll start sharing my screen here. And so we're really gonna start with focusing on that clarity pillar. And so what we're looking at here is our engineering intelligence. And the main goal with this is we bring all of your engineering data into one place. So you've got your version control metrics, your ticketing metrics, your deployments, your incidents, and we're doing this by, integrating with all of your tools. And so for years, when you think about sort of the productivity style metrics, right, Dora and space and some of those metrics, those metrics are still very valid and relevant, but there's been a shift from looking at these from an individual productivity lens into more of a team and organizational insights lens. And as we look at things like deployment frequency or incident frequency, You can break this down by team, by group. You can still get to the individual metrics as needed, but really understanding how your engineering org is operating, you need to be able to kind of slice and dice these metrics on a higher level. And so with the shift in AI tool usage, you know, tracking metrics like PRs, when you've got agents opening PRs kind of becomes a moot point. So having this holistic view, becomes a much better focus. And so when you look at these metrics in engineering intelligence, understanding where are the bottlenecks, where is work getting stuck, and you can filter this down by specific team, and you can dive into all of the details as well. Now these are all individual modules that you can put together in a dashboard, but we also offer a number of dashboards out of the box. Something like the velocity dashboard. Right? We connect your tools. All of this data data starts to render, so you don't have to worry about setting any of these, setting any of these dashboards up. They all start to populate once you connect your tools into Cortex. And this velocity dashboard breaks down your cycle time by phase. So you can look at time to open, time to first review, time to approve, time to merge, and understand truly where are these bottlenecks coming from. So we can see here that this time to first review is the largest chunk in our cycle time. So how might you be able to kind of reduce that? And some of these other reports kinda overlay other metrics on top of it. So something like PR size. How does that impact our time to review? And understanding large PRs tend to get put on the back burner. People don't wanna spend time on those. So maybe we wanna focus on reducing PR size in order to get our cycle time down. And so the idea of this is having the full context of multiple metrics and understanding those metrics. We can also look at things like, GitHub Copilot metrics. Not only are we understanding who's using AI tools, but is it act how is it actually impacting our business? Is it improving the speed? Is it improving the quality? Are we seeing an impact on the number of incidents? Are we seeing, an increase in incidents because teams are using AI? And so having the clarity and the view into these metrics, right, you can't optimize what you can't fully understand or fully see. Now with all these dashboards, requires you to go in and look at the metrics and kind of make a decision and understand what's happening. And one of the things that we recently released is an AI Slack, Slack assistant. And so let me pull this up here, and I can show you what that looks like. So in this example, what I did was I asked Cortex, tell me how my teams are doing with their PRs. Is there anything I should be aware of? And so it reached out to Cortex. It got me some answers based on all of my teams. And so this provides me access to insights with no dashboards required. Right? It brings together the signals across your entire engineering organization, and it delivers clear, contextual answers in real time. And the nice thing is this has got context to everything in Cortex. So I can say, explain to me why the review bottleneck is taking so long for this team. And it starts looking into all of the PR details and telling me that we've got no comments and, no first reviews. And so it provides me all of these insights. So there's this shift from kind of passive dashboards to the proactive insights. And what this does is it allows you to make faster decisions. You spend less time analyzing the data and more time actually being able to act on it. Let me hop back here to our demo, and we can continue going through this. So we've taken a look at the engineering intelligence side, the AI assistant in Slack. Now what I wanna focus on is the catalog, which is really the system of record. We're still talking about that clarity pillar. And so when you think about sort of every business function, right, it all has a system of record. Your sales teams have a CRM, so everybody knows who your customers are. Your IT team have CMDBs or ITSM tools, and so everybody knows what devices and tickets exist. HR has an HRIS system, so everybody knows who the employees are. But engineering doesn't really have that system of record. And so what we've seen across many customers over the years is this could typically live in a spreadsheet, that may be, you know, two or three years old. It might be a Wiki or a Confluence page that's outdated and stale, or it might be a dashboard that somebody put together at some point in time. And maybe you need to change something, but that requires a lot of work and takes people off of their day to day tasks. And so when we think about Cortex, this is truly a single source of truth for engineering. What we're looking at here is our catalog, and you can see that it's broken down into various what we call entity types, and these are essentially groups. Entities in Cortex are a single piece of your software components. So everything from your services and your repos to your cloud resources and your teams. And we get all of these into the catalog through integrating with your tools. We've got native integrations with over 50 engineering tools, and then we start to connect the data to actually make sense of it. Here's an example of a service. In here, we're connecting AWS and Kubernetes and Datadog so that we can see monitors and, connecting tools to get security metrics. You can provide links to documentation and runbooks. And so all of this information becomes easily accessible for all of your engineers and your leadership teams. And there's context in all of this. Right? If a service goes down, I know who owns this thing. I know what Slack channels or Microsoft Teams channels I need to reach out to. I can have links to all of the documentation that I need. I can see what was recently deployed. And so as we look at all of this data, what it's powered by is a context graph. And so this connects all of the data and all of your relationships across all of your systems. It connects your services and your teams and your deployments and even your incidents so that you get a full understanding of everything related to this particular entity. And as we think about this, behind the scenes, we're using some AI and ML to help build and maintain all of that context so we can help with mapping ownership and mapping those relationships. And we've worked with hundreds of organizations that have seen and we've seen that the biggest reason that these kinds of initiatives tend to fail is the messy fragmented data. And so we tackle that challenge head on. We really believe that a strong foundation allows you to make better decisions and execute things faster. And one of the core underlying pieces of the catalog is ownership. And I know this was one of the, operational headache answers, so I wanted to make sure we touch on this, is understanding who owns what is really the foundation of accountability. If you don't know who owns something, if something goes down or something breaks, there's no accountability of who's responsible to go and fix those things. And, typically, what we see is this is tracked in spreadsheets or maybe a code owner's file that you've had a reorg and now it's outdated, or it lives in tribal knowledge. Right? Something went down six months ago. I know who owns that because I was here six months ago and I was part of this. And that just is not really sustainable. So with Cortex, we have, an machine learning driven ownership mapping and recommendations page. And so this is trained on thousands of signal types and multiple years of data where we can look at your data and make recommendations on what team should own this based on the data that we are seeing. And what this helps our customers do is go from 30 or 40% ownership accuracy to 80 to 90% right out of the gate. This is one of the biggest pieces of getting started with a tool like Cortex. Understanding ownership helps encompass all of the other pieces of using this tool. And you may have already heard this at some point, but the truth is Cortex is opinionated. We have made hard calls on how ownership works, how the foundational data modeling should be structured. We offer out of the box scorecard rules and workflow templates to really help get you started because we've seen hundreds of companies try to solve this from scratch, and we know what works well and what doesn't. And so what you'll notice as we go through Cortex today is we provide about 80% out of the box. So if we can get you to complete ownership and provide you some scorecard rules and provide you some data modeling to help get started, that provides you getting 80% of the way there. But then we give you the flexibility to kinda customize the rest on top of that through the extensibility side of Cortex. Now now that we understand kind of how everything is structured and kind of the lay of the land and we have the the clarity and the visibility, we wanna talk about how do we actually improve this. And so governance has been sort of the word of the year for engineering leaders, and it's completely critical in the AI world that we live in today. Right? With AI shipping code faster, security reviews, production readiness reviews, all of these were designed assuming that humans were writing the code and doing these day to day tasks. But that's changed. And so how can we help automate this so that teams can move faster? What we're looking at here is a scorecard, and this helps define what does good look like. Cortex was first to market with scorecards. They are a foundational piece of our product. And you'll see here some examples of rules that are defined, making sure that you've got basic documentation, making sure that you have ownership in place. These are all rules that you can define yourself. They use something called Cortex Query Language, which allows you to query all of the data. Everything from your core tools that you've integrated, your any of your custom integrations, any kind of custom data that you want to track, all can be used in scorecards. So you can look and make sure that code coverage is in place, that, SLOs are defined and that they're passing. So you can decide what these, standards should be. And these levels provide clear progression. So everybody's using the shared standards. No team is wondering what is it that I need to be working on, what are our security standards, what do I need to get something production ready. It's all defined in a scorecard. And the nice thing about this is we continuously evaluate these scorecards. They're not just point in time. So something that may be at a silver level today may drop to a bronze level tomorrow based on the data that we're seeing. And you could also make these rules actionable and provide guidance as to how to fix it, how to get it to a place where it's better. And this is where it gets interesting with the AI story because scorecards can really become your guardrails for any of your AI generated code. Does it have tests in place? Does it have observability built in? Is it meeting our security standards? Do we have ownership defined? All of these are rules that you can implement inside of the scorecards. As we're continuously running scores, we're going to provide updates so you can see what are the things that I own, are they meeting those standards, how does this compare against my peers, Drive a little bit of that competitive nature. And then we also provide a bird's eye report. And so this allows you to take that, you know, thousand foot view and understand where are the gaps? Where are we not meeting those requirements, where do we maybe need to focus some more time. And these reports can be grouped by teams, by domains. You can decide how you want to break this down, but it gives you a roll up of how are we doing overall, and then how does this break down across teams? Where am I seeing some of these low scores, and how do I get to the bottom of understanding what we are missing? Here, we can see a lot of these rules are being missed from this one entity in Cortex. We can see who owns that, and then we can start putting practices into place and using these reports in meetings and making sure that people are aware of them. Once you see those areas that are gaps, the risk to the business, you can actually build the initiative process into Cortex so that you can keep track of all of these initiatives. We kinda think of initiatives as a little bit like TPM in a box, things that you might have traditionally used spreadsheets to track for. Right? Constantly tracking people down and finding out have they completed this. Initiatives are a great way for you to put a deadline on when you expect an initiative to be completed, and then we are constantly running this against the data. So something that might meet an initiative today, the data might change, and tomorrow, it's no longer meeting this requirement. We can also meet your engineers where they're working, so we can open tickets for them and close them out once these initiatives have been met. We can send notifications through chat ops and emails so that they're aware of these initiatives that everybody is working on. And so as we think about scorecards, it really allows the governance to become scalable and automated. Now that we have kind of discussed that second pillar, I wanna move on to talking about the third pillar, which is really reducing friction. And this comes from, the self-service automation side of Cortex, which is our workflows. Traditionally, workflows, or processes that have to happen, internally are opening tickets and waiting for teams and maybe going back and forth and iterating on the things that you might need and the information that your platform team might need. Workflows enable that self-service automation and really help reduce that bottleneck. It allows developers to get what they need instantly, and it allows platform teams to escape all of those ticket queues. You'll see some examples here, things like deploying to production, provisioning infrastructure, new service creation, rollbacks, access to new tools. All of these are great examples of what you can use workflows for. I'm gonna show you an example here of creating a new Flask service. So this is the end user view. I can determine which workflow I want to run. I can see all of the steps that this workflow is going to run through. And as I run through it, it'll start using kind of like a form builder to ask me some details and ask me for some information. And I'll go through and input some of these details. And what I'm gonna show you next is sort of the backside of the workflow itself. So how this workflow is actually structured is daisy chaining steps or blocks, what we refer to as blocks, together to make sure that each of these steps is happening within the workflow itself. And you can see that we can embed best practices into these workflows to make sure that, you know, Jira projects get created and the right info gets provisioned and that you have ownership in place so that when you run through these workflows, at the end, you're getting a service that has and is meeting those requirements that you already have defined in your scorecards. You'll see in here, lots of different blocks available to help get you started. This kinda goes back to that 80% out of the box, 20% customization on top of it. And so we can utilize your preconfigured integrations to, take action in some of those external tools. We also have our core blocks that allow you to make some of those more generic API calls to maybe some of your homegrown tools if you're using something like Terraform or you're using another orchestration tool. We can build in things like manual approvals. Maybe you want infrastructure provisioning to be approved by a team. That still reduces the bottleneck because it's just a checkbox to say it's been approved rather than needing the platform team to go and provision some of those things themselves. We can also do things like branching and conditional logic. So you can make these workflows as complex as you would like them to be. And so as we think about workflows, right, and the state of AI in the world that we live in today, we're seeing customers start to integrate their AI agents with our workflows. And so you can think about humans defining the outcomes and then the AI and the workflows actually executing together to make those outcomes possible. You've got scorecards to help validate the governance, and then you've got the catalogs, the stores, the records for everything that gets created through these through these workflows. And so when you make these golden paths the easiest paths to people for people to follow, it also encompasses all of those governance, requirements, and it makes their day to day much easier. So we've covered quite a bit of information. As we wrap up here, I want to just highlight that, you know, Cortex is truly an end to end engineering operations platform, and it's going to help you improve your engineering organization across the full software development life cycle. If we go back to these pillars, Cortex is going to provide you the clarity through unified data and insights into your data. It's going to provide you the ability to drive improvement through scorecards and governance, and it's gonna give you the ability to reduce the friction of day to day tasks for developers through workflows and automation. And we really want to think of engineering operations as a whole discipline. And the cortex is really built for a world where the way we write software is changing faster than most organizations can keep up. The competitive advantage is no longer just writing code. It's how well you operate engineering at scale. How fast can you make good decisions? Are you consistently meeting your standards? And so companies that move faster, maintain standards, and reduce that friction are gaining a competitive advantage over time. With Cortex, we wanna help you get better at getting better. I'm gonna stop here, and I am going to open it up for some q and a. So I can see some questions in here. Can we trigger workflows via API? Yes. We are actually currently working on that. So, that is something that, should be available shortly. Looks like we've got another question here. I'm curious what changes you have actually seen customers experience after adopting Cortex. Great question. Yeah. We've got a lot of different customer stories available on our website, so I definitely recommend checking those out. But a couple that come to mind, H&R Block, they reduced their MTTR from, I think, twenty four hours down to less than an hour, which actually eliminated about five days of work, during their peak season. We also have other customers that had reduct 50% reduction in cycle time, significant improvements in, RDS and Kubernetes migrations. So a lot of sort of time saved in some of those ROI metrics that you'll see. We've got another question here. How does this work in large enterprises where standards are varied across teams? That is a great question, and it that's also very common something that we very commonly see. Cortex will meet you where you are today. So, for example, if you have teams that are kind of working against different standards, you can build different scorecards for those teams. We can filter down scorecards. So if you want each team to kind of work against their own standards, that is definitely possible. You can start with standards by a team, and then if you are trying to move towards more unified standards, kind of work that in over time. I see another question in here. Let me see. If if we use this for production operations such as deployments and rollbacks, it becomes a critical tool. What SLAs do you provide? Yeah. We'll be happy to follow-up with, more details around our SLAs. I think that's something that we can follow-up with, following the webinar today. And can we get the same I insights with GitLab Duo adoption usage? Great question. So we are working to add more adopt AI tools and kind of adoption usage metrics into Cortex. With engineering intelligence, you can also bring in what we refer to as custom metrics. So that will allow you to essentially track any metric but we can definitely follow-up with some more details on kind of where the GitLab integration is, for those adoption and usage metrics. I think oh, we've got one more. Do you support enterprise SSO such as Google G Suite? Yes. We do. So, yeah, SSO is kind of standard for integrating with Cortex and how our customers get in. We support Google. We support, Microsoft Active Directory, which I think they've renamed recently. We support Okta. You can really integrate any OIDC, provider into Cortex for SSO. What user security model does the does this have to limit the least privilege? Yeah. So we have, RBAC capabilities built into the platform, so you can limit what users have access to, what for example, like, we've got RBAC built into workflows as well, so only certain people can run certain workflows. There's various RBAC built into, into Cortex. Do you have a scorecard that evaluates GitLab CI references for version currency across a large repo set? I'd have to check exactly what the GitLab rules are. I can't remember off the top of my head. You can access our demo instance from our website, and you can go into the CQL explorer to to check out exactly what the rules are. But we do have very advanced rules for, version control. We can parse through files. We can look through, all of your, files in GitLab and, look at your pipelines. So I'm I'm sure that's possible, to do in scorecards. For long term accuracy, how do we avoid catalog data going stale, especially if teams use the UI to manage data? Do you recommend GitOps as the source of truth? And if so, is the best practice per repo cortex.yml or one central repo? Great question. So when folks get started, we typically recommend using the Cortex UI to get familiar with Cortex. Once you get a familiar understanding of the data model and how things work, Most of our customers actually manage Cortex through GitOps. When you toggle on GitOps, it disables, the UI configuration, and you can do that at, an entity level. So you might manage your services through GitOps and your, you know, AWS resources through the Cortex UI. So you can break that down. With the data, we're integrated with all of your core tools. So if something changes in your version control or your ticketing ops, all of that is going to get updated inside of the catalog. If there's an incident, that's gonna get pulled in. If any of your security metrics change, that's gonna get pulled in. We're updating all of this data, continuously. Each of the tools is a little different for how frequently we pull the data. For tools like GitHub and GitLab, we're pulling more frequently than something that maybe, might update only once a day. I think we are done with questions. Lots of great questions in here. We can definitely follow-up with some additional information. But before we wrap this up, I have one final poll question here, which will be what would be the most valuable for us to follow-up with following today's webinar? We do have a, book a demo link that is available. So if you're interested in booking a demo, definitely feel free to click that link, and someone from our team will follow-up with you, a little bit later today. Well, I wanna thank you all for your time. I appreciate all of the questions, and I look forward to hopefully speaking with some of you soon. Enjoy the rest of your day.