Build The Next Great AI Company | Amit Goel, Kushal Prakash, Vijay Rajendran

Intro Trailer

Amit: I have with me Vijay Rajendran and Kushal Prakash, who are my partners in crime at GI Ventures.

Vijay: Here is someone who needs to get to the hospital because they're in labor. They're going to have a baby. What do they do? They call a Waymo, because that's the trusted form of getting some place.

Amit: This baby being born in a Waymo seems to be like this is like the next level of trust, in my opinion.

Kushal: I think with data, things have evolved a lot. Agentic systems in itself is not very new. In fact, like you mentioned early last year, we worked on the multi-agentic architecture. Almost all of the things which we use today are agentic. Like Cursor has completely changed from using just Claude GPT models to only agentic models.

Amit: There are a lot of people who believe in building horizontal AI applications and then there are others who want to build vertical AI which is very specific.

Vijay: Those horizontal tools are perfect next feature updates for any of the large language models. We can use AI in specific verticals where we know those verticals are particularly manual in the workflows today and they can benefit from automation.

Kushal: With vertical AI systems, the biggest challenge is to have the complete workflow very accurate, very precise to what needs to be done.

Amit: So recently MCP became a part of the Linux Foundation; Anthropic handed that out. I think it's a very big move that really underscores what's possible here. I still feel like the UX/UI will evolve to a place where AI will tell us or figure out what is the next best action. Like, you know, if you're doing this, what are you going to do next? People don't want to have 20 tabs open anymore. They want to have some more centralized way of managing their work, of telling agents what to do.

Kushal: We will soon have too many connectors and it'll be hard for people to know which connector they would need and what not. Just like, I think just to buy shoes, I don't think people would like to add Nike, and it has like 100 more connectors which are selling shoes there.

Amit: Why choose a venture builder if you are a founder? It's a great question.

Trailer ends / Full podcast begins

Amit: Hello listeners. Welcome to another episode of the Build AI Podcast. I have with me Vijay Rajendran and Kushal Prakash, who are my partners in crime at GI Ventures. Welcome, guys.

Vijay: Great to be here.

Kushal: Let's do this.

Amit: Yeah. Okay. So we have promised each other that we are not going to do too much of leg pulling or weird jokes. So we will just get into business.

What real-world trust means for AI adoption

Amit: I think if you broadly think about AI, the two or three biggest use cases of AI and ML so far have been self-driving cars on one end and coding assistance on the other end. And of course, in between, there's a lot of other examples, but these two seem to have made the biggest impact on the ground in production. And so a very interesting piece of news came in, Vijay, which you were talking about earlier, that somebody gave birth to a baby inside a Waymo. Let's start there because I just feel like it's a tipping point.

I took a ride in Waymo almost 2 years back, and the first ride I was very anxious. But from the second and third one, I was like, okay, this seems to be safer because there's no fatigue this driver has. There's no drinking and driving problem, and it seems to be driving really well. And now we have Waymo going across the Bay Area and even farther. But this baby being born in a Waymo seems to be like the next level of trust. So tell us about what happened.

Vijay: Right. Here's someone who needs to get to the hospital because they're in labor. They're going to have a baby. What do they do? They call a Waymo because that's the trusted form of getting someplace, and that's what they prefer. They didn't make it to the hospital without delivering in this driverless car, but it alerted the safety features, and they could tell something was going on in the car. There was an intervention. Someone came—I think it was EMTs—to facilitate that delivery. It was really cool because here's the first baby born into the care of artificial intelligence, and in a way that turned out well for mother and baby, and in a way that really illustrates trust. Because it's not just that wow, AI can code for us and AI can drive us around, but it can be a trusted service or a trusted entity in a sense in our lives.

Amit: Right. Fascinating. Who would have thought?

How multi-agent systems evolved this year

Amit: Kushal, you are a resident AI/ML expert with a lot of engineering and tech background. As much as I can sort of talk about it or fake how much I know AI, you are the one who actually is building a bunch of stuff at GI Ventures and for our companies. And of course, for viewers who don't know, Kushal actually was an AI researcher at a lab, has written research papers in AI, backed a machine learning model in 2016-17 for a nuclear research center, and has been CTO and co-founder of GI Ventures.

Recently we were actually chatting about the evolution of agentic AI. Last year we developed an agentic system within WhatsApp with 23 agents and a supervisory agent which could do so many things right across emails, calendar, scheduling. And since then, everything has evolved quite a bit from the way functions are called, the way tools are handled within agentic systems. Can you actually describe a little bit of how agentic systems have been evolving?

Kushal: Yeah, it's crazy how AI has evolved over the last 10 years all the way from a single neuron simulation to almost delivering a baby. While all of it, in my opinion, I think with data, things have evolved a lot. Agentic systems in itself is not very new. It has been there for a while now. In fact, like you mentioned early last year, we worked on the multi-agentic architecture. But then I think it's going full swing now. It's there's a lot of traction, and almost all of the things which we use today are agentic.

Like, just say Cursor, which most of the coders use for coding, has completely changed from using just Claude GPT models to only agentic models. While earlier it was there, things were working out well. But now with models themselves becoming better, it has become much more easier for agents to create an orchestration layer on top—basically create a plan for a query which has been asked by the user.

Planning, orchestration, and tool-calling

Once the plan is set forth, basically the agent can take the leverage to choose the best model with the best prompts. Based on that, it'll know, okay, this might be the LLM which can execute this better. Divide a larger query into a plan which has multiple executable steps, and then based on that, call the LLM or a tool which could perform that particular action in a much better way. This helps us also have a reflexive loop, which otherwise would just be prompt tuning. Fine-tuning is a bit harder and that can't happen real-time. So prompt tuning was how reflection would happen earlier, but now with agents in place, this has gotten way better.

Real examples: invoice automation and workflow chains

Something which I've been working on here recently is invoice factoring, where we are basically trying to automate the process of invoice discounting. A lender would usually look at an invoice from a vendor which has been raised to a company and based on that take decisions on whether to give money or not. In an agent system, most of these can be automated because internally we are looking at emails, looking at some portals, seeing if the invoice is valid, and then having back-and-forth with the company just to acknowledge the legitimacy of the invoice. Based on that, we can also have a reflection loop where the agent decides, "Okay, now this is good enough and now maybe I should pass this, or maybe I should follow up again."

These are some things which just an LLM in itself might do, but it's not accurate at all because every LLM model is built for the versatility to handle multiple things at once—because that's the context window it has to handle. But by making it agentic, we are able to make every part focused. This helps us have this reflection rule wherein we are able to also have the agent decide if the final output is good enough or not. Maybe let me learn from this, understand this, and also collect the future flows as well. So this has gotten way better, and we are seeing this everywhere.

In fact, even ChatGPT internally is right now an agentic system. That's why you see it searching the web when it's required, otherwise it doesn't. Those are, in the end, a plan created and then executing the plan based on what actions to take at what point. So the way agentic systems right now, with models getting better, is getting more traction. In fact, handling vertical AI problems has become way easier, particularly because we are able to create these narrower systems using the foundational models itself and also be able to take these actions accordingly. So yeah, it's something which is going to evolve much more next year. Last year it was there, this year it is getting much more traction. In fact, everything has become agentic right now, and so are we building on those systems as well.

Amit: Right. So we will deliver a baby even in the agentic system era very soon is what you were saying.

Kushal: We'll be an AI doctor soon.

The hallucination myth and model reliability jumps

Amit: Right. And just one follow-up question on that. In the beginning of '24 and throughout '24, there was this whole discussion around hallucination and that AI systems are hallucinating, they're not accurate. But that has changed quite a bit right now. Now the foundational models have improved. And one of the things that people used to say is that maybe we need to train our own models. Specifically, one of the vertical AI companies called Harvey said that they will train their own model while some of the competitors were not. And then very recently I read that the foundational models in the open have evolved so much that everybody, including Harvey, is just now building on them—which we used to call as "GPT wrappers." But it seemed like more GPT wrappers.

Foundational models vs. custom models

Yeah, it seems like GPT wrappers is the best approach and training your own models may not be. What's your view on that, Kushal?

Kushal: Yeah. So over time, the foundational models themselves have a bigger context window. Earlier it was required to maybe build their own models particularly because you can't feed in sufficient context to the foundational models to make it more specific, plus it would hallucinate a lot mainly because of the versatility of the models, and you can't really make it concentrated just by giving a smaller prompt. Right?

So that's where the RAG systems, which have also been evolving, are helping because we are able to extract only those required information even if it is a little bit bigger, particularly because we are able to add these as additional context and make these models more specific. In the case of Harvey, they would need a lot more legal-focused answers here. I believe they are able to add sufficient context and make the models much more specific.

Why training your own model no longer makes sense

And with the rate at which the foundational models themselves are evolving now, I think it might not be a good decision to train specific LLMs for smaller things because foundational models themselves are good enough and there's sufficient context to make it more focused towards what needs to be done. That's where I think some of the models which are there now are built more focused towards enterprise use cases. Particularly, Amazon has these Nova models—almost a million input context. That's a lot. There's in fact more than sufficient, I would say, at least for the present use cases.

Retrieval + large context windows reshape AI UX

It helps. The AI has become more focused. And on top of that, when we do additional tooling and make it multi-agentic, it becomes very sufficient, and we are able to draw towards the context we want and also get the relevant responses. Adding another retrieval layer on top, in fact, makes it even better.

Amit: Amazing. So, foundational models are becoming smarter. Agentic systems know when and where to do function calling. There's better emails. There's just this space is evolving at a breathtaking pace. But I want to remind everybody that this is still day zero or day one. There's so much development in UX, UI, and everything that has to happen.

The economics of wrappers and specialization

And think of the cost of training a model today. Like it is prohibitively expensive, and so it is not an efficient use of capital to be training your own model.

Vijay: Yeah.

Venture building in the age of AI

Amit: Okay. On that note, let's switch gears more towards the business and the venture building side. On my previous podcast, I had Todd Savitt, who has built companies in the past, has invested in a whole bunch of them, has been on the advisory board, has invested in funds, and then he's back to building again—which is a totally different topic, which we have discussed in the previous podcast. But there's one thing that I found very interesting. He was actually building it with PSL, which is also a venture builder. And I asked him, after having seen the venture ecosystem so closely, having invested and built companies and have invested in VC funds, why do you think that you chose a venture builder to build a company?

Which I would like to ask you that: What is your take on this? You are a trained executive coach from UC Berkeley, and you were at BBA Ventures, where BBA Ventures invested in a lot of fintech companies and other companies, and you saw these companies closely and interacted with founders at 500 Startups. You were on the portfolio management side, so you helped a lot of these founders, worked with them. Why choose a venture builder if you are a founder?

Vijay: It's a great question, and there's a number of reasons to choose a venture builder that should be aligned with the thing you're really trying to execute on. So if you are perhaps a team that is trying to figure out go-to-market with a particular business model and you're not familiar with how go-to-market should work, maybe there's a venture builder out there that has a formula and a playbook around go-to-market that you should use. Or alternatively, if perhaps you're a business founder and you know that it's going to take a lot of time to find the right technical co-founder, then a technical venture builder—ours is one such example—is a good fit because that venture builder doesn't just serve as a source of capital.

The only advantage a startup truly has

It serves as a technical co-founder in that case, but in any case is there to help accelerate the path from idea to product and derisk it in a much more systematic way because venture builders and venture studios, as they're also known, have to use a repeatable system to start and launch new businesses. And it's that system that is really important when you're starting a company. Having that system, having that plan reduces the time you're spending. It reduces the time that you're spending to launch. It's going to reduce the time it takes for you to get to PMF. And experienced founders really care about that particularly because they know how important getting the product right is. And then also they really care about distribution and about how they're going to move really quickly, because that's the only competitive advantage of a startup. It's its ability to move fast.

Why dev shops fail at AI-first product building

Amit: Right. And you know, Todd also mentioned in addition to all these points, he also said that in the beginning for a founder, especially a domain expert who wants to build a software company, it's very lonely. If you're getting a built-in team of engineers, designers, a CTO, and also capital, it just makes things easier and faster for you to build a thesis that you already have.

Vijay: Definitely.

Amit: And of course, this is not the same thing as just finding a dev shop someplace.

Vijay: Oh, yeah. And they're not going to perform in the same way. The most horrible thing you can do to start building a tech product and offer it into the market is to have an IT services company or a dev shop actually build your first product. It's for various reasons we can go into in detail. But one thing is that you want to build with someone who has actually built products, and product is what is their mainstay. Because the way that you build the tech for a product is very different from the way that you build tech for a client as IT services.

Amit: And then skin in the game, right? That is the second most important thing. It's a big difference.

Vijay: Yeah, they're not throwing it over the fence.

Finding market pull through real user pain

Amit: Yeah. Now on that point, I want to go a little bit deeper on why venture builders are, you know, sort of also help in derisking what you're building. And can you talk about especially from a GI Ventures perspective, because this is the one that we know really well, and we are actually executing these things on a daily basis. But helping in the customer development phase, and along with helping in the fundraising process, how does that whole thing sort of help the founder in building a business?

Vijay: The most important job for the founder at the beginning is to build something that people want, right? Very simple but not easy. And this isn't a new idea. I think it was probably most well-verbalized by people like Paul Graham at YC. But that is your job. And so the question is, what is the best approach for you to figure out something that people want? And we take that very seriously. Given my own background in human-centered design, given the experiences I've had with creating a studio in the past, I think the way we look at it—and people can take different approaches—is we want to figure out if there is pull in a market as quickly as we can.

So we might have a thesis. We might believe eventually there's going to be an amazing product for AI in some category of lending. But if there's not pull in the market for that right now, then it's really hard for us to go build a business that takes off quickly, because that's what we're trying to do. So how we go about finding pull in the market is we partner with that domain expert who has this unique insight and secret about the market but also is eager to partner with us in doing a lot of customer development—talking to people where we really understand how do we get past the mom test in order to figure out, okay, what is the thing that they really want? Not like priority 8 or 9, but like a number one, two, or maybe three thing that they're ready to go out there and buy.

And so at the end of a 4-week process, before we kick off our formal incubation, we already have a design partnership or perhaps even a proof of concept in place, such that we're able to build something that we have strong belief that people already want. And then of course we have to go forward and test and validate that further.

Horizontal vs. vertical AI: the decisive shift

Amit: Um, maybe that's a good segue into what's happening in the enterprise AI and what's happening in terms of... so there are a lot of people who believe in building horizontal AI applications, and then there are others who want to build vertical AI which is very specific. Can we like—what are your thoughts and what is that you are seeing? Because when it all started, everybody was building these very generic horizontal AI tools, and now everybody seems to be talking about vertical AI.

Vijay: Those horizontal tools are perfect next feature updates for any of the large language models that you know, the major foundation models that we talk about every day. So it might be that a general-purpose business writing assistant is a great product to stand up, but it's one of the first things that people are just going to turn to Gemini or Claude or ChatGPT or Grok or something else, because that's going to do it for them, and it's just as good, or it's 95% of the way there.

Why enterprises want automation, not interfaces

I think thinking though about workflows and what people actually need to do and where context matters—and where they know, "Oh, if I put this into ChatGPT or Claude or Gemini, what I'm going to get back is going to be a lot of drivel"—like, really, the context matters. And also from an enterprise standpoint, training on our data and having a process where we're using it to get highly contextual, accurate answers matters a lot. And so that's where we can use AI in specific verticals where we know those verticals are particularly manual in the workflows today and they can benefit from automation, so that people can do the work that they're really looking forward to, not some of the manual things that are taking up a lot of their time.

Amit: I was talking to a CXO at a lending firm based out of Washington DC, and he mentioned something very interesting: that they have Microsoft Copilot, and it's not the best product in terms of using AI. The only reason they still use it is because of its deep integration in Microsoft Office products and some of the stuff that they are doing.

Precision, workflows, and the vertical AI stack

And this reminds me, Kushal, that so you have been a CTO at a very different tech company before, and now you have been building multiple different AI systems for portfolio companies like FastTracker AI and now Swyft AI. And vertical AI build is very different, right? From, you know, of course it is being built on top of LLMs and so on and so forth, but how important are things like integrations and having that context and having the data which is coming out of the workflow itself? How is this whole thing kind of in vertical AI very different from a build perspective?

Kushal: Yeah, with vertical AI systems, the biggest challenge is to have the complete workflow very accurate, very precise to what needs to be done, like which I mentioned already. It's about reducing a lot of inefficiencies which the current workforce in these vertical AI companies are going through. Just like you mentioned Swyft AI, the invoice factoring itself, there's lot of smaller moving parts which are done manually right now—like reading the email, understanding okay who is the sender, who is the receiver, and what the next action should be.

That's where AI can actually take these calls, not just once, but keep reading it again and again and change these decisions based on that. The current just the larger models would not be able to do this because actionables are not just defined within any of these foundational models. Building vertical AI workflow is a product. This is where we can have sufficient watches kept on systems where we need to track, and based on that have the actions, and also deliver the actions where it has to be done. As good as sending an email to someone and tracking if he has responded, if he responded, at what time did he respond, and based on—and not just what time, what is the content of it and what action should be taken.

Modeling user behavior for real actions

These can be divided as well. Like sometimes we might want to fill out a form or a PDF, or we might just want to respond or schedule a meeting, or just draft something as a response to him in the tone at which that person usually writes. This is something which I have been working on the last few weeks here: trying to understand an individual or a professional, how his writing style, how his way of working would be, how can we understand what intent he would have at what point in time based on what the responses, then take the actions accordingly.

This is a lot more challenging because as much as we want to reduce the time which people would take in an organization, there's a way in which they would work and there's a way in which they would respond to some things and they would take the actions. Understanding those clearly and then mimicking the same actions requires a lot of narrowed perspectives which the AI should have, and also context on that individual's behavior as well as the way at which the working methodology is.

Why replacing CRMs is a losing strategy

So those are some things which vertical AI systems built out right can actually make the processes seamless a lot of the time. And on top of that, also ensure that it's done on time as well. Something which I think you and I always keep discussing about—that we end up missing out because there's a lot of action items we have, and sometimes we think about discussing but postpone it, and we just miss out a lot of times. With vertical AI systems, well, it can't be there everywhere, but where it is there, we can ensure that things are being done on time and there's not much delay happening as well.

Amit: Right. And just to summarize and also add a few of my points, that in vertical AI, what we have seen so far is that integrations are actually far more important than anything else. And our approach has been that don't go and rip and replace the software which is already there. This is something we did in FastTracker and also doing in for RIA, where FastTracker plays. You don't have to go and replace their CRM and financial planning software on day zero. What you need to go after is the labor market. There are so many things that have not been automated before. AI-native solutions can actually help automate those things which the human beings were doing. They were not the most value-added things. They were kind of back-end, admin operations. You would rather have a wealth advisor just talk to customers, manage the relationship—as they say, a wealth advisor is also like a therapist and a doctor, and so on and so forth. Focus on those things while all the nitty-gritties and some of these operational stuff can be handled by AI. I think that is what seems to be working out in vertical AI. And of course, integrations to all the existing systems, being able to manage the data flow, has turned out to be very, very important. I think MCP will be a groundbreaking thing very soon because of this—multiple integrations, multiple systems can communicate with each other and take the actions accordingly.

MCP becomes infrastructure

So on MCP, what do you guys think? Recently, MCP became a part of the Linux Foundation; Anthropic handed that out. So how do you see that sort of panning out?

Vijay: I think it's a very big move that really underscores what's possible here, and I think it validates some of the assumptions that we've had about that direction, and that MCP will be very integral to how a lot of products work.

The unsolved problem of AI UX

Amit: Yeah. I also feel that the UX/UI of AI has still not been found, in terms of horizontal AI. So we have tried a couple of things so far, right? One is a chatbot experience within ChatGPT and Claude and all that. Then there is experience where we are embedding AI within the existing products like Notion and Gmail and Google Docs and so on. I still feel like the UX/UI will evolve to a place where the AI will tell us or figure out what is the next best action. Like, you know, if you're doing this, what are you going to do next?

One interesting thing I recently came across is that once ChatGPT, OpenAI, opened up their app SDK, and then I basically through ChatGPT, I said what would be a good music to listen to right now, and I had enabled the Spotify app within ChatGPT and then basically figured out and decided what song to play. So this is where probably we are heading in the future. I don't know if you guys have thoughts about all this.

Vijay: Yeah, I think those integrations are going to be really important. At least in the business context, one of the things that we're learning is that people don't want to have 20 tabs open anymore. They want to have some more centralized way of managing their work, of telling agents what to do and interacting with those different products that are important. But maybe they don't have to live in a browser where we have countless tabs now open as we're trying to go between things or remembering to come back to something later.

Kushal: We will soon have too many connectors and it'll be hard for people to know which connector they would need and what not. Just like, I think just to buy shoes, I don't think people would like to add Nike, and it has like 100 more connectors which are selling shoes there.

AEO, discoverability, and the new search layer

Speaking of this, Amit, you have previously built Medici, but I think you had cracked UX very well there. How do you think this whole discoverability gets impacted with these AI systems? And you've been doing a lot of research on AEO as well, which I know about.

Amit: Yeah, you know, that seems to be my favorite topic of the month right now because I did two podcasts, both with AI visibility and discoverability companies. I think if a billion weekly active users are in ChatGPT, and then you add Claude and Perplexity and other AI chatbots as well, we are talking about a lot of traffic going to websites and apps and merchants. I spoke to one of my portfolio companies in skincare, and they said that 5 to 10% of our traffic is coming from just ChatGPT itself.

Vijay: Wow, that's amazing.

Amit: And yeah, for some of them, they are reporting upwards of 15% already. So imagine ChatGPT going from 1 billion to 2 billion, 3 billion weekly active users, and then the same happening at Claude and others. We are going to see everything become AEO, GEO first, as opposed to SEO.

Vijay: Is there a big difference? A lot of people are kind of scratching their heads wondering, isn't SEO and GEO pretty similar? Because you just have to have clear authority in a space and have maybe not as many backlinks and things like that, but you know, like good, relevant, timely content that the models are going to pick up and reward you for.

Amit: That's a great question actually, and more so because I have the answer to it. So recently I was told that look, if you look at SEO, there are many actually differences, but let's start with one very basic one. If you are a startup founder or a content strategist for a startup or you're a marketer for a bigger company, and if you started thinking about AI visibility and discoverability, the approach to this is very different. Like in SEO world, what you would do is you would focus on 20% content basically driving all the traffic because you wanted to publish something very specific. But what everybody's suggesting, especially these AI discoverability companies and visibility experts, is that AI actually likes more content. So you have to go almost encyclopedic on every topic on your web. So instead of writing 20 articles in the SEO era and maybe 200 today in AEO world, you have to think about writing 2,000 articles and thinking about every angle that people might be asking, because that's how AI likes it.

Second difference is that in the SEO world, you could actually work with an agency and they would basically—all the agencies did the same kind of work. While in AEO/GEO, it will be very product-driven. And the reason for that is you will have to, by doing these queries, figure out what is that people are searching for and what you need to feature for it can actually be productized. And so the whole thing will move from agencies to actually product platforms to crack AEO/GEO. That's also something very different from how you will do it.

And then there is also one very big difference: that Google would have looked at when they were doing SEO—when you're doing SEO and you're trying to feature in Google, you would basically try to look at a number of sources. And then here, what is happening is that apart from your website, something which is very important is review sites and Reddit and Quora and LinkedIn platforms actually have much more value than they used to have in the SEO era, like disproportionately. It has been seen that AI is actually suggesting a lot of answers on what people are talking about while they're reviewing your product, or what are they saying on Quora and Twitter and Reddit. And there of course like other differences. In fact, we have covered it in the last two podcast episodes on how this whole field is very different. It's really wild and it's changing really fast.

Systems thinking and the limits of LLM coding

Vijay: Yeah, yeah.

Amit: Okay, so that takes me to the next section of vibe coding, also a very pertinent topic.

Kushal: Yeah.

Amit: I think amongst us, we have talked about it a lot that it's a great thing. I think personally, for example, I've always struggled with managing time zones and meetings across time zones. So I just went to Lovable one day and basically said—before that I did some research on ChatGPT that what could be the best interface for a time zone kind of a thing. Because most of the existing sites are very slow and crappy, you know? I'm talking about those which were created like 5, 10, 20 years back. And today you need somewhere you can go and just literally in one or two clicks you can figure out what is the time in PST, IST, and then EST and CST and so on. And then Lovable, once I gave that research to it, it created a very nice scroller. So I could just shift the scroller and it could show me timings in different time zones. I thought that it was a very nice interface.

And so one thing I learned is that for personal apps, I think vibe coding is very good. But then it's highly debatable with that for enterprises and for production systems and for serious applications. In vertical AI, is vibe coding the best thing to do? Now, Kushal, from an engineering perspective, you do use Cursor every single day, every single hour. But can you vibe code a vertical AI product for a client using Cursor?

Kushal: I think vibe coding, especially using Cursor and stuff, it works out very well for me especially for these smaller tasks—just creating these smaller functions and then doing the final orchestration myself. The problem with building a whole vertical AI product is, I think we have seen this as well within our own team. Sometimes we fix something, and because of fixing that, something else would have broken. This I observe a lot while using Cursor when the code is, let's say, 10,000 lines of code in a single product. It can't take the whole context, find out and fix something. Eventually, most of the time it ends up also breaking some other thing which was always working very well.

This issue I see time and again, and sometimes I regret doing that, go back and then fix everything, and then feel that yeah, sometimes I just wasted time because I need to tell the same prompt or keep changing the prompt to figure out if it understood it well and it fixed in the right place. Because most often, as the code gets bigger, AIs tend to miss out on the smaller nitty-gritties and goes and fixes something else. And it also understands something completely different to what I would have expected it to be doing.

Like you mentioned, Amit, for micro products, smaller use cases, it's really good. And in fact, even to lay out the initial boilerplate codes as well. But building the whole vertical AI product with multiple orchestrations and the complete workflow, that is harder. More than that, in AI systems, it's required to do something which is different, and this is a lot of times new as well. This requires more understanding of what's happening in the current research world, what's working out best, and where are the metrics actually working out well, and based on that taking the calls.

How I approach this usually is I try to read some papers, try and understand some things, and then use that also as part of the prompt to see if the AI is understanding that and building it out. For me, it does do it decently well a lot of times. However, it fails in creating the complete agent system and doing the complete orchestration in the right way most of the time. Maybe in the next year at this time, we'll have AI doing a much better job at this as well. But for today, I'm not that happy with how these systems have been working out for handling larger code bases. And I think there's still room for actual engineering work to be done there.

Amit: Right. You know, Manoj, who is an advisor to GI Ventures and the Head of Engineering of Intuit, and before that VP of Engineering at Meta and Apple, he was saying that look, you still need a CTO and a system architect who can figure out what the overall architecture will look like. Things like systems engineering, also things like security and DevOps. So to the point Kushal you are making, pretty much you can actually get modules developed if you know exactly what has to be developed, but you don't want to allow AI to decide what the architecture is going to be and let it forget about security completely. Sometimes you must have seen that post by this guy who built a product with vibe code and gave it out to the customers. They started using it, and then some hacker actually exploited the security loopholes. These can be big nightmares, you know. So let's not get too excited about vibe coding. I think it's great for building your personal health tracker and things like that, but not for very big production systems, mission-critical systems.

Ideas, founders, and venture studio methodology

Amit: Okay. So we are coming towards the last part of the podcast. One question, Vijay, I would like to ask you is that can you explain like why GI Ventures we have chosen to work in three verticals.

Vijay: Yeah. So the three areas that we focus on are financial services, commerce, and enterprise productivity. And what we know about these spaces is that these are trillion-dollar, multi-trillion dollar sectors of the economy. But within them are very particular niches that are both valuable and very deep, and where these workflows are especially important, and where building AI that works in that context matters. And that's why we think vertical AI will have many, many iterations and rounds to go in terms of building the automated future that we've been talking about in this conversation today.

Amit: No, great. And in terms of when we think about vertical AI companies, especially the couple of them that we have built, and in the if you look at the future, what is the approach of ideation? Like where does the ideas come from? You know, this question has been asked to all of us. I think it will be great to sort of explain that how do we develop these ideas itself. Many studios have their ideas and they know what they want to build, and then they go and build it, and maybe they find someone who is great to go and run that. And I've seen and been involved in things that look like that.

Lessons on AGI timelines and agent hype

Alternatively, what is far more effective is for us to have a strong perspective in terms of where to build, and we have theses around AI in wealth management or audit or accounting or some other space. But in terms of what to build, we really want an expert who is working on their second or third startup, or coming out of industry, who understands this market and how to go to market there really, really well to help us shape what to build. And so we have a process where we explore these ideas. And of course, it's really important we validate that through, as I was saying before, customer development. And then our incubation sprint, where we're building the product and we're learning very quickly and we'll probably pivot it. But it is not just a matter of whiteboarding and brainstorming. It is a matter of doing and building, and that's a very important part of where not just ideas, but real businesses emerge.

Amit: Great. So I thought that one way to sort of end this discussion and this podcast would be we just summarize some of our learnings. I'll say a few of them and then I'll pass over to you. So couple of things—both our own learnings and what we have been seeing in the market, in all the discussions with other AI builders, investors, people in the research labs, and so on.

One of the biggest things that I picked up this quarter is that AGI is still a decade away. And this was none other than Andrej Karpathy who said that today's AI excels only on narrow, well-defined tasks. Things like human reward systems, curiosity, or intrinsic motivation—AGI is at least a decade away, as opposed to some of the other narratives that we have seen. Which means that we will still be required to build very specific solutions to specific problems using LLMs, but there's a lot of other engineering that has to be done on top of it. And vertical AI specifically, which we have discussed in this podcast, also requires more sort of integrations. It requires a lot of workflow mapping. It requires, in many cases, forward deployment engineers and so on and so forth. So it's still a lot of engineering and a lot of work. It's not going to be like you're sitting back and relaxing and the AI is doing everything.

And then there are a couple of others, but I'll pass on the thing to you guys. What are the learnings that you would like to share?

Vijay: And in the time we have left, I would just comment on agents. I mean, this year in 2025, everyone's been talking about agents. I think what's become particularly true in Q4 is realizing how many executives at big companies are telling their teams, we want agents, we need agents. They know what they want, and they don't seem to know what for yet. And so there is this call to deploy agents, to try things out. We're in such a phase still of experimentation there, where first people are just starting to use the tools and like, now they want to build agents. But it's clear we don't know altogether what for and need rubrics to test whether or not there's return on investment in those areas.

What’s getting harder in AI

Kushal: I think one of my biggest learnings so far is, as much as AI have made things easier to build, to do stuff, it's getting harder to build the best solution because it's not just CRUD anymore. It's not just taking some input data, storing in the database, manipulating it, and showing it in different ways and adding a visualization layer. It's about the intelligence itself. This is getting harder. At least getting the whole of the system accurately doing everything is getting harder, and I think it's going to get even harder.

And then also the solutions are not expected to be doing the smaller things anymore. People expect AI systems to be doing a lot more complex things, which is going to become, I think, much more complex in the next couple of years. So yeah, I think being smarter in the approaches and knowing what you're doing and taking the right calls is very required. Otherwise, with AI, the thing is we can keep circling around the same thing and expecting some magic would happen and things might get fixed. But I think it's better to be smarter in our approaches and then building things out right, and it takes some time where it's required. But we can't keep circling around the same thing.

Final insights and closing thoughts

Amit: Yeah. In fact, OpenAI created an AI BDR, but for that, they put a guy to actually do the BDR stuff. The engineer who built that actually did the BDR job for like a couple of months to learn what it means. And that is where I would like to end this podcast by saying that the real value actually lies in the domain intuition and understanding the workflow, which is what the vertical AI thesis should be. There's a reason why Scale AI and Sama are generating billion-dollar revenue by putting experts to train these models. The domain expertise is far more important than it ever was, I think, today when we were building solutions.

Great. It was a wonderful discussion. I learned a lot. Thank you so much, Vijay and Kushal, and hope that we can do this maybe every two months or something.

Vijay: This is super fun. Thanks, Amit. Let's do it again.

Kushal: Thanks a lot. Thanks, Vijay.

Amit: Great. Thank you.