# Capital One's AI Governance and Risk Framework

**Podcast:** Dev Interrupted
**Published:** 2026-11-10

## Transcript

Welcome back to Dev Interrupted, brought to you by Linear B.
In this episode, Linear B co-founder Dan Lyons talks with Abhijit Bose, Senior Vice President and Head of Enterprise AI and ML Platforms at Capital One.
Dan works with a lot of engineering leaders in regulated enterprises, and this conversation is a showcase of how governance becomes an amplifier for teams.
But to get there, we have to set the stakes.
Capital One is a bank after all, so it understands risk.
Now, Abhijit's team is turning that instinct on software, building a risk software for code headed to production and for the steps an agent takes along the way.
And how does a bank stay at the frontier of AI anyways, with what Capital One calls the speed of well-managed?
Well, you're about to find out in Dan's conversation with Abhijit.
Hey, what's up, everyone?
Today's guest is Abhijit Bose, Senior Vice President and Head of Enterprise AI and ML Platforms at Capital One.
In this episode of Linear B's AI Enablement Series on Dev Interrupted, we're picking back up the story on Capital One from earlier this year when we had Amish Palazia on the show to talk about AI adoption.
Abhijit is going to share how Capital One takes an AI-driven approach to building software, governing and instrumenting its own multi-agent systems on one enterprise platform and the lessons learned that take a pilot to lasting value.
So Abhijit, thanks for joining us today.
It's a great pleasure, Dan.
Big fan of the show.
Yeah.
Oh, thanks for saying that, man.
Awesome to have you on.
And, you know, we looked up, obviously, a lot of background about you and the really, I think, interesting stuff that's going on at Capital One.
And obviously, I think the whole world, like all engineering leaders, VPs of engineering, CTOs, we're all going through this AI transformation one way or another.
And so I just wanted to start us off by asking, you know, what's kind of top of mind for you right now as you change how your teams build with AI?
And what did that like same type of work look like maybe a year ago compared to now?
So first of all, you know, I have been doing AI ML for like almost more than 20 years.
And I have never seen a time like this, as we all know.
You know, AI is a huge business transformation for us.
Every company is going through that phase change.
For us, you know, when it comes to AI, it's like, how do you scale AI in a regulated enterprise like banking?
That is really important.
How do you, like we have a saying inside the company, like how do you stay at the frontier of AI with the speed of well-managed?
And, you know, you don't want to get slowed down.
But at the same time, how do you transform your basic, you know, risk and cyber systems?
As you know, like if you have to unleash a bunch of agents within your environment, it's not just enough to create a runtime, you know, to let the agents work, but you have to worry about which tools they will access, you know, what modifications they can make to the file system and all that.
So we have to think through a lot of those things to...
really scale AI within the company.
Just between last year and this year, personally, you know, my workflow has changed.
I think most people's workflows have changed.
We are seeing so much AI first, you know, kind of mindset, like, and often the work itself has changed, you know, like code generation, for example, it's way more automated than, you know, even where we were last year.
But now human judgment is still quite important.
Like how do you pick the right intent?
How do you experiment more?
Where do you have the developer still engage with the AI?
For example, designing the harness properly, designing the agentic loop, guardrails, a lot of those things are more important than last year.
So it's been a profound change.
I think it's going to change how We build products, how product managers, engineers work together.
You know, the lines are even blurring in some cases.
So very fun and interesting times that we are living through.
That's super cool that you've been doing this like 20 years, right?
I think that's what you mentioned about like 20 years and probably in the last like two, three years.
I don't know maybe what was happening for the first 17 years, but there's been probably some rapid developments in the last, I don't know, two years or so.
And you brought up so many great topics.
Let's see where we dive in because you talked about, okay, speed versus quality, right?
You also, I mean, and I think what's pretty cool, we have a whole topic on this is you're in a regulated industry.
Like a lot of the customers that I work with, yeah, different banks or financial institutions, we call them kind of like these large regulated enterprises, which a lot of our listeners are in.
It's almost like you have an extra constraint that we're going to need to dive into it too as well there, right?
But I think maybe where we'll start is let's start on that maybe like speed and quality side or something around there.
Where do you see the biggest gap today, maybe between where engineering organizations might think they are with AI versus the reality?
One thing that I just want to throw in here, at least the ones that I'm working with and some of the data, a lot of the companies right now, there's a ton of code generation going on.
Code generation, code generation.
I think a lot of us are there now.
But one of the gaps when I'm talking to engineering leaders is I'll ask them, well, how much of that is actually making it out to production?
And how much is it making out like in a high quality way?
And sometimes they'll have a tough time answering that question.
They know that there's a lot of agentic cogeneration going on, but we don't know exactly what's happening after that.
And that's where I see a bottleneck.
What are you seeing in terms of like, okay.
Kind of like the reality versus perception with the AIS DLC.
So, you know, last year or even like earlier this year when we turned on, you know, like one of these agent decoding tools, you know, Cloud Code, for example, we saw a huge rise in AI generated code and everybody jumped in.
I think the biggest gap today are actually in a few different places.
One is the outcome.
you know so we are yes we are generating a lot of code um every company you know all the engineers are probably more productive they're experimenting more but does it you know result in faster product delivery you know does it result in more features you know like enriching you know enrichment of the product itself i think those are the things that we are starting to measure uh like what's the how do you tie the outcome of, you know, SDLC or PDLC with the all of the AI enablement that's happening today.
So token maxing is not the right, you know, for example, like the right metric.
Yeah, we're beyond that now.
I think we moved past.
We were at token maxing for a bit.
I think we moved.
We're beyond that now, hopefully.
I think we are beyond, it's actually the reverse problem now.
We're all trying to figure out, you know, how to manage.
Save the money.
Optimize, right?
The cost of tokens.
But I think the outcome is going to become like a really solid measure that every company will be, you know, probably putting in place.
So we are probably a little bit ahead of other companies because we are starting to put those.
systems in place like measurement systems.
The second gap that I see is that a lot of companies probably developing a lot of AI applications, including they're deploying a lot of agents, but they are not putting the time or resources into evaluation frameworks.
So the evals have become like the core focus area for us.
This year, we have been very serious about putting together the evaluations frameworks and eval infrastructure.
We'll continue to invest more next year to the point that these days in our software enablement framework, all the coding tools, all the different harnesses that we put in, every change now goes through an eval with our both custom datasets.
for benchmarking as well as industry you know benchmarks that we run so that way we can do good trade-off between different models you know different uh harnesses uh and we want to codify that you know before we put in a particular harness uh into production into the hands of our users i want to know like what it will cost me in terms of tokens you know what the latency would be what the quality threshold would look like.
And so we are getting better and better at that.
So I feel like that's not always, it has not always been true for us also, but I feel like those are two big gaps.
Yeah.
I mean, and it sounds like, you know, you are, yeah, you're probably more mature in the way that you're thinking about it, I think, than most, especially with the evaluation framework.
I think we were probably previously at a time that it was like, hey, Let's just make sure AI is generating a bunch of code.
And, you know, it sounds like from talking to you here, you went through that phase maybe a little while ago.
I would love to hear about the evaluation framework because that's maybe the next step here.
And hopefully, you know, you probably have quality in mind when you're thinking about it.
But tell me about the evaluation framework.
And then also tell me, you know, what...
metrics or if you have any, do you need to report on?
Like, do you report, you know, the results or like the efficiency and the cost back to the business?
So with AI cost, we have a slightly different approach.
You know, we don't, you know, like we are not like top down in terms of like, oh, you have to manage your AI cost, you know, this way or.
You know, in some places, you know, there is like a strict limit on how many tokens you can use and all that.
So we are not there yet because we feel like this is a long-term investment and we are in a phase where we need to do a bunch of experiments to try out different models, you know, different ways of working, even to train all of our associates, you know, with AI.
We need to have those investments today.
So we are not tracking the cost as a strict measure, but we do, of course, track our token usage and all that.
And we try to understand why some people are using so many tokens, like what's the outcome of that?
Or is it just taking an entire GitHub repo and putting it into the context window?
So one of our recent products actually came out of because of that.
thing that we saw that a lot of people are not using the context window efficiently so we started building our own context retrieval engine that we are going to roll out to the entire company now so but going back to the eval we have the genui platform this was you know put in place about two years ago now with the rag as the only use case the first use case now we have a full set of capabilities on it One of the things is to be able to do evaluations.
Part of that, we have our own SDK that you instrument an application end-to-end, and that puts all of the data from that application from the FM hosting, like LLM hosting, multi-turn agentic loops to data coming from the tools.
All of those things get...
put into a lake that we manage on behalf of users.
We're tracing IDs throughout so that you can concatenate all of those events into an end-to-end view of how the application is doing.
And then for each application, we define a set of metrics.
If it's a document summarization agentic workflow, there are metrics like how many documents, what's the retrieval accuracy.
You know, if it's reading like OCRs, you know, there are like precision metrics that we can come up with for that particular use case.
And then we have a, so there are like a bunch of pipelines that people have to build for that application with our, you know, starter kits that take the data and build those insights.
And then we have, we are not fully there, but we have a visual way of seeing.
all those metrics on a dashboard.
And then we use a third-party packaging, you know, like package software to do that as your kind of front door to see how your metrics are doing, both during designing the agent, like offline, before you deploy, and then once you deploy, it gets the data from the production system.
So, you know, it seems like it...
It's quite advanced, but I will tell you that it's a work in progress.
We have done this for a few major use cases that we have shaped.
Now we have to democratize it for the whole company so that my team and I, we are not in the user journey here.
It should be all self-service.
So that's the work that we have to do over the next few months.
I love it.
I love it.
That's so cool.
Actually, I mean, Capital One sounds like a good place to work right now.
This sounds fun, right?
It is.
It is quite fun.
Yeah.
We have been very lucky, by the way, with our talent.
That's awesome.
Yeah.
I mean, first of all, I like what you said.
I mean, you got to spend money to do these experiments.
Like AI, everyone is trying to save right now, but AI costs money.
If you want to change a workflow and to be more like AI driven, like you got to pay to play.
A lot of our customers come in, they want to talk to me about the cost of different models, comparing the different models, the cost of tools.
How do I bring down the cost?
That's usually like one part of our conversation that I'll help with.
But yeah, on the flip side, you do got to spend if you want to innovate and get to where you are and do these tests and that type of thing.
And you were just talking a lot about context.
You said you were building, I think you're like almost building a context layer or maybe a data lake.
One thing that we're doing at Linear B, at least for our customers, is actually sending their agent context.
We usually send things like incidents found in production.
Is there a live incident going on?
What's the rework rate of the code area?
Is there anything going to get merged?
All this like additional context that we're able to look at.
And these are the things that allow an agent to say, okay, maybe I don't need to work as hard.
I'll select a lower effort or I'll change my model.
And that's been pretty effective.
Like I think that's going super, super well.
I was wondering for you, what type of context do you, if you're able to tell us, like what type of context do you put into your data lake?
Are you trying to send to your agents to be more optimized right now?
two distinct kind of groups of use cases you can think of in terms of context.
One is of course software development.
You know, that's where we have GitHub, Jira, Confluence, you know, all the Google Docs, PDF files for, you know, PRDs to technical specs and all of that.
And more recently we are seeing that, you know, Slack actually becomes a lot of source for good context.
A lot of the Slack channels that people put in for, you know, like SRE functions for a platform.
Yeah, like all the alerts, alerting and information that gets sent there.
Yeah, yeah.
And kind of knowledge sharing between, you know, SREs, you know, they're using Slack channels.
So all of that, you know, for software, for other types of agents, you know, for like traditional document processing, back office.
risk, you know, a lot of other multi-agentic frameworks, they are, it comes in two forms.
One would be the APIs that they are calling, you know, so all of the information, we are lucky to have a central point, you know, where all of our APIs are registered and orchestrated.
So we can...
index all of that information beforehand and essentially only supply the needed information to the agent on the APIs and tools that they will be calling.
And then the other information is the business logic, like the business policy.
Like if you're in a call center and you are deploying an agent API application in a call center, there are so many operating manuals where the business logic policies are encoded.
And some of them are compliance, you know, like how do you handle a particular call or a situation and all of that.
So all of that also get indexed.
And then, you know, we have this multistage ranking system that takes all of this information, does a re-ranking over all of the chunks that it retrieved.
And then finally, the top end chunks are sent to the agent.
And then...
that eventually the harness packages for the LLM to process.
So that's kind of the way it works, you know, among the different use cases.
That's super cool.
I mean, I think we all know, but it's like context is king.
These agents, they work so much better when they have the better context, can save money, quality increases.
So I really appreciate you kind of breaking down how you think about it.
I think that's really important for the audience.
I have a note here that you've built your own multi-agent workflow.
Yes.
We'd love to hear about that.
And also in particular, what parts of your SDLC are actually running agentically today?
Do you have agents talking to each other, passing off work?
And also, on the more humble side, What do you not have running with agents?
What's been really hard for you?
Yeah, so that three-part question.
So let me answer the multi-agentic framework, what we call Macau.
And frankly, I think we were the first company to actually put a multi-agentic framework in front of customers back in 2024.
you know, when there were not too many multi-agentic, like, you know, customer facing applications.
So it's a very general framework where there is an understanding agent that works with a planning agent.
And then these two agents work with the user to disambiguate the intent, you know, so they go back and forth between the user and the understanding agent and the planning agent to fully create a plan.
And then there is an evaluation agent that actually verifies the plan and it runs some sandbox to check the tools that the plan, you know, generated to be called by the LLN, for example, of the agent.
And then finally, there is the actual, you know, like response agent that will either go back to the user or actually take the action on behalf of the user.
You know, for example, if I say like book this, you know, time with my, with the, with the dealership, like for a car dealership, for example, it will go ahead and try to call the, you know, booking API with the dealership to, to set a time and date for your visit to the dealership.
So we built a bunch of applications actually with this generic framework.
The first one was the.
in our auto business, you know, like called Chat Foncierge.
So a lot of dealers in, you know, in North America now have this thing on their, either on their app or website.
It looks like an assistant.
You can browse cars.
You can ask anything about, you know, cars, different cars, different choices.
And you can say like, you know, I want to test drive this particular car, you know, please give me a time and date and it will book the car.
book the time for you and all of that.
Not many people realize that it actually runs on our GNI platform on the back end.
No, that's cool.
I had no idea.
A lot of the interaction happening in real time.
And when we first shipped it, I think 12 second latency.
So literally 12 seconds will go by before you got a response bad.
But nowadays, we are targeting for less than a second.
latency.
So we have come a long way.
That's the other point I was going to make is that deploying an application is easy, but to scale it and to make it really useful to our users with multi-agentic frameworks, with multiple LLM calls, it's actually very hard.
So to the point that we had to build our own model and we had to build our own inferencing stack to actually make it possible end-to-end.
This episode is brought to you by LinearBee, the engineering productivity platform.
Your agents now ship more code in a week than your team has hours to review.
And on November 18th, we go live with a walkthrough of LinearBee's new agentic studio, built to deliver outcomes when human attention can't keep up.
Co-founder Dan Lines opens with why we rebuilt LinearBee around context.
Then the product's team shows it working.
I'm hosting with Jamie Burse, and we're saving the last 10 minutes for your questions.
So be sure to save your seat.
And if you can't make it live, register anyways, and we'll send you the recording and the assets afterwards.
Link is in the show notes.
That's interesting.
This one is, at least the example you gave, there's a user waiting on, it's real time.
There's a user waiting on the other end, right?
So 12 seconds, you know, it maybe doesn't sound that much.
You can imagine the waiting version of our product, yeah.
12 seconds is kind of a lot when you're thinking, okay, I'm waiting for the response, right?
So you have to scale that.
Okay.
And I didn't even realize that the way that you've built this, it's more like a generic system, right?
That you can apply to, you gave one use case of the book.
Okay.
Yeah.
Yeah.
So we have done this for document summarization, you know, document processing.
It's becoming quite a nice generic framework for us.
I would say Jensen in 2025 actually featured this in GTC as one of the few frameworks that are out there as a generic multi-agency framework.
That's awesome.
Are you using this?
So I understand like, okay, hey, this can be used in an actual app.
you know, interacting with you.
Are you using this in your SDLC as well?
Or like for your internal development?
Okay.
Yeah.
Not yet SDLC, but a lot of the customer facing use cases and even internal other use cases, non-software like back office, you have been using it.
Yeah.
To come to your other question, you know, like whether there are multi-agentic frameworks in SDLC.
There I have one example where we have built essentially a pretty elaborate code review system that does a bunch of things, where one agent will look at your, for example, architectural integrity of your code.
Another one will do a cyber review.
Another one will do stylistic checking of your code.
And these agents...
also have verifier agents, you know, they will check and then finally your PR will be approved, you know, or at least get the first pass through this system.
And then eventually, you know, it will go to a human.
We are still in the human in the loop for our software deployment.
But, you know, we do a...
AI first review of the code base, particularly the PR, before it goes to a human.
This is what I'm seeing.
Actually, what you just said for a lot of the, I would call them like the enterprises or maybe the regulated industries were right there where you said, hey, there's a human in the loop, which means, okay, we...
probably use a bunch of AI to generate the code.
Now we do our AI code review.
Maybe I have something built in house.
Maybe I'm using one of the popular review tools.
But right there is where I see a lot of companies saying, maybe we're not ready to go fully agentic.
We still need a human in the loop.
Now for you, is that something to do with the governance or the sensitivity around being in a regulated like financial or do you see it as something that hey we can't fully trust ai yet like where does that all sit for you that you know you feel like you need the human in the loop still i i don't think it's a trust issue but you know we do have a higher bar you know when it comes to governance that we want to be absolutely sure of something, you know, that would be operating in an automated manner.
So we have to convince ourselves that, you know, we have taken into consideration all manners of risk, you know, and there are areas where we may not, you know, always have an autonomous system.
You know, those things will always be human in the loop.
But the biggest gap that we have today is that when you have a piece of code and you want to deploy to production, what is the risk of putting that code into production?
Would it cause an outage?
Looking at similar code bases, looking at similar outages, looking at that type of application, how many users are going to be impacted by that particular change?
Those things, depending on the scale of it, will have a higher bar.
In some cases, there might be a human in the loop.
In some cases, we might let that go automatically to deployment, maybe behind a feature gate, and then the feature gate would be the last, you know, human in the loop stage, but the rest of it would be automated.
So that's where we are.
Like we are literally doing a bunch of experiments to figure out what's the risk, you know, level associated with different types of tasks that we do.
And what's the best way to mitigate that?
And, you know, in some cases, as I said, always human in the loop.
In some cases, you know, there could be opportunities to automate, you know, certain deployments.
That's so funny that you said that because, yeah, at Linear B, that's exactly what we're working on.
Like the pain point for most of our customers is what you said.
How do I do an impact and risk assessment of this code that I'd like to get to production?
I'd love most of our customers would love to be in a situation where there doesn't need to be a human in the loop.
But oftentimes, depending on the risk score, I may need to route it to a human for review or to a security team or maybe multiple people.
That's where I think like the I would say the next pain point is.
for the industry.
It sounds like you're doing something maybe built in, like you're doing your own risk assessment or impact score and then routing it.
Is that, are you doing a build in-house?
Yeah.
We are building that risk scoring infrastructure right now.
And then when you couple that with long running agents in agent runtime, for example, on the cloud, it's not just the deployment, you know, because the agent has to run that risk scoring depending on the step in the process, and it's not just deployment, it's a step in their workflow might come back to the human to escalate, to approve something, and then it can go about its way to do the next task for a few hours.
So we looked at this problem holistically, and we realized that there needs to be a risk scoring thing here, whether it's a long running agent, short living agent, deployment.
So for us, it's all about risk scoring.
And we are a bank, so we understand risk.
This is your specialty.
A lot of IP around risk scoring, yeah.
And when you have good telemetry, you can bring in a lot of data to bear into that risk scoring process.
Like what exactly happening in our production environment, you can be really...
good at predicting risk of something, the next step in the process.
Yeah, I mean, that's the context, right?
That all comes back to context.
Do I know what's happening in production?
Are there any live incidents?
What's the sensitivity of the code?
What or who built the code?
That's where I think if the teams that I'm seeing that are focusing on getting more and more context.
to each decision point, better outcomes tend to be happening.
It's kind of like a general observation that I have.
And it seems like you kind of have the same mindset.
If I know what's going on in production, I know what's supposed, the more live data that you have coming in, probably your risk score will be better.
Yeah.
But you know, what I have come to understand, you know, throughout, through this process is that if you have central platforms, that's such a blessing.
A lot of companies have two or three of the same thing because of different lines of business or just historically, they may have- Yeah, perjures and acquisitions, lots of different, yeah.
Yeah.
So at Capital One, we have most of the major kind of work is done through central platforms.
So our founder basically calls us a platform company.
And that actually really helps when you are deploying agents in AI because you have to do telemetry once, you know, you have to do the integration once.
So I think that's a big sloper in AI.
Yeah, I totally agree.
I mean, instrumenting, let's call it like the software factor.
Instrumenting is tough, especially when you have disparate.
The more centralized you can get, it still might be tough, but it'll be easier than if you have lots of different systems, lots of different tools.
And being on the cloud, you know, like we are an AWS, you know, infrastructure, you know, all of our infrastructure runs on the cloud.
It will be very hard to do these things if you have mainframes, you know, like you have to literally...
probably bring the data into the cloud and do all of this, but it's kind of like a indirect way of doing it, you know, not instrumenting directly with those systems.
I saw a few startups that are focused on the mainframe problem now.
Let me like, but that's, you know, it's obviously a real thing.
Yeah.
In terms of governing and instrumenting, but maybe we'll stay on governing another minute.
So What I've learned from where you're at so far is that it seems like you're pretty much AI first, almost end to end.
You're on that review phase problem in terms of when to bring a human in the loop and when not to that we just spoke about.
Are there other areas of the software development lifecycle that you have to...
I don't know, do something in particular because you are regulated or areas that you worry about more or less worried about?
Like, you know, what's coming next, I guess.
So we want to make risk and governance and well managed, you know, really as the responsibility of the platform.
so that our users and developers can build an application and all of the controls are automatically applied on their behalf.
I'll give you an example.
We have deployed a bunch of coding tools in the company, like many companies.
But every one of those tools, we had to work with the vendor, whether it's Anthropik or OpenAI, etc., to follow a particular architectural pattern.
For example, we have an AI gateway in the company that we built ourselves, and a lot of our controls are there, like prompt injection, guardrails are there.
You don't have to worry as a developer.
It's automatically invoked in every input-output.
That is a game changer because you can actually then focus.
As a developer, I can only focus on the task.
and not have to worry about the individual cyber or well-managed controls.
That's one thing that I, you know, we will continue to make progress on that.
How do you basically make your platform central to risk management and, you know, controls?
Yeah, I love that.
I mean, no developer wants to be worrying about that stuff ever.
Yeah.
That would, that would suck.
Then it's like, I can't even really do my main job.
Yeah.
So it's okay.
Yeah.
No, great tip there.
I mean, yeah.
Having that, like taking that off the developer's plate is I think crucial.
Makes sense.
Yeah.
And, and we are training our developers to, you know, be more like, how do you run agent teams or multiple agents, you know, like the, the other, like those aspects of software development and.
Macau and all of that, but not like how to figure out prompt injection.
We want to automate that as much as possible.
Gotcha.
If I shift our focus now, we'll go into our last topic here.
And the last topic is around going from, let's say, like a pilot to maybe first deploying something agentic into production to that lasting.
So once an agentic system is in prod, what does your team do in the months after launch that turns it maybe from like, okay, we just launched this to scale and lasting?
Like what comes after you get something into production?
The pilot phase is mostly for us to experiment and learn.
We want to get as much offline.
and some real production data with the pilot users to do some evals.
But then once the system goes to production, we start to slowly scale the number of users.
And scaling has its own set of things that it surfaces that you don't always find out, like when you are designing or developing an application.
with a small number of users in the pilot stage.
So that's one thing we do.
We slowly start to ramp and see, is the latency going up or down, or going up, for example, or do we see more turns for some reason the agent is taking?
Where are things dropping?
Like when we don't get the right expected output from the right tool calling, for example.
That's one thing we do.
The second thing is we, as I said, like eval is the new kind of like mantra for us, you know, so we double down on evals to actually use evals to improve the system.
So, you know, whether it's the using a different LLM, using the, you know, tightening the harness, bringing better context.
Every part of the system, you know, we try to improve using evals from these, you know, from that scaling in production data.
So that's where the engineers focus on, engineers and product managers and, you know, our data scientists.
Once the application goes from pilot to production.
I mean, all of that is about telemetry, right?
You got to be measuring everything.
You got to have all of that.
to input back into your system.
That's what it sounds like to me.
Absolutely.
Yeah.
So, I mean, one of our, you know, distinguished engineers basically took it upon herself to make sure that every part of our platform is emitting the right telemetry with the right tracer ID, for example.
You know, again, this was until you really deploy the platform to a number of use cases and start scale, you don't always, you know, see those things.
So now, you know, every part of our platform has an ID that stitches all of these data together for a particular session, for a particular app ID, and, you know, et cetera.
So it makes it easier.
Super cool stuff.
We should have you on for another hour.
We could probably keep going.
You've been doing this.
you know, kind of in this world, ML, AI, you said, you know, let's say 20, I mean, you've been doing it a long time now, which is great.
Now looking ahead, let's go one year into the future.
Do you see any trends or shifts on the next change of how engineering teams will work?
What will AI, you know, consume next?
What are you seeing over the next year going forward?
I think the models.
I'm really excited to see what, you know, the future of open-weight models and U.S.
sovereign models, you know, like in just in a couple of months, we have had some great news of, you know, new models coming on.
So I'm really watching that space, like open-weight models, and even, you know, the frontier models will continue to improve.
I mean, we are all excited about what they have done in math, you know, for example, more recently.
So I think there will be a lot of pleasant surprises and step changes in the model side.
The scary part is what it will do to the cybersecurity side.
That's one thing we are also watching.
You know, I think you have seen our recent announcement of Hunt Hunter.
that we open sourced product, you know.
So the ability to find, you know, like very complicated attack surfaces and be able to patch them very quickly, that's something we are also very, very much focused on.
And that's where the platform controls come in.
You know, you don't want to patch every application out there.
That's just too much work.
But if you find certain platform-related, you know, controls that you can patch quickly, you know, I think every enterprise has to be, like, super careful, you know, and on top of, like, cyber threats in the age of AI.
I think that's going to continue to become a topic for us, you know, in the coming months.
And then I'm really curious about where RL will take us.
So the combination of our own models, the frontier models, all the deep telemetry we do, you know, and then if we put RL on top of it, how much more can we push the boundaries of what the agents can do inside the company?
I think that's one area, again, we are really interested.
And I think that's going to shape up, you know, a lot of our agenda next year.
Amazing.
Thanks for sharing, especially on the security side, which is something we don't talk about that much on this show.
But yeah, I mean, anytime there's a revolution in tech, the attackers always use it to try to get access to whatever they need access to.
And the window is getting smaller and smaller.
A lot of companies used to have like one month SLA, you pack something in open source.
I mean, you can't do that anymore.
It's like you have to patch it, you know, almost the same time, you know, it's detected.
Abhijit, there's one question that I've been asking each guest that comes on to Dev Interrupted.
So I'm going to ask you the same question.
What's one piece of advice that you give another engineering leader who's in the middle of their own AI transformation for their...
organization right now?
One piece of advice that you would give them?
I think it's the growth mindset or be curious and learn.
You know, like we are all learning.
I started my career with traditional machine learning.
My PhD thesis was in machine learning.
You know, I then I picked up AI.
I took coursework in AI and there were no jobs, you know, when I was studying AI.
And now we are into the age where we are.
So I feel like if I look at my own journey, it's been just continuous learning.
That's probably going to be the number one skill or kind of like the self-development journey that everybody has to go through in the next 10, 15 years.
Well, Abhijit, it looks like you made the right bet a long time ago of where the focus your career on.
I'm sure it's paying off now.
Thanks for coming on here and sharing all of your knowledge, your background, your information, where Capital One stands.
Like I said, it sounds like a really fun place to come and innovate and work.
And yeah, just thanks so much for joining us on Dev Interrupted today.
Thank you so much, Dan, for inviting me.
And I really enjoyed it.