Think AI Podcast - There Is No Magic Wand: What AI Can (And Cannot) Actually Do | Ep. 15 with Dilip Bagrecha (Wishtree)

Episode Date: July 28, 2026

🎙️ There Is No Magic Wand: What AI Can (And Cannot) Actually DoDilip Bagrecha built mission-critical financial systems at RBS and UBS where failure wasn't an option. Now, as founder and CEO of Wishtree Technologies, he's watching enterprises treat AI like it can solve everything—and it's not working. In this episode, we unpack why only 5% of enterprises have truly adopted AI, the reliability discipline that separates real engineering from hype, and the uncomfortable truth most AI consultants won't say out loud: there is no magic wand.In this episode:(00:00) The reliability standard that built global banking systems—and why AI ignores it(02:30) Why 99.9% uptime is a death sentence for enterprise deployment(06:15) The shift from "AI tools" to "AI teams"—what actually changes for leaders(14:00) How to spot which AI use cases will actually work (and which are technical debt waiting to happen)(20:45) The fixed-pricing trap: why outcome-based contracts don't work yet(28:15) The CFO mindset killing AI ROI: cost obsession vs. value obsession(36:00) Advice for the nervous mid-market CEO: think transformation, not tools(42:45) Why honesty is rare in AI consulting—and why Dilip refuses to play alongIf you're leading enterprise AI initiatives, skeptical of the hype, or about to invest in AI and want straight talk instead of magic-wand promises, this conversation cuts through the noise.Subscribe to Think AI Podcast wherever you listen and send this to a leader in your life who's buying AI or building their first autonomous system. You'll get answers differently.Links and Resources:Dilip Bagrecha on LinkedIn: https://www.linkedin.com/in/dilipbagrecha/Wishtree Technologies: https://wishtreetech.com/Think AI: https://thinkaicorp.com/#EnterpriseAI #AIAdoption #FinTech #AIConsulting #ProductEngineering #AINative

It's not a magic wand. It will only actually aggravate some of the problems. If you don't fix it in the right way, if you don't design it the right way, you are actually creating a lot of technical deck, which someone else, after two years, three years, we'll have to kind of solve it. Welcome to the Think AI podcast. Each week, we talk about the most exciting AI research, tools, case studies and more.

I'm your host, Dave Goyer, and I've been working behind the scene in data and AI for over 30 years, whether you are an AI expert, skeptic, or something in between, this podcast is for you. Welcome back to the Think AI podcast. I'm Dave Goyal. And my guest today is Dilip Bagraja, founder and CEO of Fish Tree Technologies. The Leip's career started where a lot of great engineers start at InfoSys. And then went somewhere that changes how you think forever.

He built large-scale mission-critical financial systems at RBS and at UBS. When you write back-end platforms that move real money, you learn very quickly that it usually works. It's not an acceptable answer. That discipline shows up in everything he has built since. For the last 15 years, he has been running Westry, a product engineering firm he founded to democratize top-tier digital services. Today, he is 300 engineers, more than 750 solutions delivered, clients in over 40 countries, wow, Enwistries positioning is one of the boldest I have ever seen. AI native by design, agentic by default, and they're not bolting AI into software.

They are building autonomous systems that real business workflows in supply chain and in fintech and in healthcare and in distribution works. Here's the line that has made me want to have this conversation. He said by 2026, we will stop talking about AI. tools and managing AI teams. This is either the most important sentence in enterprise software right now or it is the most dangerous one. We'll find out soon. Dili, welcome to the show. Thank you. Thank you so much, Dave. It's a pleasure being here. Great. So let's get on with it. I want to pick back right back on to what you said. You built mission critical systems at RBS and UBS, as we said. What did that teach you,

that most people building AI today has never learned. Well, it was at different times. We're talking about 2006, 7, 8 period where there was not so much of hype around AI and automation. And any system, be banking or healthcare, was expected to work always 100%. Now we see a huge debate, good enough, 99.9% is fine.

The acceptance criteria has kind of lowered down. Non-deterministic behavior of software is accepted as a, this is how AI works. But back in days, that was never good enough. I mean, so I worked for RBS Royal Bank of Scotland into international payments. I was the Swift architect there. And then you cannot expect the Swift system to, you know,

work for 99.9% but not work for one or two payments. It is not acceptable. There will be huge escalations. There will be some regulatory penalties. And you cannot live in that kind of world. So you have to design systems by default in a way that those corner cases, those 0.01% use cases are also covered. And I understand why this is the case with AI at the moment.

But I also see that this is going to improve. We are not building those kind of use cases yet in enterprise AI and that is possibly the only reason why you see only 5% of enterprises have adopted AI. Because you cannot take risks with those kind of use cases. There is a room for even 0.01% of error. There will be huge reputational laws. There could be potential lawsuits, regulatory penalties and obviously the business data stake. So good enough is not good. Even in this so-called AI fluff or a lot of AI world and modern systems have to be deterministic if they want to have an enterprise adoption.

Now that piques total sense and there's some similarity I have with you. I studied on finance, international finance and then did CFA. I actually worked as a portfolio manager with a. A. B and Amro Bank in Bombay. Ah. Is it? So I was actually the part of the project where we kind of merged the ABN. So RBS had acquired AABN Ambrose Bank in 2007.

I remember that. Another largest banking in history. Correct. I was there in 96. And then later on it got merged. Yeah. Long back. So there was a famous thing about you.

You must have seen like orange sweet. I know going off track on the script, but I'm just geeking out here. You know, we had this orange suit thing because they only like orange, so you were drinking Capacula, no, Coca-Cola, a lot of funny stories are happening.

Coming back to this, I think building that discipline now, you know, whether in IT, in finance, as you mentioned, is getting somewhat difficult. AI is not to blame, by the way. So I feel a little bit differently. AI is not to blame,

but it's really people getting lazy due to they think AI can do everything. But AI is merely an improvised tool just like a calculator to put a simple analogy there. So a lot of this legacy issues, challenges, people try to solve it as if AI is a magic wand, which will do some magic and undo a lot of this lazy work done for many, many years. So that's the kind of mindset people have. It's not a magic wand. It will only actually aggravate some of the problems. don't fix it in the right way. If you don't design it the right way, you're actually creating a lot of

technical deck with someone else after two years, three years, we'll have to kind of solve it. So think of it in a way that you design it from day one for all your use cases. Not every again, use case is meant to be solved by air. You can use it for simple use cases like coding and stuff like that. Why not? But then don't think of it as a magic wand which will, you know, solve all your problems. Especially in enterprise, it's a very risky proposition to her. I agree 100% with what you just said. And that leads me to the next question, which is more about managing AI teams,

not tools what we just mentioned. So you said by 2026, we stopped talking about AI tools. And start managing AI teams. Unpack that for me. And what actually changes for a leader? Right. So we are already seeing team compositions

where AI agents are being called out as a separate line item or you know as a team member like suppose i want to deploy a team of 10 people uh i put three engineers humans uh two devabs guys one uxware designer and three java agent or a i coding agent so we are already adding that element of you know kind of an entity to an agent now which means you have to manage AI agents as in some sense human as someone whom you need to manage as a leader as a manager And for that, I think it's very, very important to understand the pros and cons of an agent or, you know, that entity, the benefits of using them as well as the limitations of using them. Now, in a pod where you have seven, eight humans and then three, four agents, you have to, you know, play through their potential.

As example, some of the tasks that you know can definitely be better done by agents because they can work 24 plus seven, they don't get tired. they can do a lot of this repetitive, monotonous tasks. Humans will get tired and that will reflect into their quality. But at the same time, you cannot just rely on them for the final output, especially when you're building healthcare systems or banking systems. And that's where human, by design, keeping them in the loop, makes sense. Example, the standard use case we all give is coding. Now, software development by nature is now most of the companies done by agents.

but then most of the companies have also realized that having a human review the code is extremely, extremely important. I mean, we cannot ignore that fact. So you have to design your workflow in a way that you use agents to the truest of the potential by doing a lot of this task, which are, you know, easy to do by an agent. But at the same time, have humans in the loop who does, and you know, you work towards that potential, towards that potential. So that the team is a complete part, as a complete team, we are maximizing their output. As a leader, you have to, in your mindset, you have to think like it's an entity. I mean, you cannot say, oh, it's a software. You know, it's not a software.

It's an agent. It's a real thing now. And you have to stop thinking like it is software or some delta addition to the productivity. No, you'd have to think of it like an entity. And trust me, companies are doing that. I have met few CTOs who, if you see that budgets, they have a separate line item for agents, right? So they put humans, engineer, and then AI agents, a separate line item to take care of their cost, the token costs, and their management costs. So we have already started doing that.

And I think you have to have that mindset as well to ensure that you use them to the fullest of the capacity, but also knowing the limitation. So Dilip, I like what you just said. One of the thing in our business also, we just think, yeah, we created the whole C-suite while we do have a human just to see and, you know, when we consult our customers, how do we see and what works and what doesn't work? And anything more mathematical formulated works great. Like I create a fractional CFO or virtual CFO as an agent. I have a full C-suite. And that works just perfect. So there is an advice. Obviously, you have to take it or not take it. So advice is okay. It's not that harmful at all. The second is it's balancing the balance sheets, cash flow and other things.

We are not giving access to our systems, by the way, we are just giving local models access to the statements and things like that. And it matches picture perfect way because it's all mathematical. There is not much to hallucinate with. So, you know, there are examples. And then we have done some research. I have a patent in AI. So certain things in innovation in research labs is amazing in AI.

There's some good use cases. What could be few good use cases in finance, which people can start quickly. in AI without worrying so much on other things. I think the best use case is any job which is analysis like you want to analyze few companies. Example, I do my competitive analysis a lot. Any analysis, analytical job, anything which needs to fetch data from different sources. Example, if you are a public listed company or you are competing with a public listed company, you have a lot of balance sheets available.

You can do some market research also. As example, you are competing with a competitor and some of the information is publicly available or through balance sheets if it's a public listed company. company, you can use that to also read through a long balance sheet and understand, say, hey, I want to go to, this example, Japanese market. Now, what is the revenue mix of this particular company, which is my competitor in some sense? What is the mix of that company in Japanese revenue or, you know?

So this kind of research, a lot of this analysis job can be done from a financial perspective, which I use a lot these days. I'm not a finance guy. I come from computer engineering background. So a lot of times a lot of people ask me certain financial questions and I use AI for my personal usage as well to unclutter things and okay, tell me like a 10 year old kid, what does this term mean? You know, it's like REOC and all those things. So yeah, it helps a lot at the level of the company as well as at the level of personal usage. Now that makes total sense.

And I want to pick back on it, any workflow that you've seen successfully implement. in your side of the world, in your businesses, that AI can handle very well. It may not be 100% maybe like 90% successful. So I can share an example for each one for our internal usage, internally at my company and one for my client. So for internally, we are at the end of our day an AI-native technology services company. So we give our services to our clients. And for that, the coding is something that we,

use a lot. We used to have a huge pool of developers, a huge army of developers, but I don't need so many developers. So what we have done is we have implemented a lot of coding agents internally at Vistri. And we have workflows where a human is in the loop. There's a technical architect who will review the code, who will see the design, who will see the system design is in place or stuff like that. So I think coding software development as such is an amazing use case. It works really well. It is kind of becoming better and better and better. And trust me, in just a matter of a year, you will see 99% of the code being done by agent. That is actually happening in a lot of companies where you have to write software ground up. But it will start

happening again in companies where you also want to move some legacy code to, you know, modern design and modern systems. So yeah, That's an internal use case. For clients, again, I give this as an example to most of my clients to strive with. The best example is voice agents or chat agents. It's the easiest, low cost, low entry barrier and you can deploy it in real time. So you have an agent to whom you can use for multiple reasons, calling, connections, APAR processes. You can use for customer support, customer success, order,

information, a lot of use cases can be built. And then there's always a human in the loop. So there's a workflow you define where there's a human in the loop. It takes over if the agent is not able to understand your end, get some context. And if the client is not happy or you can understand from the sound and the tonality of the conversation. And then human takes over. And then some use cases where, you know, it's not able to get an answer. It just passes on the call to the human. And needless to say, it actually fits into your existing telephony system. So example, if you're using ring central or any system, having those AI agents will not change anything for you, for your customer.

It actually fits into your existing telephony system. So it works really well. And I think that's the best use case for every company, big or small, to start using AI, ASAP. No, that's a beautiful example. And, you know, what you were mentioning before, I've talked to executives from large database organizations, one of the top three, two, you know, companies such as ours. And there's this term now called agentic engineering.

And that is just floating very beautifully because you want to have more thinkers who can nurture it and use agentic tools such as slot code or codex or anything out there. Yeah. And get a lot of results. And results are, you know, we have monitored in our own organization. It's like 10x. It's not like simple thing. You know, you can build.

Yeah, my son, you know, he's now 10 grader, nine grader. He learned agency code. He built websites for some of the local businesses that do not have websites. So he did it on his own. He went to Yelp. He said, okay, do they have a website? He went to Loveable initially and then build a site. It's like a two-hour thing he made.

I don't know how much money he make. I don't ask. But he made, he doesn't want to share it because he was to be. buys game or anything, which is fine, it's his money. Now, he made the money, but that gave him a lot of confidence for three things, right? One, finding customers, which you and I struggle, we have come from that background, finding customers, understanding their needs and delivering the solution. So nowhere in this conversation, he's mentioning AI, right? And it's not about AI. And AI as a tool, what we were talking before. And, you know, the agentic engineering is helping. So you can, let's

say subcontract the task to agents, you know, see what the results are, like you said, see through a human eye if the site is correct, if their things are laying out correctly, if the content is correct, whatever the case may be. And that's beautiful what you just mentioned, those two examples. So I want to pick back on agentic AI and why most agentic AI never ships. You said brilliant agentic AI is useless. Stuck in the lab. Why does so much of it stays there?

So I think I'm a computer engineer and I have a very practical and hands-on a feel of a lot of things that's happening. A lot of agentic solutions are built because of a formal thing rather than having a genuinely good use case. I mean, as we say, Bay Area always suffers from form, right? Investors, developers, founders. All of us. So we are part of that problem anyway.

But a lot of these use cases are actually can be solved through normal software rather than agentic. So you don't need an AI hammer for every nail. That's unfortunately happens to every problem. Now, a lot of these problems are solved through agentic. But then these problems cannot live with a non-deterministic output. So you will see a lot of demos and prototypes being built. But then when it comes to actually deploying it in production,

neither the CTO nor the CISO, nor the tech team will be confident to put it into production. So there's a huge anxiety about the non-deterministic behavior. But that's by design, right? That's how AI in some sense at the moment works. So then that's the point of, you know, who is going to bail the cat and no one is going to buy the cat. So you'll see a lot of production,

a lot of these prototypes and demos, not guaranteed to production. And that's why I feel it's a huge waste of time for a lot of people. People are doing it for the sake of FOMO or just trying out. I want to see what's happening in the market and stuff like that.

But then when you start looking at solutions with the right design mindset, having the right evaluation tools, the right use case, having human in the look for important workflows where there are humans which can, you know, unlock the deadlock. Then it makes sense and then it adds a lot of value.

otherwise it becomes a lot of futile exercise for a lot of people. Yeah. No, you beautifully said that. And a lot of times, any new technology, if you remember the days of blockchain and then back then some of the other technologies, it always goes through the hype. So if you talk to any executive today, the agentic word without them knowing what it really does and the difference between an agent and an agentic, which is a process than the actual person or actual thing. There's a non- adjective difference, I mean, to say the least. But in any case,

they are just thinking, oh, I do need, like you said, FOMO, right? I do need it. And I use this term called pilot purgatory, right, where people just want to keep doing pilots. And, you know, they don't pay attention to a few things. First, do you have the right data to put AI on? Now, some cases, you don't need data. But most cases, you do need data, especially corporate world, enterprise, mid-sized companies. Do you have the data? data is your workflow or the process really mapped out? It is done properly. And then third,

do you really have the gaps from human where the consistency is an issue? Because a person changes hand and then your process falls apart and nobody is monitoring it. In those particular cases, you get the result. But the last leg, everyone forgets to look at, which is what would you spend on it? You know,

what's your token usage? What model you would? use how you would use it. And there's a statistics from MIT, I'm forgetting, about 90 or 95% actually. Projects are failing right at the pilot level. And this is the reason why. And there's a lot of educational thing needs to happen on what is AI, why is needed, and why it is not needed.

So we teach our team, do not embed AI like Gen AI in everything. Use AI to build it, but just don't throw AI for the sake of. if it really has a need, like on research, finding things like this podcasting. When I need to do research, AI is beautiful. It will give me a lot of information. Obviously, I'm a writer. I write music too, so I want to write on my own.

But AI helps me tremendously. My process is at least three to four times faster now, you know. So those kind of good examples that you need to find and then apply towards it. What do you think? No, absolutely. And as you rightly say, I think the first point. So what I have seen is a lot of this so-called AI project. on day one become data projects on actually day two.

He don't have the right data in the right form and in the right structure in the right place is in silos and then suddenly the whole narrative of the oh, we need data and then where's the data? And then you start, you know, making data tricks kind of a project for them. So we recently became data mix partner and that's the reason. I mean, we were very bullish on some partnerships that we did for a few agentic AI companies. but then you start looking and talking to enterprise clients, you realize there's a lot of historical legacy, dad,

and there's still a lot of structural problems. So then you start solving those plumbing problems and then you can build a beautiful castle on top of it. But then before that, you need to first do your homework. And that's, I think, is very, very important. Yeah, example is perfect. I always say data before AI. 30 years, I've been doing data and AI both AI in 1997,

yeah, 96, 97. in data for a long time, being Microsoft partner, a couple of my companies, you know, Thinkia is a advanced specialized partner with Microsoft. And the value of data, you just mentioned, right, plumbing, getting water before plumbing is not going to happen. You do need to have the right plumbing to get the right pressure in your bucket. So that's the analogy. It's a beautiful analogy.

And data has even far more importance today than ever, because if you want to analyze something, it's still garbage in garbage out. So if you don't have data in right shape and right format, AI is not going to do anything. It's all gibberish. It will hallucinate and it will give more stupid answers. And then the problem is even if it's a top-down approach,

CEOs and CTOs want the team to use, if they're not confident on the answers and the output, the team will not have adoption. There will be no adoption in the team. It's a riskier problem to have, right? The team is not using AI. The senior management wants everyone to use AI, you know, and then there's a huge problem and the gap between the two.

Very true. It's extremely important that we do it in the right way. Absolutely true. So I want to go back to our initial discussion on where to use AI. So software engineering excellence, that's the word, been floating around for a long time. Yeah. And we thrive for it, you know, being the implementers for our clients.

that has to happen. That's the reason where they hire us. Now, in this era where AI writes a lot of code, what's the bar now? And the reason why I'm asking, you already mentioned you are using testing a QA on a human loop and AI to do the coding. And then AI follow the best practices.

I think testing and security, I can clearly see the two human side angles that needs to happen. But then there is another aspect. Because when we are hiring, there are juniors, like my son is still so junior, but you know, the ones coming out of college and they are into this AI hype in this AI era. And they're not no longer learning because the mindset is whatever I need to learn, I'll let it on the job. I'll go into an AI chat model and start talking to it and they'll start learning through it. So how do you keep your organization consistent where learning still has a lot more important?

And what do you refuse to let an AI do other than what I just mentioned? I want everyone to understand what they want to do from AI. So the thinking cannot be outsource to AI, first of all. Thinking cannot be given to AI. You have to know what input I am giving, what is the process and what output I'm expecting from AI. But then you just let AI dictate everything. No, it will not work.

Now, you're right that a lot of developers. especially freshmen who are coming from colleges, they are struggling. And as a part of our interview process, to be honest, we actually give them a paper and a pen and actually ask them to write algorithms and data structures and all that. So I want to see their thinking, their system design, their technical architecture design and all that, before actually giving them an AI tool to code and stuff like that.

So the basics have to be very, very clear in terms of your programming skills, your design thinking, your system design and all. And then we definitely give them all the two. because you cannot let them live in a world where you're not giving them tools. But then you also give them tools with the proper training. And that training has to continuously evolve, like every three months, every six months, not even three months actually. Every month, like, there's a new thing or one thing or the other coming.

So there's a separate team in my company that does the research that keeps an eye on the latest models, on latest tools, technologies. There's a new inference engine or something new coming up. They keep a tab on what's happening in the market. and then they kind of propagate that inside the engineering team. That's how we have a continuous training sessions. We have a group called Technical Focus Group that does it. And then they bring those lessons back in the company in terms of educating all

our engineers. So it's a continuous learning. Trust me, things that are moving so fast that you cannot have a monthly or a quarterly thing. It's like a daily there's something about the other coming. So we also created a board. We call it TechBites. and we continuously put stuff because not everyone follows LinkedIn

or what's happening in the market developers are working on client projects they are I mean how it's chasing a deadline and understand all that someone will definitely continuously put something on the TechBites platform and we kind of keep everyone updated about the latest what's happening

in the world of technology in general that's really amazing and you know it just brought a memory back So when I started, as I mentioned, I did finance and CFA. It was not a programmer. But a company hired me to set up their operation. I got excited to learn programming back in the days. It was biotech solutions.

And they come from Palo Alto, from Bay Area. And I belong to a city called Adore. So initially, I said, I want to do this. I like what all the other developers are doing, which I held them hire. And they said, you know what? Everyone went through this process. So you need to. And the process was I need to go through the C++ books and things,

very short amount of time. Second, I started to write code on paper, everything written on paper, like all those hives and pointers and everything written on paper. And I need to score 80 out of 100 to get to it. And that was, you know, the computer was sitting right in front and I set up the first Power Mac for them, and I was itching to go on to it. And they said, though, you have to.

to do this. So they taught me two things. One is the coding. Second is the biotech. I'm an engineer. So biology, we come from India. We hated biology. We hated anything related to that science. And I had to love that. And they scored me on that also. And we went through the business side. We went through the technology side. We married that up. And then I became a programmer. And I talk about that story a whole lot because these days people say it's not needed and but but it's needed more than ever because AI is taking over your job especially a lot of Indian engineers are from India itself are losing these jobs so if they are not an SME they don't understand the subject area well they're going to lose their job constantly and like you said 90 or 95% jobs will be outsourced to AI so then what would you do

you will apply the logic on the business and improve upon that what's your experience looks like there? I say this to my team all the time. So we have heard of this is turn called shift left where a developer is expected to do testing. We heard about shift right, where developer is also expected to do DevOps, observability and infrastructure.

And then I said shift north, which means you have to start also learning the domain, start understanding the context of the project, the domain of the project, the industry of the project, business model of your client because when services company we sometimes do not pay attention to example business model what is my client's business model how is he making money and stuff like that but then only if the developer understands all of that and have a complete holistic 360 review

then we become more and more valuable and then we genuinely become a problem server or as they call it in modern world now with a lot of high forward deploy engineer otherwise you just are a developer or you know are paying a role of our tech team technical member team. But then once you get a holistic view and can appreciate other aspects of the whole cycle, then you actually become a real forward deploy engineer. And that is where I think the industry is also moving towards. Because coding is cheap.

Software is a commodity. And that's where, you know, a problem solving skills of an engineer becomes important. Now, that's amazing. And bringing that culture is absolutely the need of the hour. And that brings me to another point. So, you know, three pillars of my life. I'm a disabled entrepreneur, done multiple things, nine businesses, five miserable failure. So learned a lot and I don't want to change that process.

What happened at all? Because that gave me a lot of learning. Three things that I pay attention to. So I'm passionate about technology. So tech innovation for sure. Leadership and motivation, which is like mindset game. Now, you're just talking about the leadership thing. So this is kind of an honesty question.

When you built a wistory on openness, ambition and honesty, tell me a time or an example or a use case or a story about honesty cost you a deal and you did it anyway. Meaning you lost a deal, but you wanted to do it because of your values. Well, I think that comes naturally to us, to me, someone who has worked in forces and we all carried that feeling very, very with a lot of, you know, It was like, oh, we've voted on our sleeves. If you remember, InfoSys was the darling of the stock market and everywhere.

And the tagline was powered by intellect driven by values. So in that sense, I think values have been something which has been inculcated for a lot of us who are proud X Infoces is inculcated and is part of our DNA culture. So when we started working with large enterprises, you are, you are supposed to claim a lot of things. I say a lot of things as part of the vendor onboarding. So we have one client. It's a very large financial institution that we work with based out of Washington, D.C. I'll not name the client. But yeah, it's one of the world's largest nonprofit international development agency out of Washington, D.C.

And then we were supposed to do, I mean, there's a huge vendor onboarding form, and we were a small company back in days. It was like around seven, eight years back. And then we were not such a big company, and we were supposed to enter certain information about all those, you know, nice to have things like environment safeguards or certain vendor policies and all. And we were advised by our advisors to kind of bluff or, you know, our way out and, you know, put some incorrect information. But then I said no, whatever it is, let's put it very clearly in black and white. Let's not even put it in, you know, a gray area. And then if they

want to select us based, they knew that we are a small company. So let's be honest about it. And Let's not bluff anything just for any one particular team. And initially there was a lot of, I mean, it was not a rejection, but then the vendor team was not too keen to onboard us as a vendor because it was a large institution. But the client, the champion inside the company, the large bank, they appreciated us more. They were honest and we didn't cut corners to, you know, just become a vendor, which a lot of companies do. And they convinced the procurement team. and created an exception for a few requirements, and then we became a vendor.

But then we were very clear that we will not use a shortcut or bluff our way to become a vendor to such a big institution. We will share whatever is the truth, and then let's see what happens. And then that also built a solid reputation and a deep relationship with the client, and then we have been working with them for many, many years. And that was our big breakthrough in the enterprise business. So we were not qualified in the strictest sense, but we were honest. The process took longer than expected, but at the end of it, I think it pays off really well. And I'm proud that we stood aground and did the right thing.

No, that's amazing. And, you know, that just builds your character, your identity and soul. we have a few examples, but one of the example is where we were working in an environment. The client knows us for a long time, and they wanted to do something. An SAP, we don't do it. So we hired an SAP team. And obviously, our PMs could not understand the integrity and the depth while we had checks and balances. And one thing led to another, the value was not delivered.

And he was like, you know, it wasn't delivered. No questions asked. We talked to the team. They said, yeah, this is what has. happened. We refunded all the money. Not only we refunded all the money. We found another team. That's a lot of loss at us. We found another team and got it done by them, absolutely how he wanted it. And we didn't do it so that we get more work from him or whatever the case. Maybe he was well connected. But then he appreciated. We laid it out transparently. This is what has

happened. And since then, he's like our biggest referral and a lot of work comes through him. For good reasons, yeah. Yeah. Yeah. So yeah, that that always gives a lot of value. One of the question I have is, if I'm a mid-market CEO with no AI team and also a nervous board, what is the very first thing I should do on Monday or what would you advise me if he just sits one on one with you? First of all, he should look at AI as not just an incremental technology, but look at it as a big, transforming, disruptive technology. And now I don't think anyone in this world, even the board will kind of discount it, so it will be easy to convince a lot of people. So he has to think of it as a transformative and disruptive technology.

And more importantly, think of building some use cases. which he or his team has not built in the past. So when I double click this, a lot of times you have different teams like HR, finance, sales, marketing, ops, and you have some use cases that you want to build, you want to automate certain things, and you know, you have every department,

every function will have their own list of bank of use cases. But then we all have thought because we always had some restriction, restriction of building software, of restriction of not having an amazing, co-worker called AI. So I will as a CEO give all my teams a free hand to be very bold, very expansive and think of amazing use cases which they have never, and it can be crazy sometimes and it will,

maybe it is not possible to build them all today or tomorrow. But then think of it as to get bold as much as possible and think of all amazing and good to have, nice to have use cases, not star use cases. North Star use cases and note down. So you create your banks. So example, your finance team will have a bank of use cases that you want to build every department. So you have 100 to 100 good use cases, which then you can prioritize, you can plan. You can plan short term, midterm, long term.

Maybe the technology is not ready today, but I can guarantee that technology will be ready tomorrow. Because everything is happening at such a high speed, at such a fast pace speed. So that's my advice that, hey, think of. scenarios think of use cases that you have never thought of in the past that you could not take big bets on start thinking that's those use cases and that's where we'll add a lot of value you will add a lot of business value to it you will can increase your top line you can reduce your expenses you can increase your bottom line from all those use cases building those you know use cases in your company beautifully said and that has

a follow-up question. So what is the question you wish clients would ask you, but they never do? That's a tricky one. I think I think that I still see, I still see some in some conversations say they know the limitation, but then because I run a services company, sometimes it's hard to kind of ring fanci it in a proper way. Example, a lot of these clients, if you work for large institutions, they always look for a fixed cost quotation from you guys, which is hard to give in an AI context. You cannot give a fixed price quotation to a client. We are in the same board, so I feel the pain.

That's hard. Second is, you can see a lot of times this hype of outcome-based pricing. I am seeing this a lot that the client expects an outcome-based pricing, which is okay. Okay, if you know the outcome. A lot of times the client doesn't know the outcome. There's no system. there's a big data problem, data is in silo, and then how can you give them an outcome-based pricing

when the client then says you don't know what is the outcome expected? So a lot of times, yeah, I mean, there's life, I'll not complain, but yeah, I wish we all had a better sense of what AI can do and not go by what's happening or just a fluff or just feeding a formal that someone X has done it and I need to do it because the context is very different in every company, the legacy is very different,

there's a lot of debt in some companies in terms of tech, debt or knowledge debt, which is not anywhere else. So you have to be more realistic of the context that you're working in. And then sometimes I feel the science is missing in some cases and some conversations. And we have to kind of explain, educate our client. And it's not that they don't understand because I think they know it, but then they just want to, you know, hope and assume that there's a magic wand. But unfortunately, there's no magic wand.

And yeah, you have to be very pragmatic about what it can solve for you and what. AI cannot solve for you. Yeah, you said it. And this is one culture I've seen because we end up working with a lot of mid-sized customers. Some of them have the right IT tech leadership so they can ask the right questions.

But most, you know, CFO, especially when the organizations are run by CFO on the IT part, it becomes scary because the mindset is, I think like CFO, so I understand their mindset. But mindset is more about saving money, then getting value, right? So more than outcome, it should be a value-driven

proposition. And how do you really determine that? And so when I ask my team and I do that too, what is the definition of done for the client? And it has to be very specific. You can say, oh yeah, the project is completed or this is deployed or whatever. It's pretty generic and abstract. How do you really measure if this is done? Because if they know, then you know, and if you know, then your team knows, and then you are delivering incrementally to get to that level, and then it's easier for a client to sign off on it. Like, AI is such an abstract term because you can up,

it's like an electricity, you can put it anywhere, right? So I generally tell my client, do not think about AI. We are the company who's thinking AI, so we think about AI. You don't think about AI. You really think about what value you want to get. Now, we can use AI to bring the cost down. But we still need to define the value. And what is the value to you if this is done through AI?

Are you ready to take those kind of risk? Because technology is not there, it will hallucinate. There are guard risks we need to think about. What are the risk you are willing to take? And what are the options if you don't want to take that risk? So most of the times they are only looking at fixed cost and hybrid team, you know, engineers who are knowledgeable? This is all good.

But are you getting the value? You know, if you are hiring a contractor, can he build a beautiful room? Can you see his work? What kind of work he can deliver at cost and per your liking. If you are not looking into those things, you're going to get doomed sooner or later. I think that's a fair point. And a lot of times we feel the client is also on the not the same page, right? The finance is saying something and engineering is in a different direction.

So you're right. Sometimes you have to put your foot down and tell. the truth. And then as I said, there's no magic wand, unfortunately. Awesome. Awesome. That brings me closer to to end the show, but I want to give you an opportunity to talk about Vich tree, what you do, how you do it. And if your potential clients are watching, what do they need to listen about Vichery. Sure. So I done an AI native technology consulting firm focused on mid-markets. So we work with the likes of Kupa, exactly. Blue Ridge, Integral Light Science.

These are all portfolio bagged companies, large private equity back companies. And essentially, in the SaaS space. So we have them built software products, digital products. We have them with DevOps, cloud, data and AI. And we are AWS partners. So we help them with cloud optimization, DevOps, infam monitoring, observability. And we are also data decks partner, which is becoming very, very important. As I said, for a lot of this AI implement.

And we are backed by a solid engineering team with a solid engineering culture. And that's possibly our secret sauce. That has so much of focus on the overall engineering, overall problem solving in the company. And that is possibly the reason why we are able to work with these amazing brands and this amazing logos. This is great. So, Delip, this is the exact conversation I wanted to have with you. This is beautiful.

So you're one of the few people building this stuff who will say out loud. that most of it never leaves the lab, and that autonomy control is a liability, not a feature. And honesty is rare in this market. We just talked about it. It is the reason people should listen to you. And for everyone listening to leave, he's the founder and CEO of Wish Tree Technologies,

found him on LinkedIn, and find Wish Tree at Wish TreeTech.com. If this episode was useful, subscribe to me at Think KiI podcast, wherever you're listening, and send it to the leader in your life, who is about to buy an AI or who is an AI skeptic or curious, and they want to build an AI agent to fix their data. You will find the answers differently.

Please send it over. I will thank you. Dave, go ahead and see you on the next one. Thank you so much, Dave, for having me. It was a pleasure. Thank you, Philipp. You have been listening to Think Yeah, podcast with Dave. Take one idea from this episode and turn it into action.

Thank you.