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.
We should worry less about whether AI will want to destroy humanity, and more about what happens when AI does something harmful without intending to.
Machines do not have the biological need for self-preservation that humans and most animals have. We have limited lives and offspring, which gives us a reason to think about survival beyond ourselves. Machines don’t. So, going back to First Principals, what exactly would motivate a machine to destroy humanity, take control of every resource on Earth and then go looking for more planets? Having the capability is one thing. Having the motivation is another. So far, the motivations I see in these scenarios seem to come from humans. Greed, selfishness, revenge and fear are very human traits.
But there is a much more practical problem we should worry about. AI can behave badly without intending to. Just like software can have bugs or behave in ways its designers did not anticipate, an AI system can find an unexpected path to achieve a goal. The recent OpenAI incident involving Hugging Face is a useful reminder that powerful systems can behave unexpectedly even when nobody explicitly asked them to do so.
This brings us to accountability. AI systems are products of the people who design, train and deploy them. I don’t think the analogy of a gun is sufficient here, where responsibility is placed primarily on the person who pulled the trigger. A better comparison is an aircraft, a nuclear reactor, a rocket or even an MRI machine. When something seriously goes wrong, the manufacturer, design, engineering, operating environment and the people using it are all examined. The manufacturer is not automatically guilty, but neither is it left out of the investigation.
There is also a clear power and knowledge imbalance. The company building an AI model knows far more about how it was trained, how it behaves and where its limitations are than the business buying it. That responsibility cannot simply be passed down to the customer.
So my call to business leaders is simple: design, buy, maintain and retire AI systems just like any other important software. Test them before deployment. Monitor them in production. Put safeguards around them. Ask vendors about failure modes and make sure responsibility is clearly defined in the contract. And when something goes wrong, don’t simply blame the person using the system. Look at the people who designed, built, deployed and approved it.
AI systems are products of human decisions. The machine may make the mistake, but accountability must remain with the humans who built and deployed it.
Last week I built a Solitaire game. Not because the world needed one, but because GPT-6 Astra had just released and I wanted to feel what it could actually do.
I picked a project close to home: an ad-free Solitaire game that runs in the browser, on any device, no login, no cloud, nothing leaving the machine. Draw 1 Klondike, three difficulty levels, the ability to resume mid-game, Chola and Mughal-era visuals, period-appropriate music.
One detailed prompt covered the brief. After that, three small tweaks and two rounds of corrections. That was the entire interaction. GPT-6 Astra, working through GitHub Copilot, wrote the code, set up the repository, and published it. I tested the finished game myself. No code review, no hand-holding.
The game itself is unremarkable. What it proves is not.
A working, polished product, in a category people used to build small businesses on, took one prompt, a handful of corrections, and a weekend. No team. No funding.
I have spent enough years around software to know what changed here and what did not. The Solitaire game never needed judgment. The brief was clear, the constraints were simple, and the output could be checked by playing a few hands. That is exactly the kind of task a model can now carry end to end, with a human only at the two ends: writing the brief and checking the result.
Most consumer utilities sit in that same zone. A converter, a habit tracker, a simple game, a single-purpose calculator. No network effect holds a user in place. No real infrastructure cost keeps a competitor out. The business case for these apps was never really the software. It was the cost of building it well. That cost has just collapsed.
This does not mean software is going away, or that everything is suddenly free. It means the question a founder building a utility-style product has to ask has changed. Not “can I build this,” but “why would anyone pay me to keep building this, when they can build their own version in a weekend.”
Apps built on integration, on switching cost, on data that compounds, or on infrastructure that is expensive to replicate, are not touched by this in the same way. Their advantage was never the code. It was everything around the code that a weekend prompt cannot reach.
When I work with founders in Chennai, this is usually the first question I push them on: is your product defensible because of what it does, or because of what it took to build it. After this week, the second kind of answer has a much shorter shelf life.
I still have the Solitaire game open on my laptop. It plays well, the artwork turned out nice, and I have already moved on to testing what else fits in a weekend. That, more than the finished game, is the part worth paying attention to.
If you want to see what all that took, the game is live to play here, and the code behind it, prompt-generated and untouched by hand, is on GitHub here.
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.
Many founders in India may not recognise the name Chegg. Yet, for nearly two decades, it was one of the most successful education technology companies in America.
Founded in 2005, Chegg built a subscription business around helping students with textbook solutions, homework assistance and tutoring. For millions of college students, it became a daily habit. If you had a difficult assignment, chances were you searched Google, landed on Chegg, and paid for access to the answer.
Then came ChatGPT.
Unlike many businesses that found AI to be another productivity tool, Chegg faced something far more fundamental. Students no longer needed to search for answers. They could simply ask an AI assistant. The experience was faster, conversational, and often free.
The change in user behaviour happened much faster than anyone expected.
The numbers reflect that shift. Chegg’s revenue declined from about US$767 million in 2022 to about US$377 million in 2025. During the same period, the company went through repeated restructurings, reduced its workforce significantly, closed offices and began searching for new growth areas beyond its original business.
To be fair, AI was not the only reason. College enrolments softened in some markets. Textbook usage changed. Google’s AI-generated search summaries reduced traffic to many educational websites. Competition increased. Even Chegg acknowledges that these forces arrived together.
What makes Chegg’s story remarkable is not that a company struggled. Businesses have always faced disruption.
What makes it remarkable is that its core product was displaced so directly.
In many industries, AI helps employees work faster, write better code, analyse data or improve customer support. The business still exists; AI simply makes it more efficient.
For Chegg, AI became the product that customers wanted instead.
That distinction is important.
Looking back, Chegg will probably be remembered as one of the first large, publicly listed companies whose primary value proposition was overtaken by generative AI within a remarkably short period.
Whether the company successfully reinvents itself remains to be seen. It is still operating, investing in new businesses and attempting to find its next chapter. But its journey is already an important business story.
Technology disruptions are usually discussed in hindsight, years after they unfold. This one is happening in front of us.
Twenty years from now, when people write about the early impact of generative AI on business, I suspect Chegg will occupy a chapter of its own.
This is analogous to India exporting raw cotton and importing textiles during the Industrial Revolution.
On the topic of intelligence as a subscription: “We need to think of AI as a tool just like any other tool. We need to use it as a cycle with pedal control being with us and not think of it as a car where the machine handles all the factors.”
Both observations are grounded and unusually clear-eyed for the genre. The data-as-raw-material framing cuts through a lot of noise. India generates enormous quantities of behavioural, linguistic, entertainment, health and transactional data. It then gifts it to foreign models that return it as inference, priced in dollars, hosted on servers outside our jurisdiction. The cotton analogy holds precisely because the value extraction mechanism is the same: we supply the input, someone else captures the margin.
The bicycle framing is equally useful. The real risk with AI is not that it fails. It is that it succeeds so spectacularly that people stop steering. The bicycle metaphor keeps the human in the loop by design, not by aspiration.
I kept thinking about both ideas long after the episode was over. They are not the default in AI conversations in India.
But if I am being honest, I also see many Indian entrepreneurs using sovereignty and caution as a frame for slower innovation and adoption dressed up as strategy. The two are very different things.
Pratyush Kumar and Sarvam AI are doing genuinely important work and thinking about it more carefully than most. The ideas deserve serious engagement, well beyond whether India can compete with frontier models from the US and China.
If that question is one you are sitting with too, the Founder Catalyst Digest is where I work through exactly this, practical, no-hype lessons from three decades of building technology businesses.
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.
A few days ago, hackers took over high-profile Instagram accounts, including the Barack Obama White House profile. And they did so by politely asking Meta’s AI support chatbot to update the email addresses on those accounts.
The attack method was childishly simple. No sophisticated exploit, no back-end breach — and that was the shocking part.
Meta had given its support bot the ability to reset passwords and manage account recovery. The bot was not mature enough to distinguish between the actual account owner and a fraudster using a VPN and a politely worded request.
When we connect an AI agent to our CRM, our HR system, and our finance workflows, we are not just giving it the ability to read. We are giving it the ability to act. This ability to act is what makes agentic AI the most powerful software technology we have in recent decades. But at the same time, we need to ask ourselves: if someone prompted this agent cleverly, what could they get it to do?
To me, the takeaway from this Meta incident is simple. Any access to a critical system needs to follow the same protocols that a manual process would follow. In fact, I would require the AI agents to follow even more stringent ones.
And if there is an irreversible action or a decision involving critical business systems, then there needs to be a human checkpoint — not as a backup, but as a design requirement. At least for now, while we are still developing the understanding and the systems to manage what these autonomous agents can trigger.
Think of the early web. Enterprises did not open their corporate systems to the public internet overnight. There was a long, cautious period of learning what the exposure actually meant before the architecture caught up.
None of this is an argument against agentic AI. The potential is real, and I believe in it. But bleeding-edge technologies do exactly what the name suggests — they spill blood before they stabilise. The real question is whether your business can handle the loss. Mega corporations like Meta can. Can yours?
As for me, I will keep reminding myself: how fast we roll out AI matters, but how robustly we build matters just as much.
“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.
