“AI Build, Human Verify, AI Refine”: Rethinking IT Engineering at CurieTech

Ashish Thusoo
Always the development tool was human build, human verify, human refine. Now it is AI build, human verify, AI refine.

 

Saket Saurabh
There’s so many stories of enterprises buying software and spending months and even sometimes years implementing them.

 

Ashish Thusoo
So a lot of evolution is around how do you enable fast verification?

 

Saket Saurabh
Maybe if you can show a little bit, what are the data related challenges that you see?

 

Ashish Thusoo
The fundamental core is still the same. You want to make sure that this data is clean. You want to make sure that this data is in one place, and you want to make sure that as new data comes, you can merge this data into that stuff.

 

Saket Saurabh
So how does this change how we are hiring people?

 

Ashish Thusoo
It changes completely. I’ll give you an example of how we hire engineers today. We do a problem and see how they are using the AI to do the problem.

 

Saket Saurabh
Hi, everyone. Thanks for listening to another episode of Data Innovators and Builders. Today I’m speaking with Ashish Thusoo, founder and CEO of Curitec AI. Ashish, thanks for chatting with me today. Great to have you here.

 

Ashish Thusoo
Thanks, Saket. Great to be here.

 

Saket Saurabh
Awesome. So let’s get started, Ashish, with the latest stuff that you are working on and share with us the problem that you’re solving at Curie.

 

Ashish Thusoo
Yeah, so Saket, Curie is a very exciting firm that started a couple of years back. The core thesis around Curie is how do we use AI agents to automate software development, but in a different way. We are really focusing on IT engineering. We are really trying to reimagine how IT engineering is done today and automate as many workflows as possible using AI and AI agents.

Every company under the sun has IT. Every company under the sun has various business systems, CRM systems, financial systems, and a lot of energy in IT is spent on making these systems talk to each other. Since this is data related, there’s a lot of data movement that happens between these systems. And a lot of this integration work is done today by IT engineers.

 

We are trying to bring a lot of efficiency using AI agents to this integration work. And that’s where we have innovated. We have created a fleet of agents that go all the way from creating design specs to creating code to creating tests and the general lifecycle that is followed by IT engineers. These could be things like upgrades, migrations, troubleshooting of what is happening in the integration and so on. So it’s a brand new world. The whole of software development is getting redefined, and we are focusing a lot on the IT engineering aspect of it.

 

 

Saket Saurabh
Okay, well, that’s very interesting. So IT integrations is basically working through all the different IT systems in an organization. The focus is not on the core software that a company may be developing as a product, but more like all the systems that they’re trying to operate together, right?

 

Ashish Thusoo
That’s correct. In the valley, we hear a lot about companies who are building software as a product. But as you know, the economy just doesn’t have only those companies. A lot of companies are in logistics and healthcare and many other places where the product is not software. But all of these companies have one thing in common, which is that in order to run their businesses, they need various business systems. Those are managed by IT, engineered by IT, and integrated by IT in order to make a lot of their business processes automated.

 

Saket Saurabh
Yeah, okay. So Ashish, maybe for our audience, if you can give us a before and after sort of perspective of how this has been done so far and how organizations are doing this today? And then when you talk about an agentic approach to solving this problem, what does life look like for your customers?

 

Ashish Thusoo
So that’s a great question, Saket. Today, before this AI revolution that we are part of, most of this work was done through engineers, whether they be inside the company or outsourced. The classic workflow was somebody would gather requirements, write a functional spec, an architect would take the functional spec, create a design spec, then those design specs would get fragmented out to multiple different engineers working on parts of the problem. Then there would be a unit testing phase and an integration testing phase and so on and so forth. In all these phases, there are humans designing, humans building, humans verifying, and humans refining, whether it is figuring out requirements, design, build, testing, or putting things in production.

 

Now, with AI, that whole model changes. It goes from human building and human verifying and human refining to AI building, human verifying, and AI refining. And that has significant implications on how you do this type of work.

 

The biggest benefit to the companies is that they can now compress these cycles significantly. With our software, for example, they can get 70-80% productivity improvement in many of these cycles because the machine is doing all the build and the refining and the human is essentially focused on verifying. This is fundamentally shifting how you do this work today and taking it to a much more efficient model. The benefits to the clients are that they can compress the amount of time and the cost, while at the same time getting much higher quality work done.

 

The one thing to remember is the loop. Always the development loop was human build, human verify, human refine. Now it is AI build, human verify, AI refine. And that itself you can apply to any of these phases and between these phases and really compress the time and the effort that it takes to build or maintain these integrations.

 

Saket Saurabh
Yeah, and there are so many stories of enterprises buying software and spending months and even sometimes years implementing them and making them work. And this is true for complex ERPs and sales software and marketing software and so on.

 

One of the things that you mentioned in the process was the spec part of it. Many times these specs are created by the business user, but the implementation is done by the IT team. You talked about the AI building it. How does this part of the interaction improve? Because there’s a lot of communication between what a business team wants, what IT builds, and then there are continuous changes in business.

 

Ashish Thusoo
Yeah, so that’s a great question. Requirements gathering is an activity that, fundamentally, can happen in conferences, conversations, meetings. It can be structured, it can be completely unstructured. There’s a lot of variance that happens there.

 

However, what is now happening is that AI is making its way into many of these places. For example, if you are doing a meeting today, there’s an AI note taker which is able to transcribe that meeting. If you are doing conversations on Slack, there are now agents that you can build onto Slack to read that information. So there are places where AI is being built in today.

 

But more fundamentally, the AI can help when somebody has all this information in their heads. The AI can help in gathering that information from those people and then structuring it in a proper way. If nothing else, it can help you structure your design documents and your functional specs in a way where it could have taken days for people just to structure those thoughts. Even if you have gathered everything, structuring those thoughts and writing them in a way where it is consumable, AI can help a lot.

 

The fundamental thing is that when you’re writing these design specs for humans versus when you’re writing it for machines to build, there’s a lot more detail that has to happen for the machine build. Humans can infer and even if you don’t have the details, they can go and talk to somebody offline. But when the machine is building, those specs have to be a lot richer. So the AI is even more effective in building out that level of detail.

 

Those are the aspects where right from the designs phase, there can be a lot of benefits that AI provides which people don’t talk about much, but it is certainly a part of the software development lifecycle.

 

Saket Saurabh
Yeah, I think that’s absolutely true. Software engineering itself is changing with this, and it’s not just the writing the code part of it, it is the full lifecycle. I’d love to dig into that. But before that, you’ve been building this over the last couple of years and you’ve probably seen a lot of evolution of AI itself along the way. From the outside, it seems like AI can do everything, but in reality when you are building, where do we see the limitations? Where have you seen things improve? And maybe where is still an area of innovation to come?

 

Ashish Thusoo
Yeah, great question. It’s evolving rapidly. The first year when we were building things, even if you gave the right instructions, the models used to hallucinate a lot. I’m just talking about code building right now. That aspect has significantly improved, but it is still not at a place where you can take the human out of the verification loop, and I don’t think that is going to go away any time soon. Because many times, even with all the work that we have done, if there are certain pieces of information missing in the spec, the agent can get it wrong.

 

So verification is super important. While the first year was more about whether anything would come out at all and most of the code development was mostly around code completion, this year you can build more than code completion, you can do a lot of different things. But the verification itself, while easier, has not gone away, and I don’t think that will go away.

 

So a lot of evolution is around how do you enable fast verification of what is produced by these agents. The agent architectures themselves are evolving rapidly in many different dimensions. We use multiple techniques internally, not just the models, but how do you get the right results from those models.

 

And lately we are seeing accuracy levels where it is manageable and people can use it for productivity. Now a big part of the conversation is also how do you do this faster and faster. How do you make verification much easier? How do you make these models give results out much faster? And the accuracy improvement continues to happen, but a lot of it is going to come not just from the model itself, but from the agent architecture around the model, which is where companies like us are innovating.

 

Saket Saurabh
Yeah, the model is a core piece of technology, but how you leverage it matters a lot. We have seen the same, with a lot of innovation in our space around what that agent architecture should be. To give an example, in some cases we found that having multiple agents doing small pieces of work is not as effective. Sometimes having an agent take on a bigger piece is better. We also saw that prompt and how you build that has a lot of impact on outcomes. So could you share how you have built that agent architecture and where you might have seen certain approaches that are out there today, like MCP for example, be effective or lacking? Tell us where you hit those limitations and what you saw there.

 

Ashish Thusoo
Yeah, so building great agents, production quality agents, is both an art and a science. Because there’s no prescribed recipe. Yes, there are protocols like MCP and all, but that’s not a recipe to build an agent. That’s an ingredient which provides the glue on some of the most important ingredients that go into building agents, which are the LLM and the tools. So MCP allows you to do the glue. But how you go about building the agents is both a science as well as an art.

 

Typically, many people throw up an agent saying, okay, let me take an LLM, give it the right context, drag some knowledge bases, put some tools in place, and I have an agent. And that’s a great way of building prototypes. But when you go about building production quality agents, you first build out how you’re going to measure what these agents are able to achieve. What is your benchmark?

 

There’s a lot of energy that has to go into getting high quality benchmarks and a high quality signal from those benchmarks. Because in structured data analysis, you are dealing with numbers. You can know a signal is zero or one. But when you are in the space of code generation, or any other generation which is by nature not as structured, it’s very hard to say whether it is zero or one. So there is human verification involved, there is machine verification involved, there are agents that can do that verification as well.

 

So first, you have to lay that groundwork. How are you going to measure whether things are better or not? We spent a lot of energy on that. And then once you do that, you can painstakingly go through every single error that your agent would make on those benchmarks and reason through whether those errors are because the agent is not fine tuned properly, the model is not fine tuned properly, or those errors are in context. That is a very laborious process. We have gone through that process again and again and continue to do it. It’s a never-ending process.

 

And that then starts to crystallize around, okay, in this particular task for this particular agent, what techniques are working best? Do you need to increase the knowledge base? Do you need to build certain other tools? Do you need to fine tune the models because the base models themselves don’t understand this domain? We use a combination of that to actually build out those agents. And that’s when you start to get production grade accuracy which people can actually use. We wrote a few blog posts comparing our agents with a few other agents in our space. The marked difference is basically this painstaking process, which takes a real amount of time and energy to go through.

 

Saket Saurabh
Okay. I would 100% agree from our own experience doing that. And I actually want to double click a bit into the fine tuning part as well. But before that, can you maybe bring to life this example of you can have a simple agent, but then it’s not as effective? What we’re saying is you need an eval set, benchmarks, some way to measure that. Could you maybe share a real example of an agent operating on a particular system, where you saw it hit some issues, and how that eval set helped you fine tune that architecture?

 

Ashish Thusoo
Yeah, we can talk about a few agents that we built. Some of the agents that we built are around tasks like upgrades. For example, version upgrades. When you’re doing upgrades of various systems in enterprise IT, a typical IT department for a large company may have a thousand business systems. At any time, some business system is getting upgraded or not. That upgrade might have implications on your integration. So upgrade or version change is a very important aspect.

 

For this task, we have to first build benchmarks. The space of upgrades is large. There are a lot of different systems. So how do you first discover the space? How do you quantify that your benchmark has enough coverage? We spent a lot of energy on that. And where we did not have coverage, we would build tasks to do the upgrades and find issues. For example, in certain cases some of our models, because information about how to upgrade these things is not publicly available, the models would make errors. And so we would have to go and fix those, figure out whether we can fix those reasoning errors by providing examples to those models or by fine tuning them. That is one very concrete example where you would get these errors, and the same pattern you would see in a lot of other places as well.

 

Saket Saurabh
Yeah, I think very well said. Upgrade is a very big part of the IT job and errors and issues can have significant impact. I’ve seen cases where these upgrades go over months of time. So bringing AI to accelerate that, make it more reliable, makes for a very high value use case of applying AI.

 

As we’re getting into this, we’re talking a little bit about fine tuning. That’s something that we have seen in some cases as well, for example, we fine tuned for a faster response to the user when they’re working on things. So maybe let’s double click on this a little bit. How did you go about that process? There has to be a data set to fine tune the model. What positive and maybe even some negative impact did it have? We have seen cases where security risks might also change with fine tuning models, from prompt hacking for example. So I would love to understand a bit on that front.

 

Ashish Thusoo
So fine tuning is a way for models. You essentially fine tune models in order to make sure that the response to users is faster. Today you can take the model and augment it with knowledge, which means that it comes to know about that knowledge at the inference time. It’s like I’m going to give you a book. I’m going to give you an exam and you can open the book and do an open book exam and write your answers. So that is the RAG approach. RAG is your book, your knowledge base, and you have access to that book. You’re going to look at the question, look into your book, get the answer, refine it, and so on.

 

As opposed to this, I would give you a book, you can prepare for it for a month, read it completely, memorize it completely, and then go for an exam. Your answers will be much faster. Fine tuning is just that mechanism. I see RAG and fine tuning as just two ends of the spectrum. Many times you can identify things where the knowledge is not fast changing but you need a fast response, and you would go with fine tuning. And if the knowledge is fast changing and it’s hard to keep it up to date, you can’t fine tune the model every single day. You would essentially use mechanisms such as augmenting it with retrieval.

 

Common to both of these is the data set. A lot of AI now is about how do you build these data sets? Just like we build benchmark data sets, we also build these data sets in a similar way to either RAG or to fine tune things. Building these data sets may involve humans. We have also created synthetic algorithms to build those data sets, and there’s a full process around how you build these data sets, get them verified by humans, and apply a lot of science to it. You can take a sample of this data set and have humans score the sample. From that sample, figure out how much of the synthetic data set is junk, how much is not, and use that to train judge models to do that.

 

There’s a whole pipeline that you can do to build those data sets. And you can throw different metrics at it. You could throw metrics around what feature set it covers in your particular domain. You could throw metrics around whether it is safe or whether it can be hacked. Is there information that should not go into the training of the model? So all of those parameters happen there. But once you have this data set, you can apply it to fine tuning or to RAG.

 

Data is key. Data is central. And if you think about us, we are much more of a data company as opposed to a software company. We are essentially building all this data in this particular domain, which gives us the advantage.

 

Saket Saurabh
Okay. And is this the data about how this process has been built in the past and how some of these workflows have been created? Or is this data from the system itself to validate, before and after changes, what data comes into picture here?

 

Ashish Thusoo
What we do is we identify a workflow or portion of a workflow that we want to do through the agents. So this portion could be, for example, given a spec, give me the code. Or it could be given the code, write me the tests. Given the code, write me the documentation. This is a very well-defined task.

 

For this well-defined task, you define what the input is. In the case of spec to code, the input will be the spec and the output will be the code. Now you can build a lot of data sets around this, which means you have to build various repositories. You have to build specs. You have to build code. You have to make sure that these all match. You have to have positive examples of it. And that becomes a painstaking process. But once you do that, you have a very strong base of data. And that then starts reflecting into how good your model or your agent becomes.

 

Saket Saurabh
So Ashish, I think one of the things that I’m seeing is that you are solving some of the most complex enterprise challenges within the IT space. And when there is a general conversation in the market about enterprise adoption of AI, a lot of that conversation is about to what extent can AI help run the business itself, the day-to-day of the business, and how much of that adoption is possible?

 

It has been challenging, I personally believe, because enterprises are incredibly complex. You gave us an example of upgrade, and upgrade itself can be a complex process. So maybe from your vantage point, give us some picture into what are the real complications in the enterprise and how you’re bringing AI to those, and what that roadmap looks like. Some of these technologies are amazing, but actual adoption takes time.

 

Ashish Thusoo
The complications are both the environment, the technology, and the people. The market is not at a place where every enterprise is ready to adopt AI. Much less this year than last year, but last year we would go and talk to companies and they would say, we are not going to use AI. I have still met companies who say, hey, AI is a no-no for us. So there is that people aspect of it.

 

Let’s start with the people aspect. As happens with every new technology, there is a little bit of skepticism, then there are certain early adopters who adopt that technology and gain competitive advantage, then everybody follows. This has happened with the cloud, with the internet, and now it is happening with AI. You can see the arc of adoption is actually much faster, much quicker than any of these things because people see the benefits. But right now, most enterprises are in the experimentation stage. There is a tremendous amount of willingness to experiment because they can see the benefits if this works.

 

Now let’s talk about the environment itself. Enterprises internally are very, very complex, both in terms of the technology they use and the processes, which are not very standardized. Some enterprise might be doing customer support in a certain way, another might be doing it in a completely different way. This customizability is super important, and that’s why the richness of the agents is there. If everything could be done with a single model, there’s no customization needed. But because enterprises are complex, you can’t just take an off-the-shelf model and say, let me throw it at my customer service problem or my support problem or my sales problem, and it will solve it by itself.

 

You need to write software around it, an agent around it, and people are writing those agents. We are writing IT integration agents. And just like in software, you have to provide hooks to customize them. For example, in our case, when we are doing integration builds, we provide hooks for an enterprise to write a knowledge base of any customization around naming conventions. Similarly, there will be some customization, some knowledge base that can be written by the enterprise on what are the different stages of their sales process and how those things transit from one stage to the other.

 

So that is what is needed, and that is where the agents are starting to fill that gap. That is basically the way you solve the complexity of both the process and the technology within the enterprise.

 

The third part of the reason why you can’t just throw a vanilla model at things is that because of this specificity of the enterprise around how they do things, the process and the data which captures this process is also inside the enterprise. It’s not outside. And the model feeds off the data. So that’s why it becomes very important to also consider that custom data for that particular enterprise, whether it be on knowledge base or elsewhere. That is what the agents can go about.

 

So we are still on day zero of this whole transformation, but what is very encouraging is that there’s a lot of willingness to experiment, especially this year compared to last year. There’s also a willingness to even change the way things are working. Like I described, how AI agents are essentially changing how you actually build integrations. That same thing applies to how you actually support your customers. That is an evolution and it is going to keep going for many years.

 

Saket Saurabh
Yeah, yeah. And you mentioned along the way that this is very much a data problem as well. It’s not just the application and the process side. Maybe if you can share a little bit, what are the data related challenges that you see and how does that impact? Is that fine tuning? Would love to understand.

 

Ashish Thusoo
The data related challenges are the same that have been there previously as well, except on a grander scale. We come from the analytics background. Analytics always used to be, hey, my data is all separated in multiple places. That challenge is there. My data is not standardized. That challenge is there. How do you merge all this data together and make it correlated? That challenge is there.

 

Now, agents and fine tuning are just another application of that data pipeline. The difference being that this data now is way more diverse. I described to you the problem we are solving about spec to code. This is very different from the data that you would get in a BI system, for example. But the fundamental core is still the same. You want to make sure that this data is clean. You want to make sure that this data is in one place, not distributed. There is a way of gathering all of these things, a way of cleansing, of making sure that this data is in good quality. And you want to make sure that as new data comes, you can merge this data into that. So that problem is still the same, but it’s even more critical for AI systems because the AI system’s accuracy is completely dependent upon the quality of this data.

 

Saket Saurabh
Yeah, yeah. So it’s all this stuff, right? Data integration, data quality, fixing the data silos, observability, discoverability. One question I have, I’m curious if you see that as different from the analytics use cases. In analytics, you would pick specific data and say, this is the data I want to use, and do that. Whereas when it comes to AI, arguably you could open up any type of data in the enterprise and let AI figure out whether we are passing it as knowledge or as an MCP server or whatever the interface is. It’s like AI can go figure out what is useful for a particular case. So do you see that as completely exploding the scale and complexity because you’re not putting a human in the middle deciding what data to curate or not curate?

 

Ashish Thusoo
The complexity is because of the first thing that you mentioned. You can ingest any kind of data. Typically in the BI space, you would think about data in your systems of records, very structured. Now on the B2C or consumer-oriented side, the data was far richer and that’s where all the big data movement came in.

 

But now there are applications for that same unstructured data on the AI side, which also resides inside an enterprise. So you can bring all that data to an agent or a model, and the scale increases a lot.

 

When we used to talk about analytics, it was structured data, then semi-structured data. Now it is totally unstructured data. You can throw videos at this, pictures at this, completely unstructured conversations at this, which is the knowledge base of your enterprise. So the first complexity is because of the multimodality of the data. Second, when the modality is so diverse, how do you ensure the quality of the data? People are applying LLMs to build judges and so on and so forth, but judges are not perfect. So then you have to think about how do you improve the quality of the judges and that’s when the human has to come into the loop. If the human is not verifying it, how do you know?

 

And doing that at the completely unstructured data level, where the quality metric is completely different for this type of data per task, the quality metrics could be very different. So that explodes the problem of data quality. It’s not a very well-defined data quality metric. There is explosion due to multimodality of data, and because of that multimodality, the quality metrics change. And because of that size of both the data and the quality metrics, how do you and when do you introduce the human to actually do the verification? The end goal is still the same. You need high quality data to do all of this.

 

Saket Saurabh
Yep, yep. One thing I would love to learn from you, Ashish, is that in addition to being a technical expert on the AI side, your career has gone from one of the foremost people in the data world, from Oracle to leading and building data infrastructure at Facebook back when very few people even knew what data was and what it was for. Creating Apache Hive, which was one of the first SQL engines on top of big data. Building Qubole as founder and CEO. Being the general manager of AI at AWS. You have seen the evolution over the last 25 years from foundational data to AI in such an advanced way.

 

So I want to have you zoom out a little bit and give us a picture of when you look at enterprises and when people are trying to figure out AI and how it will grow and work, what is the advice you have for founders and entrepreneurs who are trying to figure out, hey, I want to work in AI, what are the key problems to solve, how to go about it?

 

Ashish Thusoo
I think the whole AI revolution, for the last two or three years, has gone from focusing on models to now focusing on agents. And I think the future is around how do you productionize these agents. I don’t think the infrastructure for productionizing agents is there today. If you see a sprawl of agents, how do you make sure you can control that sprawl? What are they doing? How do you verify what they’re doing is correct? So this is following the same arc of thinking of agents as a new application type in the enterprise. Enterprise apps used to be business apps, then SaaS came, and now there are agents.

 

In this new world, imagine everything being done through agents. There are opportunities in core infrastructure. How do you run this in an efficient way? There are opportunities in governance infrastructure, in security infrastructure. Whatever was applicable when SaaS hit the enterprises, that same thing is now applicable in agents. One very simple way for entrepreneurs to think about it is, what are all the problems that were hit during that arc? Those are the same problems, but at a much bigger scale and at a much more probabilistic scale, that you’ll hit in this arc. Start creating ideas from there.

 

The second thing is that with LLMs, there’s a new processing unit which allows reasoning to be embedded into your workflow. Previously software was dumb. Software would do what was encoded in those instructions. It could not reason. All the reasoning was done by humans. So now there is a big opportunity to rethink the human workflows within the enterprises. How do you embed these reasoning components at different places and fundamentally make those workflows much more compressed, much more efficient, much more productive? That is where new agent-based enterprise applications can be created, like the ones we are essentially creating with our agents or rethinking IT engineering.

 

So there are these two arcs. One arc is agent proliferation. Agents are a new app, and as these new apps proliferate, what can you do in the enterprise domain from the infrastructure, governance, and deployment process side? And the other arc is that reasoning is becoming very simple, and when reasoning becomes very simple, how can you reimagine the old ways of doing things into new enterprise apps? Both these arcs can lead to a lot of innovation and new ideas that can bring a lot of productivity benefits to enterprises.

 

Saket Saurabh
Yeah, I think that’s very right on. Now if I think about this and maybe extend it a bit further, two important things you mentioned were one, human as a verifier in how you are building software, and the other part was human as a judge. Now, if we take that and say AI can do reasoning, are you imagining that AI can reason, figure out how to solve a problem, humans verify and judge that, and does that go back into some sort of reinforcement learning and further advancement? Maybe paint a picture for us of how you see software and enterprise workflows progressing?

 

Ashish Thusoo
So I think what is happening right now is there are certain ways of doing things in the enterprise which define their workflow. And what is happening is parts of these workflows, the agents are coming in.

 

Let’s take support as a good example. The workflow was a support ticket would come, a level one support person would look at that support ticket, triage it, look up a knowledge base. If they were able to find an answer, they would give the answer to the user or fill out the ticket. If they were not able to find the answer, they would give it to a level two person, who would do a lot more digging and so on and so forth.

 

That is getting heavily disrupted by agents where the level one work the agent is able to do, because now they can reason. They have the knowledge base, they can do the reasoning. However, can you let this agent be by itself and do everything? No. So what happens is as it is doing this reasoning, you provide human verification on some sample of its reasoning to make sure that it’s going the right direction. And that feedback can go back into improving its reasoning for that particular use case, for that particular domain. Some of it will get subsumed in the fundamental models themselves. Some of it would be very enterprise specific. And that way you keep optimizing these units.

 

But another big opportunity is if you can turn the support problem on its head. Instead of waiting for the user to give the error and reporting a problem, suppose you deploy agents which are doing verification internally and proactively reach out to users. If you are deploying machines to do all this, it is much more doable. Support itself can change where it is proactive. Before the user hits a problem, you have already fixed the issue or anticipated it and provided a resolution to the user. Now that becomes a realm of possibility.

 

You could have your agents monitoring your internal systems, figuring out there’s a problem, handing it off to another agent, a support agent which has that information, identifying the users that might have this issue and proactively engaging all of them. You’re turning the support problem inside out. These are just examples and how this will pan out, time will tell. But these are opportunities now because it’s fundamentally new technology that enables you to do this.

 

Saket Saurabh
Yeah, I think this whole approach where the tasks are being broken down and the agents are running those seems very promising. I’ve also seen challenges in terms of getting the quality and reliability high, but that’s one of the areas of improvement. That reminds me of one of the papers that came out of Stanford recently about agent context engineering and how the proposition is that you may not need to fine tune models and you can have cases where you’re doing reflection on prompts and outcomes. Are you suggesting a direction where agents are looking at outcomes and improving the prompts? How do you see that fitting into this?

 

Ashish Thusoo
Hard to say where it goes. There’s a lot of work happening in improving prompts themselves based on outcomes. At the end of the day, all of these techniques boil down to some feedback, some way of verifying and some way of telling the agent, or creating a data set that says this is good, this is bad. Today humans are doing it, you put agents to do it, or you can create loops where the agent itself is self-correcting. Now you have this reasoning unit, you can apply this reasoning unit anywhere.

 

Saket Saurabh
Yeah, absolutely. So how does this change how we are hiring people, training them, managing them with all of these agents in the mix?

 

Ashish Thusoo
It changes completely. I’ll give you an example of how we hire engineers today. We make them do a problem and see how they are using the AI to do the problem. We obviously ask them to check their fundamental understanding of algorithms and systems and things like that. But the most important thing that we do is, here is your dev environment, you use whatever you want, you want to use Claude Code or Cursor or whatever for generic programming, use it. Here’s a problem and we then look at how they are guiding the AI to build. It is a very different skill set and it’s a very important skill set to have in this future world.

 

So I think the same would apply to other aspects of hiring as well. If you are a marketer and you are creating content, instead of being evaluated on your ability to write all the content yourself, I think you should get evaluated on how do you generate that content using AI much better. So a lot of creativity in how you break down the problem is important in that sense, as opposed to how do you actually build the asset.

 

Saket Saurabh
Yeah, 100%. I mean, I believe that the best hires are people who actually know for their area of work what a good outcome looks like. And then they can use AI, break down their task, and have AI help them get close to that ideal outcome. And then they can do the necessary tuning and adjustment. But in that process, they have become that much more efficient. They’re probably producing, if you’re a marketer, five times more content in the same time with better quality even.

 

Ashish Thusoo
Easily, easily. So you can imagine the amount of productivity that happens. And that is very well put, Saket. You go from there, they know what a good outcome is, and they’re able to make the AI build that output for them at a much faster scale and a much better quality as well.

 

Saket Saurabh
Yeah, yeah. This is great, Ashish. Of course, I can go on chatting with you and learning in the process. And I think it’s a great learning experience for our audience as well. So I want to wrap up with this one last question. Since we talked about people and what are the skills that are important, maybe tell us what skill is important for entrepreneurs. You’re seeing the whole cycle of product to business and sales and scaling and everything. Tell us what will help entrepreneurs succeed.

 

Ashish Thusoo
There are certain things which have become much easier for entrepreneurs now, and certain things which they need to adopt in this new world. The easier part is that previously it would take a long time to research things. Now, with so much AI technology able to summarize a lot of public research quickly, research has become much easier.

 

But what is more difficult is that the rate of change of technology is so fast. Back in the day, 20 years back, you would take an idea and work on that idea for three or four years and build a big company. Now that is not possible. If you take a point of thought and plan to work on it for three years and then take out a product, you’ll be irrelevant in that period of three years.

 

The core skill for the entrepreneur right now is to be very, very agile with their ideas and look at the arc of technology and shift based on that. When there is so much fast change, there’s opportunity. Opportunity also arises very fast. But you have to operate with a mindset of being able to very quickly identify those opportunities and change rapidly around those things. So I think that is very important for entrepreneurs now.

 

Everything else follows. The tools for starting companies now are much easier. The tools for creating great companies, or the ability to create great companies, is much harder just because the arc of technology is changing so rapidly.

 

Saket Saurabh
Yeah, very well said. I think the baseline definitely has moved up. Any idea that you can think of or come up with, by next day there are probably 20 other people doing that. But agility and adaptability are still going to be the test of time. Who can keep doing that, not just the first time, but month over month and capture value out of that?

 

Ashish Thusoo
So true. That’s absolutely right.

 

Saket Saurabh
Well, this has been a fabulous conversation, Ashish. Thank you so much for taking the time. Really enjoyed this discussion.

 

Ashish Thusoo
Thanks, Saket. I really enjoyed the discussion as well. It was great talking to you about these topics.