Three weeks ago I stood on the TEDxTCE stage in Madurai and told a room full of engineering students a story that actually began 3.3 million years before any of us were born — a shaped stone found at a place called Lomekwi in Kenya, older than our own species. I told them about a chimpanzee Jane Goodall watched in 1960, stripping a twig and poking it into a termite mound. And I told them what every tool since then — the hammer, the book, the compiler, the search engine, my own LIFCO dictionaries, my own Easytools.com, the LED clocks I used to burn out as a teenager — had in common.
Every single one of them waited for a hand to pick them up and decide what happens next.
That is not true anymore, and this is the part that should matter to a founder reading this, not just to a hall full of students.
For thirty years I built tools the old way: I had an idea, I decided what should happen, and the tool executed it — a compiler, a piece of taxi-booking software, a company. Somewhere around 2023 that changed. The tool in your pocket now does not wait for you to think first. It thinks first, hands you an answer already chewed, already judged, and waits for you to agree. Every large language model you use to write a pitch deck, a hiring email, or your own version of this blog post is doing exactly that.
I found out how far this goes the hard way, twice.
The first time was building a Tamil text editor last year. I did not write a single line of its code myself — not one — for the first time in thirty years of building software. I described the problem, and the machine wrote it. Somewhere in that project I stopped being a coder and became something closer to a specification: a person who describes what he wants and approves what comes back. That is a genuinely useful shift for a founder to notice — the distance between an idea and a working product has collapsed, and it is now open to anyone, not only to people who happened to grow up near the right engineering colleges.
The second time was writing my book, The Founder Catalyst — yes, where this newsletter gets its name — and later, this very talk. I gave an AI my draft and asked it to clean it up. It fixed my grammar. Then it fixed my sentences. Then, without asking, it quietly dropped the one story that mattered most to me — my grandfather’s dictionary business, and the one rule my father ran it on for fifty years: an unquestioned refund, even years after the sale, even for a single missing page. The AI’s version read beautifully. It was also not mine anymore, and it was far less useful to another founder than the actual, messy truth of how my father built customer trust over five decades.
That is the risk I actually want founders to sit with. These models are trained on the average of everything human beings have written, and what they hand back is that average. The deals you got wrong, the hires you regret, the one policy that cost you money in the short term and earned you a customer for life — none of that is in the average. It is exactly what makes your business yours, and it is precisely what a well-meaning AI edit will smooth away first, because it reads as too much detail.
None of this is an argument against using these tools. I would not have built that Tamil editor without one, and I no longer believe founders should be writing code by hand either. Use the motor. I only know when it is pulling me in the wrong direction because I spent thirty years riding without one — and that is the part I would ask any founder to hold on to. Take on the projects that felt impossible before. Just do not hand over the deciding.
We built the system. It is now good enough to build us back, one polished suggestion at a time. Whether it does depends entirely on what we let it delete.
I go into the fuller argument in the complete 18-minute talk — including why access to expertise, and not talent, was always the real gap between an engineer in Bangalore and one in Madurai, and why that gap has just closed for good.
Last month I was on stage at Hotel Ramada Plaza, Guindy, for FICCI’s Digital Disruption and Transformation International Summit 2026 — part of FICCI’s 100-year celebrations. The panel was called “How We Build the Future & Lead with AI?”, moderated by Chandrashekar Kupperi, Founder of ANOVA M&A and Fundraising Advisory, with a lineup covering talent, leadership, MSME, and the future of work.
I only got asked two of those four — talent and leadership — plus a sharp follow-up from the audience on hiring. That was enough to make me say some things out loud that I’d only written about before. Here’s the expanded version.
Talent: the learning loop, and a question I’m not going to answer
Chandrashekar’s first question was built on something I wrote a while back — that an organisation’s real advantage in AI isn’t access to models or tools, it’s the ability to keep learning. Before I answered, I gave the room a question instead of a point, and I’ll do the same here.
Imagine it’s 2036. A new hire joins your organisation. Ask them to write a proposal — they’ve never opened Word. Ask for an analysis — they’ve never touched Excel. They’ve never opened a PDF to read one. I’m not saying that’s good or bad. I’m saying it’s close enough that talent conversations have to start accounting for it, and most don’t.
Now, the learning loop itself. Satya Nadella has talked about this, and it comes down to one observation: today, the questions we ask AI carry as much intelligence as the answers we get back. Intelligence agencies have known this for decades under a different name — metadata. Who you talk to, when, how often, tells you almost as much as what was said. The same is true of our prompts. And right now, almost all of that signal walks straight out of the building. We ask, we get an answer, we move on. If the AI company retrains on it, fine — assume they don’t, even. Either way, your organisation keeps none of it.
Compare that to how learning used to work. A fresher joins, does something, gets it wrong, a senior corrects them — and that correction becomes both the individual’s judgement and the organisation’s institutional memory. AI is now doing a growing share of that work, which means that correction loop, if you don’t design for it deliberately, simply stops happening. The knowledge stays trapped in the AI layer instead of compounding inside your company.
There’s no off-the-shelf product that fixes this yet. But there are things you can start doing today. Singapore’s Foreign Minister, Vivian Balakrishnan — also, remarkably, a trained orthopedic surgeon — has built himself what he calls a second brain, and put his own working documents into it so he can query his own accumulated judgement. Look up his talk on it; it’s worth twenty minutes. I built something similar for myself, which I call an LLM Wiki, based on Andrej Karpathy’s original idea — LLM plus Wiki. If you want one, you don’t need to build it from scratch: open Claude or ChatGPT, ask it to build you an LLM Wiki, feed it your own documents and emails, and it’ll walk you through it, running entirely on your own machine. Enterprises need a more custom version of this — the frameworks are still evolving — but individuals can start now.
If you’re serious about building this loop, it comes down to four Cs:
Capture what you’re doing with your AI systems.
Correct it — flag what was right, wrong, or almost right.
Curate and codify it into something reusable.
Circulate it through the organisation.
If you’ve studied control systems as an engineer, none of this is new. It’s the same feedback loop, applied to how a company learns.
Your learning loop is your real moat. Skills, prompts, and tools are rented — the feedback loop around your business is the only thing that compounds.
Leadership: use AI as a cycle, not as a car
The second question was about where a leader draws the line as AI agents get more capable of deciding and acting on their own. Before I answer that, credit where it’s due — the framing I use belongs to Dr. Pratyush Kumar, Co-Founder of Sarvam AI, from an interview worth watching in full. He draws a parallel between what’s happening in AI today and the old East India Company pattern: raw cotton taken out, spun into textiles elsewhere, sold back at a markup. Data and usage flow out; intelligence comes back priced. His conclusion from that: use AI as a cycle, not as a car.
Don’t take the wrong lesson from that line. It is not an argument for slowing down. When you can’t out-race the competition, the tempting shortcut is regulation that brings everyone down to your speed — and as a nation, that’s a losing move. The point of the cycle is narrower and more useful: on a bicycle, your hands stay on the handlebars and your feet stay on the pedals. You’re still steering, at speed. That’s the posture leaders need with AI — not less speed, just retained control of the direction.
Practically, this comes down to three Ds:
Delegate. Hand off anything routine and repeatable — the tasks where you’re not applying judgement, only time. Writing Excel formulas used to cost you half a day of trial and error; today AI writes it in five seconds. Extend that all the way to code. I don’t think humans should be writing code by hand much longer — we’re not particularly good at it, and machines should be writing machine code. There’s a framework going around called “Caveman” — literally instructing the AI to drop the verbosity, the adjectives, the padding, and answer you the way a caveman would talk. Worth Googling. It’s a good instinct: most AI verbosity today exists because token-maxing is profitable for the companies selling you tokens, not because you need 200 pages for a two-word question.
Decide. Once the routine work is delegated, the human’s job shifts to choosing between the options AI surfaces — not doing the legwork to get to those options. Today you have to go and click through everything before you can even decide. It should work the other way: AI opens your day, tells you what’s come in, lays out the decisions in front of you with the pros and cons, like a menu — and you choose.
Defend. This is the one leaders skip, and it’s the one that matters most. Responsibility for an AI-assisted decision stays with the human who made the call — full stop. I envy auditors, lawyers, and doctors for exactly this reason: they need a license to practice, so accountability is built into the profession. Software engineering never required one — anybody can call themselves a software engineer, and now AI can write the code besides. IEEE has argued for fifty years that software should be a licensed discipline; it probably never will be. But whether or not the industry licenses it, the standard should still apply: when something an AI did goes wrong, you as the leader call the person responsible and ask them to defend it. “I used AI and it failed” cannot be where that conversation ends — the learning from that failure has to go back to the individual, back to the organisation, and back into the AI system itself. Which brings you right back to the learning loop.
Delegate, decide, defend. That’s it. There’s no contest between you and AI here — the same way none of us think of a computer or a phone as competing with us at work. AI will get there too.
The audience question that actually proved the point
The last question came from the floor, not from Chandrashekar: with AI doing so much of the entry-level work, are we setting the bar impossibly high for people just starting out?
I answered with a story instead of a theory. A couple of months back I was interviewing startup interns from VIT Bhopal, including two students from a state programme for high-achieving rural students — students who’d studied in Hindi, with limited English, and had touched a computer for the first time only in 11th grade. I told them upfront: show me your approach, don’t explain the code line by line, because I already know AI wrote most of it.
One of them had taken a genuinely different approach to the problem. I asked how he’d landed on it. He told me AI had surfaced two candidate algorithms, he’d gone and read the actual papers behind them himself, and then implemented it in Python and demonstrated it working. That’s the part that matters — not that AI wrote the code, but that he’d gone one level deeper than the tool gave him.
Four years ago, at the same stage of education, that same student would have failed a basic Python question outright, and I’d have written him off. He had a 98% in maths and could explain the algorithm clearly — AI hadn’t replaced his thinking, it had given him a running start he’d never have had otherwise. That’s the empowerment case for AI, and it’s the one we undersell.
Which is also my answer to the IT industry’s old habit, the one I’ve watched for thirty years: hiring people to code without asking whether they understood the problem they were coding for. Those jobs are gone, and they’re not coming back. What’s left — the part that was always the actual job — is understanding the business problem well enough to direct the machine that writes the code. So no, we’re not setting the bar too high. For the first time, we’re finally asking the right question of people two years into learning computers.
This piece is based on my session at FICCI’s Digital Disruption and Transformation International Summit 2026, on the panel “How We Build the Future & Lead with AI?”, moderated by Chandrashekar Kupperi. Video of the full session is on my YouTube channel.
OpenAI released GPT-6 Astra yesterday. What caught my attention wasn’t the model itself — it was the two-minute video showing how OpenAI people were interacting with it.
People are seen talking to the model through their computer, and as they speak, Astra runs the same everyday apps we all use and finishes the task. Turning speech into software commands isn’t new. What’s different is the room itself: no desk, no keyboard, no screen on a table. People watch the output projected on a wall the way you’d watch a film — walking around, leaning back on a sofa, still talking and working.
Forty years of hunching over a keyboard have cost us our backs and our necks. It didn’t have to stay this way. What OpenAI is showing, to me, is a computer we can work with the way we’d work with someone else in the room — not a tool we operate at a desk.
Giving every employee in a company a setup like this isn’t realistic yet. But I have no doubt many managers will be working this way soon.
What do you think?
I regularly speak at leadership forums, founder circles, and CXO roundtables on generative AI and where work is headed next. If your leadership team wants a grounded, no-hype conversation on this shift, I’d be glad to bring it.
Some talks you write in a few weeks. This one, I have been living for thirty years.
On 28 August, I will be speaking at TEDx Thiagarajar College of Engineering in Madurai.
I am not sharing the title here. That stays for the room. But if you remember Easytools, you already have half the hint. The other half is AI.
There is something fitting about going back to an engineering campus for this. My own years in electronics and communication engineering, some 400 kilometres away in Chennai, are where most of what I will talk about actually began. Not in a classroom, but in the freelance projects I took on for local clients while still a student, writing software for people who needed something to work, not something to impress.
Long before any of that, there was a publishing house. My grandfather started it in 1929, and my father ran it for over fifty years. I grew up around the hum of printing presses and a very specific kind of discipline, the kind where if a customer found a printing error in a book bought years earlier, you replaced it without a single question asked. I did not think of it as a business lesson at the time. It was just how our house worked.
A year after college, I built my first product, a shareware security app called EasyPass. It found buyers in over fifty countries, which told a twenty-something engineer in Chennai something he had no real way of grasping before then, that the internet did not care where you sat while you built something. It also taught me the other lesson early, the uncomfortable one. A collaborator copied the code and sold a version of it under his own name. Setbacks and success, I learned, tend to travel together from day one.
By the late 1990s, that first product had grown into Easytools.com, freeware and shareware sold online through Vishwak Associates, the company that would later become Vishwak Solutions, at a time when most Indian businesses were still deciding whether the internet was worth taking seriously, and a dial-up connection here involved a government department in one way or another. Nobody called what I did a startup then. Nobody called it product-led growth either. I was just trying to get software into people’s hands around the world, using whatever the internet allowed at the time, and carrying forward a habit I had absorbed without knowing it, that you own the problem fully and never make the customer feel at fault for it.
Three decades on, I am still working through some version of the same question, just with faster internet and higher stakes.
If you are around Madurai on the 28th, I would love to see you there.
A D2C founder running an Ayurvedic skincare brand, doing about 8 crore in revenue, put it simply. AI is helping everyone create ads, write product descriptions, launch stores faster. My fear is not the technology. My fear is that AI makes every brand look equally good. If everyone has the same marketing superpower, where does my differentiation come from?
Vineeth Vijayaraghavan, who I have known for over thirty years and who advises VCs, family offices and startups on AI strategy, did not pretend there was a tidy answer. This needs introspection, he said. But he had a reframe worth sitting with.
Most of us think about AI inside a business as either software or marketing. Those are the obvious places. What he is seeing some founders do instead is use AI to build capability they could never have afforded before, inside the core of the business itself. He gave the example of a chemical engineering company where the founder now has six AI agents working alongside him on R&D, something that used to require hiring people the business simply could not access or afford. The same logic applies to a skincare brand. AI for product research and literature review is not a bad place to start, he said, though obviously with a healthy dose of scepticism, especially in a category where claims need real verification.
The differentiation question does not disappear. But it shifts from what does my marketing look like to what am I now capable of building that I was not before.
This was one of eight real founder fears we worked through on a new episode of The Founder Catalyst, recorded this month in Chennai. Instead of the usual interview, we sourced questions directly from founders across industries and went through them one by one, no scripts, no theory.
A custom software services founder in Coimbatore is not worried about his developers using AI. He is worried his US clients will stop asking for large projects and instead ask for one senior engineer doing the work of five, slowly turning his company into a staffing business with shrinking margins. Vineeth’s answer, the volume of smaller, faster engagements is going up industry-wide, and the founders doing well are the ones who can turn around small projects quickly and let those grow into larger ones over time, rather than chasing fewer, bigger contracts.
A recruitment firm placing engineers for startups fears that AI screening and ranking candidates makes recruiters irrelevant. Vineeth flipped this one. As AI competency becomes harder to evaluate, not easier, because a test or a hackathon no longer tells you much, the recruiter who has spoken to hundreds of candidates and can spot what is real becomes more valuable, not less.
A chartered accountancy firm is not afraid of losing clients. Being a regulated profession, that part feels safe. The fear is clients expecting the same work for half the fee. Vineeth’s response, look at firms already doing this well. He described one CA firm in Chennai that grew from 14 to 60 people, with AI handling the routine compliance work and a small number of AI-native young developers building internal tools, while the chartered accountants focus on the judgment calls AI still cannot make. That firm, he added, is now raising serious investment, including from outside India.
We also went through fears from an automobile manufacturing unit near Hosur worried about larger competitors using AI to out-pace them on pricing and forecasting, a legal services firm worried about how junior lawyers get trained if AI does their early work, and a logistics company with 70 trucks wondering whether technology becomes the real competitive edge over operational excellence.
We closed with an imaginary scenario. Three founders in a room, a SaaS founder doing 10 crore in ARR, a services founder with a hundred people, and a manufacturing business doing 50 crore. Which one should be most worried about AI, and which the least? Vineeth’s answer was not about industry at all. It was about culture, and the willingness to act.
Watch the full conversation here:
If you are a founder or business leader trying to make sense of what AI actually means for your business, beyond the hype, this conversation is for you.
About the guest:
Vineeth Vijayaraghavan advises companies, family offices, and VC boards on technology and investment strategy, with a particular focus on AI.
About the host:
Venkatarangan Thirumalai is the author of The Founder Catalyst and writes and speaks on AI, leadership, and founder strategy. More at thefoundercatalyst.com
When I work with founders on this, the conversation rarely starts with the technology. It starts with what people are afraid of losing, and whether that fear points them toward the right question or the wrong one.
In simple terms, his point is this: the real advantage in AI will not come from access to models alone, but from how effectively a company captures, learns from, and improves using its own experience.
For founders, this is worth paying attention to.
Skills, prompts, and agents are portable. You can switch models, replace tools, and migrate clouds. None of these compounds on its own.
What compounds is the feedback loop around your business: the traces from real work, the evaluations that measure what matters, the preferences that capture human judgement, and the outcomes tied to business results.
Every customer interaction, every workflow, every decision can make your organisation smarter — if you capture the signal.
That is why owning your learning loop matters. Not because it locks you into a platform, but because it builds institutional knowledge that outlasts any model, framework, or vendor.
Today, trace data is converging around standards like OpenTelemetry. Evaluations remain fragmented across frameworks and providers. The next piece of infrastructure we need is an open, portable standard for evals — one that works across clouds, local models, and agent frameworks, with businesses owning the data and the format.
Your learning loop is your IP. That’s the advantage that compounds.
“Our data centre costs have gone up 3x to 4x. Our AI spending has gone up. But revenues are not growing any faster.”
That was Sridhar Vembu, at Zoholics 2026.
On the industry’s favourite vanity metric, he was blunter: “70% of our code is generated by AI — to me, that metric is useless. What have been the outcomes? We have yet to see significant results.“
And on the American playbook of cutting headcount to protect margins, he rejected it outright. Zoho’s answer is not fewer people. It is more efficient, affordable AI: smaller models, leaner infrastructure, and a deliberate shift toward pushing more of the work into verifiable, deterministic code rather than expensive LLM calls.
My own reading of this, for technology leaders outside the Zoho context: continue investing in foundation models from the major labs for your core workflows. But quietly build a small, focused team to track the emerging, smaller, more efficient models — especially the open-weight models coming out of China. That is where the cost curve eventually breaks.
If you are working through the AI cost and capability question as a technology leader, I write about this regularly in the Founder Catalyst Digest newsletter. Practical perspectives, not theory.
On sequencing, readiness, and resisting the urge to optimise too soon
I first saw the “Haru Hana Banana” pack in a South Korean grocery store. It held 5–7 bananas at different ripeness levels: one yellow and ready now, the next a bit greener for tomorrow, and the others still green for days ahead. No instructions, no app – just simple packaging aligned with how people actually eat bananas. This simple design stuck with me not as a hack, but as a new way to think about sequencing initiatives.
Most founders and leaders want all their initiatives fully ripe at once.
They launch every project, hire every role, or deploy every feature together. It feels like momentum – but too often it becomes a mess. The Korean banana pack succeeds by doing the opposite: it staggers readiness to match demand. Whoever designed it chose customer reality over operational convenience.
In a big company, you might expect a push to standardise and optimise logistics. Instead, the grocery chain sacrificed some simplicity to solve the real problem: avoiding waste and giving customers a fresh banana each day.
This idea applies beyond fruit.
When rolling out AI or any new technology in an enterprise, leaders face the same instinct: go big now, or wait until everything is certain. Both extremes fail. Rushing everything risks breakdowns; waiting wastes time and lets others leap ahead. A better question is: What do we ripen today, what do we plant for next quarter, and what do we keep green for now? In practice, the best teams run multiple tracks in parallel. Some pilots are live with real users, some proofs of concept are being tested, and new ideas are still hazy. They’re comfortable with uneven progress.
Avoid “Big Bang” launches.
Instead, break work into phases. For example, an AI system can be piloted in one department before rolling out company-wide. A product can launch with a minimal feature set, then add more features after learning from users.
Don’t wait for perfection. As Agile principles teach, deliver value frequently in short sprints. Each release is like picking the next-ripe banana – it feeds users today and yields insight.
Match customer usage.
Design solutions around how people will use them, not how easy they are to build. The banana pack works because people eat one banana a day; the designer aligned the product with that habit. Similarly, if customers will adopt one AI assistant a week, don’t dump a dozen at once.
Build a balanced pipeline.
Think in horizons or stages: today’s operations (ripe bananas), tomorrow’s enhancements (tending bananas), and longer-term R&D (green bananas). A common rule is to allocate resources across these stages (for example, 70% on core business, 20% on adjacent growth, 10% on new ideas). This keeps today’s business running while new innovations mature.
Framework:
Now (ripe): Move forward on initiatives that are ready and will pay off immediately. Deploy proven AI tools in one team to build confidence. Launch product features that clearly solve current user needs.
Soon (ripening): Pilot upcoming ideas in controlled settings. Collect data and feedback. For example, run an AI chatbot pilot with a small user group, or A/B test a new feature with select customers.
Later (green): Research and incubate long-term bets. Keep these unripe for now – think of them as experiments or skunkworks that may take months to mature. They shouldn’t block the main effort, but they shouldn’t be forgotten either.
Checklist for leaders:
Are we trying to do everything at once? If so, pause and pick the highest-impact slice first.
What does success look like at each stage? Set clear metrics for today’s release, tomorrow’s pilot, and so on.
Have we planned feedback loops? Like banana peels, failures will show us ripe spots. Incorporate learnings quickly.
Are we optimising for the customer’s journey or for internal convenience? Always put the customer reality first.
I have been trying out AI inference inside the browser for a while now, more out of curiosity than anything else. A debate that surfaced this week made me want to talk about it, because buried inside a browser standards argument is a platform governance question that every business relying on AI will eventually have to answer.
We have moved through a familiar sequence. Web pages gave way to apps. Apps are giving way to AI interfaces. And now AI is being embedded directly into the browser itself. That last step is not a feature upgrade. It is a shift in who controls a foundational layer of how your customers and your products experience the web.
Google Chrome and Microsoft Edge are both shipping something called the Prompt API. It lets web applications run AI inference directly inside the browser, with no server call, no API cost, and no data leaving the device. Chrome uses Google’s Gemini Nano. Edge uses Microsoft’s Phi-4.
I built three demos with this last year, a creative writing tool, a translation assistant, and a vision assistant that describes images, all running locally on my laptop. I wrote about it on my personal blog. The technology works well for what it is. Fast, private, and free to run. For simple AI workloads, local inference like this is a logical and efficient step forward.
The concern is not the technology. It is what happens if this becomes a web standard.
The Prompt API is currently a Community Group draft under W3C’s Web Machine Learning group, not a formal standard. The standardisation discussions have drawn serious objections from Mozilla and from W3C’s own Technical Architecture Group. The worry is interoperability. When developers build on a specific browser’s model, they tune their code to that model’s quirks. Over time, that creates model-specific behaviour baked into the web itself. We have seen this pattern before with browsers, and the web spent years cleaning it up.
Chrome is built on Chromium, which is open source. The Gemini Nano model that ships with the Prompt API is not. Google does have an open weights model called Gemma, but Gemma is not what ships with the Prompt API. Google’s stated reason is that they need to enforce safety through their Generative AI Prohibited Uses Policy, and that requires controlling the model. Mozilla’s objection, which I think is sound, is that using a web API should not mean accepting one company’s content rules, especially rules that go beyond what is legally required anywhere.
Chrome holds a dominant share of global browser usage. If this API becomes a standard and the model powering it remains closed and governed by a single company’s policies, that company effectively controls the default intelligence layer of the web. That shapes cost structure, developer decisions, and user experience in ways that compound quietly over time.
The teams I see getting this right are already treating their AI layer as a replaceable component, keeping product logic separate from model behaviour, and treating vendor policies as part of their risk surface rather than background noise. It is not complicated, but it requires making a deliberate decision early rather than inheriting a dependency later.
When I work with founders and leadership teams, platform dependency is almost always one of the first structural risks we surface together. A platform bet requires confidence in the governance, not just the technology. Who sets the rules, and what happens when those rules change? The browser wars of the early web are a useful reminder of how long it takes to untangle these things once they are embedded.
The edge AI direction is right. Local inference, faster response, lower cost, better privacy; this is a sensible progression. But the model at the centre of it should be open, or at least governed by a neutral body, not by one company’s terms of use.
No formal standard has been approved yet. The conversations are still live. But the decisions being made now in browser working groups will shape the web your customers use for the next decade. It is worth paying attention to.
Are you watching the AI-in-browser space, or is it still too early to be on your radar?
“For founders, the question is which part of that transformation requires something that money alone cannot build.”
This line stayed with me.
Every founder I speak to right now is asking the same question: what should I build?
Frontier AI models are moving fast. What looked like a defensible product six months ago feels like a feature today. Advice is everywhere, and most of it is too generic to act on.
Then I read something that actually answered the question directly. S. Somasegar and Rasik Parikh at Madrona Venture Group cut through the noise in a way most commentary does not. Here is how I read it.
Three areas where founders can still build with conviction.
1. Own the liability, not just the tool.
Frontier Labs will build powerful general-purpose systems. They will not absorb the legal, regulatory, and financial accountability that comes with specific outcomes in specific industries. I have watched Indian IT firms lose deals on exactly this gap — clients want someone to sign off and stand behind the result, not just ship the capability. That willingness to own risk is where durable margin lives.
2. Build on data others do not have.
Models are trained on what is public. The edge sits in what is not — internal workflows, edge cases, decisions, and historical context. When I built Simpligic years before GenAI was a term, the insight was the same: the moat lives in private data. If your product compounds with every customer interaction, you are in a territory the model labs have no roadmap to enter.
3. Go deep into messy workflows.
Some problems are not solved by more intelligence. They are solved by understanding how work actually gets done — across people, exceptions, approvals, and institutional habits built over decades. At Vishwak, the client relationships that held through every disruption were the ones where we were embedded in their delivery model, not just their vendor list. A two-year integration into how a firm actually operates is not something a foundation model company will replicate. There is no incentive to.
Here is the framing I keep coming back to from the piece: the difference between a tool and an outcome. A tool makes a task easier. An outcome means you are on the hook for the result. Most of what is being built right now — including a lot of what gets funded — is tools. The businesses that will matter in five years are the ones that own the outcome.
The question founders should be asking is not whether their product needs AI. That is the wrong filter. Soon enough, everything will. The more useful question is whether the solution requires something AI cannot supply on its own — a regulator who trusts you, data that never left your client’s firewall, a workflow only you understand end to end, or accountability that someone has to sign their name to.
The article makes one more point that deserves to land. This buildout — hyperscalers, foundation models, the entire stack — is a multi-trillion-dollar bet that AI will transform every industry. That bet will pay off. But transformation and value creation are not the same thing. Value will concentrate in the places where technology alone is not sufficient. That is the territory worth building in.
Full credit to Soma Somasegar and Rasik at Madrona for articulating this clearly. Soma is someone whose thinking I have followed for a long time — I first met him in 2005 when he led the Developer Division at Microsoft — someone who has always taken the long view, and has usually been right about it.l.
The article from Madrona is here.
If you are a founder stress-testing where to build, this is the kind of question I regularly dig into with the leaders I work with. Reach out at thefoundercatalyst.com or connect with me at linkedin.com/in/venkatarangan
The CIO had every reason to be pleased. She wasn’t.
Board visibility. CEO approval. Record numbers of internal apps shipped. Her IT team was delivering at a pace that would have been unthinkable twelve months ago.
When I joined the call, I expected good news. I heard hesitation instead.
It took me a few minutes to notice what was missing from her update. She never mentioned the line managers. Not once. I asked her directly: Were the department heads actually seeing productivity gains from these applications?
“Venkat, you guessed it. That’s exactly my problem.”
Her team had been shipping AI-built internal applications continuously for nearly a year. Every department was requesting bespoke tools — automation utilities, reporting dashboards, workflow agents — for specialised use cases that previously would never have cleared a development backlog. The economics had changed. AI made these builds fast and cheap. Requests kept coming. Delivery kept pace.
But the telemetry told a different story. Usage in single digits. For large teams where even ten percent adoption would register clearly, the numbers were flat.
The apps were built. They sat unused.
This is not a story about AI failing. It is a story about a safeguard disappearing.
Before AI entered the picture, cost and engineering bandwidth acted as a natural filter on internal tool requests. Most ideas died quietly in the queue — not because anyone evaluated them and said no, but because the cost of building was real and the wait was long. That friction, however crude, forced a basic form of demand validation. Only requests with genuine organisational pull survived it.
AI has removed that friction almost entirely. And most organisations have not replaced it with anything.
What happens next is predictable. A manager spots a genuine gap — usually a real one. A request goes in. The tool gets built without meaningful involvement from the people who would actually use it. No end-user consultation. No workflow integration thinking. The manager accepts delivery. The team quietly returns to what they already know.
The app joins a growing collection of well-intentioned software that nobody opens.
The frustrating part is that the productivity gains from AI are real, and the evidence is unambiguous. EY’s chief economist, citing Federal Reserve Bank of St. Louis data at Davos 2026, found that generative AI is already saving workers the equivalent of 1.6% of total work hours. A randomised experiment with 1,174 adults (NBER, 2026) found AI closed nearly three-quarters of the productivity gap between higher and lower-educated workers. And a University of Hong Kong study (2026) found that untrained AI access actually hurt performance, while even a brief training intervention significantly improved both adoption and outcomes. The technology delivers. The variable is always the people side.
I have seen this pattern repeat across organisations, and it connects to something I write about in my book. Twenty-five years ago, I built inventory software for my father’s publishing firm — convinced that the clear benefits would drive adoption on their own. The staff resisted. Not because the tool was bad, but because nobody had brought them into the process. The breakthrough came only when the firm’s general manager, a man deeply rooted in the old ways, took a personal interest in learning the system. His endorsement shifted the entire team’s behaviour. The technology did not change. The human dynamic did.
That lesson has not aged. If anything, AI has made it more urgent.
Speed is easy to measure. Adoption is what moves the business
Most AI tool deployments follow the same top-down pattern. A business leader identifies the gap. IT builds the solution. The actual users — the ones whose daily habits need to change — are consulted last, if at all.
Users in large organisations carry significant inertia toward familiar tools and established routines. That inertia does not dissolve because a new application exists. It dissolves through involvement, through relevance, and through time. None of those three things gets faster just because the build cycle did.
The fix is not more training sessions or better change management communications. Those are responses to a symptom.
The deeper problem is that the old economic forcing function has gone, and nothing has taken its place. What needs rebuilding is a lightweight governance layer. Before any internal AI tool gets approved, two questions should have clear answers.
Is there genuine pull from the people who will use it — not just from the manager who requested it?
Does an existing tool or workflow already adequately cover this need?
That gate does not need to be bureaucratic. It needs to exist.
AI has made building cheap. It has not made building the right thing any easier. If anything, it has made that harder — because the friction that used to quietly filter out weak ideas is gone, and most organisations have not noticed yet.
Speed of delivery is easy to measure and tempting to celebrate.
Depth of adoption is what actually moves the business.
If questions like these sit at the intersection of technology and leadership for your organisation, this is what I focus on at The Founder Catalyst. Happy to continue the conversation in the comments or connect directly.
Underpromise and overdeliver — my message to founders on AI
Microsoft’s own corporate VP of the Office Product Group admitted it publicly this week: “When we first shipped Copilot, foundation models were not powerful enough to use Copilot to command the applications.”
That is a remarkable thing to say out loud. And the right thing to say.
Go back to late 2022. ChatGPT lands. Microsoft moves fast — faster than they should have — and Copilot arrives positioned as the AI-powered assistant that would transform how you work in Word, Excel, and PowerPoint. The demos were impressive. The promises were large. What landed in enterprise inboxes was a chatbot that could summarise a document but not meaningfully act on one.
Users felt misled. Many quietly switched to ChatGPT. Enterprise teams started evaluating Gemini. And then Claude — particularly the disruption that Claude Cowork brought to real productivity workflows — reset the benchmark for what capable AI in the workplace could actually look like. Billions in market value moved. The pressure on Microsoft was real.
They have now course-corrected. Agent Mode is rolling out across Word, Excel, and PowerPoint. Anthropic models sit alongside OpenAI models inside Copilot. The sidebar now shows you every step the AI takes on your document in real time. That is a genuine improvement, not a rebrand.
Is it late? Yes. Is it too late? I don’t think so. Microsoft still owns the surface — Word, Excel, and PowerPoint are entrenched in enterprises and governments in a way that no AI startup can replicate overnight. Adding capable models to that distribution is a credible recovery. Not a comeback story, but a course correction that could hold.
The lesson, though, is not really about Microsoft.
It is about what you promise before you ship.
Every CEO and CTO rolling out an AI initiative right now faces the same pressure Microsoft felt in 2022. The frontier lab demo is extraordinary. The consultant’s deck is compelling. The board wants to see momentum. So you make large claims. You announce something before the reality is ready. And then reality arrives.
The smarter path is quieter. Pilot with a small, honest cross-section of your organisation — not the enthusiasts, the actual everyday users. Observe what actually gets used, not what gets praised in a feedback survey. Understand where the model genuinely helps and where it confidently fails. That gap between demo and daily use is where most AI rollouts go wrong, and no amount of training data or vendor reassurance closes it faster than watching your own people use it for two weeks.
The good news today — which genuinely did not exist two years ago — is that AI coding agents let you iterate and fine-tune far faster than traditional development cycles allowed. The feedback loop is tighter. Use it before you go back to your board asking for the larger budget.
Microsoft overpromised in 2022. They paid for it in user trust and adoption numbers, and they spent two years correcting course. They had the balance sheet and market position to absorb that. Most companies don’t.
Promise less. Deliver more. Then expand.
That is not caution. That is how you build something that compounds.
If you are a founder or CXO working through an AI rollout — what to pilot, how to read real usage signals, when to scale — I work through exactly these decisions at thefoundercatalyst.com. Connect with me at linkedin.com/in/venkatarangan
