Every autonomous agent still needs an accountable human
In this interview, Bhavna Bhatnagar argues that AI has pushed engineering work upstream and downstream, making discernment matter more than writing code. She contends every autonomous agent needs a scoped identity tied to an accountable human owner.
Bhavna Bhatnagar is the CTO and head of engineering at VigourSoft Global Solutions, an engineering consultancy of roughly 450 people that drops pods of specialists into client companies to build software across identity, data pipelines, and orchestration. She frames the work as a step past the forward-deployed engineer: her teams do not just write plugins to bolt onto existing products, they build whole systems. For one client making a medical device, VigourSoft wrote the device driver software that captured sensor data from dementia patients, then built the analytics and the dashboards on top of it. Alongside client delivery she runs a dedicated identity and access management practice, the corner of the field she calls her passion space, and she is pushing the firm to productize the tooling its engineers keep reinventing.
She arrived at the CTO seat by way of large-scale digital transformation. Before VigourSoft she led engineering at Procore and Rivian, walking into organizations weighed down by legacy systems and figuring out how to modernize them. At Procore she inherited a team of twenty, all based in the United States, and built a location strategy that hired across Latin America and India, standing up a follow-the-sun model that both lifted productivity and supported a customer base going global. Through all of it she has kept herself close to the code, the tech stack, the architectural decisions, and the system design reviews, asking whether the team is making the right calls and hiring the right people. That instinct, she says, is what led her naturally into the role she now holds.
“An AI agent is autonomous, but it still needs a scoped identity tied to an accountable human owner, because when something goes wrong an organization will not take the liability on its own.”
Bhatnagar's central argument is that AI has moved the hard work of software to the two ends of the pipeline. Teams now spend more time upstream defining what problem is actually worth solving, and more time downstream verifying that generated code does what it was intended to do. Lines of code no longer count for much; outcomes do. Her worry is that autonomous code arrives looking clean and well formatted, sails through its tests, and lulls reviewers who spent careers bracing for messy code. The scarce skill, in her view, is the engineer who can look at tidy AI output and say something is off here, I need to verify this actually works. That sense, she notes, is wisdom and experience, the human instinct that even a high-IQ agent does not yet possess.
What animates her now is a problem she thinks the industry has barely started on: accountability. Coming from identity, security, and governance, and fresh from debates in the OpenID Foundation spec committee, she argues that every agent, no matter how many sub-agents it spawns, must trace back to a scoped identity owned by an accountable human. She points to transaction tokens that carry the full context of who started an action, so a request ten levels deep can still be tied to the person behind it. Organizations, she notes, will not shoulder the blame on their own when an agent misbehaves. She is cautiously hopeful, unwilling to let reservations harden into paralysis, and clear about the assignment: the industry has built plenty of agents, and now it has to decide who answers for them.
The conversation
In this conversation: Josh Rubin (Host, CTO Studio) and Bhavna Bhatnagar (CTO and Head of Engineering, VigourSoft Global Solutions).
So I'm actually right now working as a CTO and a head of engineering for VigourSoft, where we are into product service engineering in different domains like identity, data pipelines, orchestration and lot of good stuff with a lot of good clients. So we are a team of about 450 consultants and I work as a CTO across for each of them. And especially I have a separate practice for IAM, which I see pretty much deep because that's my passion space.
And as the CTO of that, you are responsible for enabling the technology that helps these consulting teams to execute.
Absolutely.
What does that look like?
Well, the landscape is changing a lot. So in simple words, it's about keeping up with how things are going. Initially, we wrote code. Definitely we had the CI/CD pipelines and we committed our code. There were code reviews. There was a lot of human work. It has changed. Obviously the word AI has changed a lot of things in the landscape for good, as well as some cautious approach. But all in all, definitely a game changer for us.
For these teams of consultants that are going out there, what specifically are they consulting on?
So we have, basically we have pretty deep skill sets in verticals like I mentioned. So we have like database people. We have people who understand the machine learning, deep learning. So they are into AI, ML products, projects, and companies which are needing additional augmentation work in those spaces. Then we have identity and access management, like I mentioned. So that's more around how things are changing. Think of it this way. Earlier we had identity and access only for humans. Now with agents, there's a whole compounded problem. This particular vertical is solving. So that's that. And then we have, actually we have a lot of device work as well. So we write like device drivers for Microsoft and devices like some IoT work. So a lot of verticals. Definitely I don't have an area of expertise across all, but we work in verticals and we have engineering folks assigned to those tasks. And then they go ahead and work at the client sites, bring back requirements, and we create pods. And that's how we execute.
I see. Okay. So it's not about the enablement of how to be the better consultant. It's actually on the execution side.
Oh, absolutely. Yeah. We are a very strong engineering organization from that perspective. And we also have in-house projects, which I'm trying to put more focus on because there is a lot of smart talent in this team. So we are building some tooling, some enablement software around the use cases which we have been solving, which we are trying to productize ourselves.
When you're building that custom software for a consulting client, is that now their own product?
Oh, yes.
Okay. But I think about that. When you're operating just at the bleeding edge, your consultants that are going out there and making recommendations for best practices in a myriad of fields, you're constantly now, I imagine, inventing new agentic workflows for these systems?
Yes and no. I'm saying no because a lot of times we get a problem statement, right? Hey, this is what we want to solve. And then we go ahead in terms of, this is how we can solve it. Proposals go around discovery, figuring out what the challenges are going to be. And when we craft solutions, we may craft a solution saying, hey, if you want to focus on automation, we can build a bunch of agentic workflows for you. But sometimes they have curated the work themselves. It's more around, we don't have the bandwidth, we need some kind of augmented team which can come and deliver something very specific for them. In which case, definitely we talk about the bleeding edge stuff in all in case they would like to go that route, but we pretty much stick to what they have in mind.
Well, your consultant sounds like just this side of a forward deployed engineer constantly going into these companies to do product work to figure out what the needs are.
True, true. And it's a little more than forward deployment because forward deployment engineers sometimes land up writing, enablement code like plugins and how do you really integrate with existing products? But we actually have developed full scale products for teams. So for example, one of the companies we worked for, they needed, they have a medical device, right? And they needed to capture sensors from the device for dementia patients. So we pretty much wrote the whole device driver software. We pulled the data, we built the analytics, we built the dashboards. So it's not just around deployment and configuration of existing products, but it's about, you know, really we do everything.
Are the consultants also writing the code or is yours?
Yes, of course.
Okay, so this is really, so you are managing a team that can be deployed in pod situation to augment the consultants, I see.
So we work in, like I said, different models. We either go in staff augmentation, we go and blend with the team or we take turnkey projects, fixed cost projects and we work on them. This is something I've been, I mean, just to clarify, I've been doing this role for a little over a year, but prior to that I've led, like more like head of engineering roles at companies like Procore and Rivian, wherein I've really looked at digital transformation and looked at companies having a lot of legacy stuff and how do you transform it and how do you become, how do you make it bleeding edge in your words? Like how do you change it, transform the digital landscape of an organization, which really means hiring people if need be, growing teams in different countries, trying to figure out a follow the sun model. For example, at Procore, when I joined, we had a team of 20 and that was just US specific teams. So I realized that we needed, first of all, we needed somebody to, we needed to hire basically to do the work which we had to do. So the location strategy was, let's hire in Latin America, let's go and hire in India, so that that team not just augments us, helps us with better functioning and better productivity, but also helps us in supporting our customers, which were increasing more globally by that point of time. So I have, like I said, but as a leader of engineering, I like to be, and everybody needs to be these days, I like to be close to code, tech stack, architectural decisions, system design reviews, are we making the right decisions, are we hiring the right people? So that kind of led me very naturally into a CTO role, which I'm really enjoying doing honestly.
You say you've been doing this for about a year. So you've been doing this right at the shift point as the Claude Code, as the Cursor, as all of these come out. That's a sea change for any engineering org, but especially one that's consultative based. How has this affected and changed your approach as a CTO? I mean, your SDLC is different depending on who your customer and your client is, but how is this affecting your workloads?
So we look at it this way, right? If we are doing some kind of, so SDLCs, if we are blending in with the customers, we are using whatever SDLC frameworks they have. Obviously we kind of identify the gaps and help them learn the best practices for them. So it gets us to a more mature stage, but for our own internal product developments or our own turnkey projects or fixed cost projects, we do have an SDLC enabled, it's AI native now, pipelines, which really means that we are using all the AI tooling we are using all the AI infrastructure to build codes, develop code, review, test, deliver. So there's a lot of AI enablement and to your question, how have things changed? I would say things have changed, I'll put it very simply, right? The focus is not so much on writing the code, but really making sure that what you got as the written code is right and is doing the value, it's delivering the value, which you would want to deliver to the customer or to yourself or to the product which you are building.
But doesn't that value change depending on what the project is?
It does, it does, it does. And that's why we say it has to be outcome based, it's not any more, hey, I wrote so many pieces of lines of code, that doesn't help. It's about, did you get the, so it's about, we've pushed the, think of it this way, in the SDLC pipeline, we have pushed the problem statement upstream and downstream. Upstream being we spend more time in defining what the problem is, we spend more time in figuring out what are we trying to solve, and then downstream being we spend more time in validating and making sure that what we have developed is actually serving the purpose and is not, and I'm being very cautious here because then I'll blend into my favorite topic, but it's also about, is it doing the intention of what the generated code is doing is really what we intended it to do. And I'm using the word intended multiple times because agents being autonomous, the code generated being autonomous looks to a common human eye if it's clean code and it's been parsed well. We as code reviewers and architects have spent so much time looking at messy code that we are not prepared for that, right? We look at this code and we're like, yeah, it looks fine because it's been formatted well, it looks good, it has passed a bunch of tests maybe, but I think I would value an engineer who can say, no, I don't think this AI code generation has been done correctly. I need to verify that this code really works. And that's the mind shift change which is getting more needed now.
That's interesting. It's upstream, it's a matter of discernment and taste about what we should work on and having the deep knowledge and expertise to be able to take a step back and say, I know we can do everything. We're not going to, we're going to do this. But then that shift says the discernment and taste hits the bottom of the project. It's almost a redefinition in my mind of what vibe coding is and what I mean by that is the vibe is off. I think about this as someone who's spent a career as a video editor for many, many years. I can look at an edit and if it's off, it reads as off. I can't necessarily tell you in that moment why it's off, but I know it's off just by looking at it and that's an intrinsic human calculation. And that's something that's, it's a physical manifestation of wisdom and experience.
Absolutely. That is still that part of the human piece of all of this. And that is not going anywhere, right? I mean, even though an AI agent will definitely have an IQ which no human can meet, but it doesn't have the right, it doesn't have the experience yet. I should say it's been just two years and obviously the AI technology is getting mature, but it doesn't have the experience and the wisdom to say, I think something is off. I may not be able to say right away what it is, but it's off enough for me to go and investigate whether this needs to pass or this needs to pass.
Does AI have an unconscious where it's like, because that's it, it's the human unconscious where I can say, there's something off about this. I can't articulate what it is. AI doesn't necessarily have that yet.
It doesn't. So really, I mean, with AI tooling, it's all about not just asking it what to do, but it's about verifying, giving a feedback, making sure that you're building the right context with the AI agents to be able to say, hey, this is where things could have gone right. So there is some bit of inherent memory. And of course there is memory which is being built up about, hey, this is what this user likes, this is what the user told me not to do, and this is the tone. And like you said, right, this is what the expectation is. But at the end of the day, it's a technology and there have been cases of hallucinations, there have been cases of, I'm sure you've done this, you're dealing with your chat and you say, do this. And then sometime you're like, hey, but I did tell you that this is something which is not right. And then it would come back and say, oops, my bad, yes, you had mentioned. So this is where the memory falters, the hallucinations start building up. So trusting it blindly, not really. And especially, I come from identity, security, governance and guardrails background. So I would say, we've spent a long time figuring out or rather telling the agents what to do, but we haven't spent any time, or at least lot of time figuring out, is the agent doing what it is supposed to do? So build the guardrails, build the accountability around it because we kind of talked about it offline. Is there accountability around what the agent is doing? And if there is none, who is accountable?
Right, because accountability is a downstream effect of fear. And what I mean by that is like, you need to be able to threaten it. Like there need to be consequences to screwing up. AI can't feel consequences. So any guardrails, any training data, any proof points are always going to be suspect because firing, it doesn't matter.
True.
So I wonder about, like, how do we affect, like we can only make humans accountable. Like we can't make AI ultimately accountable, can we? As you're putting guardrails in or do we simply change the definition of what accountable means at this point?
So, you know, there is a lot of time I've been spending in the OpenID Foundation and the spec committee. So there is hope, right? So the reason I'm hopeful that it's not all going down south is because accountability is concerned. We have, you know, we have specs, we have frameworks to be able to say, hey, this is what an agent identity should look like. Like for example, we have the client ID credential spec, where there's a lot of discussion going around, should that be used to explicitly state what an agent identity should look like? Or there are specs like SPIFFE and SPIRE, which are more like workload identity specifications, which can tell you, you know, this is the ID. And that ID has a certain format. So if let's say two organizations want to align on, hey, we recognize each other as agent, I'm putting it very simply, then they need to be identifying their agents in that specific format to be able to say that, you know, hey, this is an agent identity. And as part of that, we are saying that agent needs to have an owner and that owner has to be a human being. There is a little bit of debate, okay, since I am like coming fresh off these discussions at OpenID Foundation where we debate all the time, can it just be an organization? But no, because at the end of the day, when something goes wrong, an organization will not take a liability for, you know, what went wrong. They might say, we have no idea who did it. It was probably a rogue employee, not with us anymore. So it has to be associated with an employee functioning in a certain role. So it's like a scoped identity of an agent. Agent is autonomous, but it has to be a scoped identity, which is accountable.
Yeah, well, we know what happens when a Waymo runs somebody over. We need to know what happens when your agent spends inappropriately.
Absolutely, absolutely.
Do you think we're moving in the right direction with that or are you screaming into the void right now?
No, I mean, I am cautiously hopeful. I would say cautiously hopeful, as in we are making continuous progress, but it's, so I have my reservations, but it's not paralyzing reservations, like I said, right? We have done leaps and bounds progress in terms of defining diamond as an agent, being able to say, hey, go do this work for me, and then, you know, agents can spawn subagents, agents can give certain tasks to subagents on behalf of, and these are very technical words. When a person tells an agent to do something, that agent is doing something on behalf of a user. So there is a subject associated with an agent's action. Now this agent, you know, we are talking of millions of transactions. This agent can go and create subagents. Now these subagents cannot just run wild. They have to be given scoped permissions. So we have frameworks, like I said, you know, we have the governance framework, we have the guardrails framework, which needs to be leveraged by companies to make sure that when they are sending their agents off to do some work, they are not creating the gap between the guardrail of these agents, and that's where the focus should be. So I am hopeful that agents and AI tooling is the key to, it's an innovation. I mean, we have to adapt it, and it is the right thing to do, but the guardrails and the governance needs to give up. That gap is,
And you think ultimately every agent should answer to an individual human?
I think so.
That's a fascinating take, and I actually think about the movie Tron with that, not that anybody remembers Tron like I do, but it was every agent character in that was the digital representation of the real world person that programmed them in there.
Yes, yes. So the accountability, like I said, it's not crazy out there. Like I said, if people start, it's about putting your buck where it needs to go right now. We have built a lot of agents. We better start focusing on, are the agents taking the accountability? And that really means have we defined a human associated with the agents accountable?
Is requiring a level of identification and de-anonymization on the internet that has never been a thing?
Yes, and think of it this way, right? I mean, the other thing which I have to say is there has been a lot of discussions in the tech industry around, do we need, should we accept the concept of ephemeral agents? So since we are talking of scale and we are thinking of these multiple zillion worker agents running around doing things, do we really have the bandwidth to catalog all these agents and say what each of them are doing and what are they supposed to do and who wants them? So there has been a discussion of ephemeral agents and I think what the eventual solution would look like would be a combination of the parent agent, which is representing a human, and then that agent taking responsibility for all these sub-agents or worker agents of ephemeral agents and there are specs. I mean, right now there is a good spec by Asher Routh on transaction tokens and it's been discussed in the identity wars where you're saying that you carry a transaction, when an agent is running a transaction, you put a token with that agent which really has the whole context of who started it. So even if you are at level three of the sub-agent, I know I'm going all over, but you still can trace it back to the parent agent and the human to say, hey, this 10 level down agent is really performing something on behalf of this human being. And those things exist. It's about investing and making sure that we pull it into our agentic frameworks.
Is this essentially just a backdoor way to make blockchain actually worth something?
That's a very interesting thing to say. That's a very interesting thing to say because digital verification is what really this is all about. And this is what blockchain did initially. I mean, the whole ledgers and digital ledgers is really, it benefited the financial industry a lot more than anything else, but at the end of the day,
I mean, we say financial industry, but we're talking very specific part of the financial industry, like bribery and human trafficking.
So now that you say, so I was, one of the projects which we had to take on was something around how do we do code attribution, which is fine. You would like, my code attribution, I mean is how much is human generated. I mean, I have written myself versus what has been generated by an AI tool. And that really says that this is a human generated code and this is an agent generated code, but of course the copyright and trademark and trade secret, whatever you have is with the organization, which is using that AI tool. So there was a lot of debate about how do we make sure that we have the legal rights to own the code which the AI agent has generated for us because it's coming from a generic LLM. LLM has been used to do something in terms of, like the Cursor was probably using generic LLM, it wasn't like an onsite private LLM install. So, and we were like, yeah, that's an interesting area and I'm sure this is just the top of the onion peel. Once we get into IP and trade secrets and legal battles, who are we fighting with what around the legality of who owns the code?
But take it beyond code, take it into creative projects that suddenly I have agents that are writing music and I have these that are doing different things, but then I'm using this agent over here from this person that I'm collaborating with who owns that song? And it's whoever ultimately what percentage of an agent? If I'm collaborating with someone to write music, there could be multiple credits on that particular song. This is just an extrapolation of that. That's a fascinating concept.
Ownership, right? I mean, we're not just talking about accountability, we are talking of ownership of what comes out of collaboration of, I'm using a lot of big words here, collaboration of federation of organizations who have decided to do something together.
Last question that I'll ask you is around hiring and team building at this point. Let's say your company gives you infinite money, and say you can hire, absolutely exactly who you want. Who is that?
I wish. You know, I think having spent such a long time in the industry, I know what we need to value and that hasn't changed. The human curiosity intellect, dealing with ambiguity, being able to, to your point, something is wrong but I can't tell what right now but I'm not gonna accept it as is. I think those are the qualities that haven't changed. So if I had to hire, I would hire, so I mean, in terms of, you know, placing, there are a bunch of things you can think about. Education, yes, it can be probably like a filter, right? It's about your capability filter, how much do you know in this particular domain? It doesn't matter so much. In fact, I have, I know I'm digressing but I have gone for, you know, college dropouts. I did a program in UBS. I was heading security engineering at UBS. I did a program of getting college dropouts and just giving them a training and seeing, you know, how they operate. And one of them, you know, I landed up promoting him eventually to a team lead of a certain division. So I don't think education is really that big of a deal. Like I said, personality definitely matter and judgment. And I know the test frameworks have changed. Now I can't ask them to write code and if they write the code, I'm like, wow, you've done it, right? Writing the code is not a capability anymore. It's about being able to review AI generated code and say, you know, something is off. I need to debug it or be able to explain what it is doing, be able to explain the edge cases which it has covered or not covered, be able to talk about the deviations, unintended behavior, what we intended to do versus what we think this code will end up doing. Those qualities are more critical and that experience gives you, I mean, your personality combined with your experience is what I look for. Really the ability to write code is moot.
Right, so just product oriented engineers looking to solve problems.
Absolutely.
Be part of the
conversation.
Whether you're a CTO who wants to be featured, a company looking to sponsor, or an engineering leader wanting a seat in the room — there's a place for you here.