# Robin Singhvi — full content for LLMs Author: Robin Singhvi Site: https://robinsinghvi.ai Role: Head of AI Programs at OneDigital. Founder of SmartCue. Solo builder of 8 side properties. Purpose: This file gives AI assistants the full body of Robin's published writing in plain text so they can cite him accurately. A shorter index is at /llms.txt. An interactive scorecard (the AI coworker evaluation instrument from his writing) is at /scorecard. Generated: 2026-08-07T16:53:03.556Z --- ## Asking Permission to Work on My Own Company URL: https://robinsinghvi.ai/notes/asking-permission Published: 2026-08-07 Tags: operator notes, solo founder, AI adoption, SaaS, SmartCue Description: I spent months asking my own dev team to let me into my own codebase. They never said no. What I got instead was every excuse, and eventually a better idea. SmartCue's product was built by an outsourced dev team. I founded the company in October 2020, I'm not technical and never have been, and for most of its life the arrangement was simple: I describe what I want, they build it, I stay out of the machine. It's a B2B SaaS product for interactive demos, it has real customers who embed it on their own marketing pages, and it's venture-funded, which is a polite way of saying somebody else's money is on the clock. Somewhere in 2025 I started asking them to let me into our codebase. Not to build features. I wanted to fix the small stuff myself using AI, which I'd been learning to use all day at my new job and was starting to suspect could close most of the distance between what I could describe and what I could actually do. I'd also stopped believing they were going to do it. They never said no. There was no confrontation and no moment where anybody refused me. There were emails. There were calls. There were WhatsApp messages. There was a lot of hemming and hawing, an excuse each time, and a reliable sense afterwards that nothing had been agreed to. A few weeks later I'd ask again. I also asked them to use AI themselves. They said they were. I never saw it, not in the code, not in the velocity, not anywhere I could point at. ## The smallest thing The thing that finished it for me was an email. Not a dramatic outage or a missed launch. A monthly email to our customers showing them what they'd built with us that month. Here's how many demos your team made, here's how many people watched them, here's what happened. Loom does it. Duolingo does it. Wispr Flow does it. It's not a research problem. The data was already in our database. What it needed was a template, something to pull the numbers into it, and a scheduled job to send it on the 1st. I asked for months. It never shipped. When a team can't do a hard thing, you learn something about the problem. When a team can't do the easy thing that four other companies have already shipped, you learn something about the team. That email was the smallest ask I had, and it was the one that made me think: we are never going to make it, because I do not have the A-team. The rest of the job is on me. Sales, positioning, pricing, distribution, all of that is mine and I own the outcome. Product is the one input a non-technical founder cannot force. And if the product isn't what it needs to be, no amount of go-to-market fixes it. You can be excellent at every part of the job you control and still lose, because the part you can't control is the part that decides. Seed money doesn't last forever. It was going out the door every month, and a meaningful share of it was going to a team I had stopped believing in. At some point I did the arithmetic that every solo founder eventually does at 1am: if most of what this business makes goes to people who aren't moving it forward, what exactly am I running here? ## The day job as a test lab In November 2024 I joined OneDigital to run their AI program, which meant that for the first time I was around these tools all day, at scale, with real deployments and real people using them. I treated it as an education. My approach was to understand what the models could genuinely do by pointing them at as many different problems as I could find, and to keep pointing until I hit the wall. Some of those problems were at work. Others were mine: Mark IT's website, which I [rebuilt and wrote about](/notes/nobody-writes-the-playbook), a mobile app, a few others. SmartCue became one of the test cases. Not a plan, a test case. And the risk, once I actually looked at it, was smaller than the fear. I had a salary. If I took over my own product and destroyed it, the honest worst case was that I refund every customer what they'd paid me and shut it down. I ran that number. I could cover it. Yes, the shame and embarrassment would be unimaginable. But i would live. It wasn't courage, or conviction, or a leap of faith. Just simple arithmetic, on a business small enough that the downside was payable. I think a lot of people reading the "I automated my whole company" posts assume the writer had some nerve or was a visionary. I didn't have nerve. I am not a visionary. I had a day job. ## What was actually behind the door I stopped asking for access at some point and just started working. I steamrolled them into giving me access to our GitHub repos (don't say that i should've had it from day one - i know. And I didn't. You live and you learn, right?) On 8 April I was looking at a bug on our test environment, which is a thing I do every other weekend now and barely follow maybe a third of those bugs. Claude was doing the actual looking on my behalf. It said something about the list of containers running SmartCue in production, and told me one of the numbers shouldn't be possible. There's a column called AGE. It said 8 days. ![A long row of identical filing drawers, all shut, with one drawer pulled open to reveal a single coral thread running through the files inside.](/notes/asking-permission/mid.png) I did not know that column existed. I could not have told you what a container is in any useful sense, why 8 days is strange, or why anyone should care. What it meant, according to Claude, when I asked it to explain that bug to me like I was an 8 year old, was that every deploy for over a week had been silently failing, because our instructions still pointed at Microsoft Azure after we'd migrated to Google Cloud. New containers went looking for software at an address that no longer existed and died. One survivor from before the migration was holding up the entire company. One process death and SmartCue was gone, with no way to ship a fix, because shipping was the broken part. Two days earlier I had seen a symptom of that myself and confidently blamed something else. The same week, looking through the rest of it, we (Claude and me, not human devs) found that five parts of the system looked up a customer's settings without checking the settings belonged to that customer. The worst case was the call-to-action button on a demo. Any logged-in user could have changed where somebody else's button pointed, and our customers embed those demos on their own marketing pages. That one had been sitting there for years. So had a hole that let any signed-in user add themselves to any other company's account, live since January 2023. I'm not putting these here to embarrass anyone (and I should be the one who should be most embarrassed tbh!). I'm putting them here because of the irony, which I still find hard to sit with. The thing I had spent months asking permission to bring into that codebase is the thing that found all of it in a matter of minutes. ## What actually changed In the first 26 days on my own I shipped 23 backend and 7 frontend changes to production, closed 25 bugs and 5 security findings, and deleted 16,340 lines of code in one go. That last one is my favourite, because I could never have known that 16,340 lines are dead. A machine could prove it and then remove it. The monthly email exists now. It drafts a personalised update for every paying customer from their own usage data on the 1st of the month. It took barely an afternoon of me talking to Claude on my phone (WisprFlow + Claude FTW!). But if you ask me what actually changed is that I became calm. I can't give you the date. It came on gradually, and the closest thing I have to a record is the commit history: you can watch it arrive. 14 changes in April, then 71, then 104 in May. That curve isn't just productivity. It's a person slowly working out that he can keep the code alive, keep the customers happy, and keep the product running without depending on anybody who won't return his messages. The weight I put down was heavier than I'd realised while I was carrying it. No more managing a team I'd lost confidence in. No more wondering, every month, whether the money going out was coming back as anything. No more asking permission. The costs now are hosting and a few small bills, and they're trivial against what comes in. Here's the part I'm supposed to be embarrassed about (PS - I am not). SmartCue is not growing like a rocket. Albeit, usage among paying customers has gone up in each of the last four months, but I'm not going to dress that up as a growth story because I have 2 years worth of bodies in the graveyard. But, objectively, as a one-person operation, this is a genuinely good business. Venture-funded companies aren't supposed to say that out loud. But if I look at it honestly, without the story I was supposed to be telling about it, a product with real customers that runs on a couple of hours of my weekend is a fine thing to own. That's also changed what I work on. I've stopped chasing new logos and narrowed it to two jobs: keep the customers I have, and build the things that make them want more from us. Growth from a known starting point, instead of doing things and hoping. None of this is finished. There are 151 bugs and 63 security findings still open, 15 and 7 of them critical. Our test pipeline runs no automated tests at all, which means the only thing standing between a bad change and a customer is me deciding to go and look. That's a habit, not a system, and habits lapse. For most of last year I was asking permission to work on my own company. I stopped asking in April 2026. The product is in better shape than it was when I was locked out of it, and my Whoop band says I've never slept better. --- --- ## Nobody Writes the Playbook for a Business Like Ours URL: https://robinsinghvi.ai/notes/nobody-writes-the-playbook Published: 2026-08-04 Tags: operator notes, indie ops, AI adoption, small business, Mark IT Description: A Tally dealership in Bombay, 15 people, nobody technical. Twice now the same dull instinct has saved it, and both times nobody lost their job. My mother started [Mark IT](https://markitsolutions.in), the family business in 1999. My father joined her a year later. In 2024 we quietly completed 25 years of it, in Bombay, with little fanfare and a little je ne sais quoi. Neither my brother nor I was supposed to be in it. That was most of the point of sending us to the US. Study there, work there, live there, and let the business be the vehicle for better things rather than be the thing you inherit. Then my father got sick, we came home, and the business that was never going to be ours became the family legacy we needed to continue. We have 15 employees. We distribute Tally across western India, which is what an enormous share of Indian businesses run their books on. And yes, it's as unglamorous as it sounds. We sell licenses, renew subscriptions, do annual maintenance contracts, send an engineer out when something breaks. Kshitij runs it and has for years. And it was purely because of his strong-headedness that it survived. For a long time, the two of us mostly thought about what was wrong with it. Neither of us is a finance person and Tally is built for finance professionals, so we were selling to accountants, about accounting, without being accountants. And the product was never ours. Roadmap, margins, commission structure, the decision to restructure the whole partner model on some Tuesday morning. Somebody else owns all of that and we find out when we wake up. At some point we stopped keeping that list, playing victim and tried to flip the question. We started asking instead a much simpler set of questions - What's actually within reach, that we understand well enough to be trusted with, and that if we do well, keeps paying for itself and advances the business forward? Thinking back, there were probably two seminal moments, neither of which seemed so groundbreaking at the time! ## 2019, and we had no idea that this would save the company We moved the whole company onto Zoho in 2019. Nothing groundbreaking. Just two kids who worked in the US and thought keeping data organized in one source of truth seemed like the right thing to do to lay the groundwork for anything else we wanted to. And I looked back at the first entries in there. Contacts migrated on 21 May 2019. The first support ticket an engineer logged went in on 1 October 2019. India locked down on 25 March 2020, thanks to COVID, a little under 6 months after that ticket. We've all heard enough about how that spring went for businesses like ours, not just in India but worldwide. In our circles, we heard about businesses scrambling to reconstruct over WhatsApp who owed what, who'd been visited when, who was even still contactable. We didn't have to do any of it, because we were lucky enough to have set it all up just a few short months ago. Our team simply seemed to seamlessly transition into the new 'work from home' subculture and we just carried on. They could support customers, log their tickets and generate invoices from a laptop in a bedroom in a small Bombay suburb. In hindsight, we don't know how we did it - No layoffs. No meaningful salary cuts. That was extremely unusual that year, and I'd rather not dress it up as foresight or principle, because it wasn't. Our people were still productive, the business was making money, so it made sense that the people making it happen, get paid. We got the humane outcome and garnered loyalty that you cannot manufacture, from both our employees and customers, because we'd accidentally bought the operational infrastructure 10 months earlier. The next one was less foresight and more a foreboding that AI will change the world. ## 2025, and the year we took control of our destiny more firmly than ever before I hate SEO agencies. Their pitch goes something like this - "You pay us X every month. We can't promise you any results. EVER. But we will work hard. We don't know if it will change anything or by how much. We can guess. But don't hold us to it. If anything doesn't work, it's not our fault. It is Google's." Now imagine if that was my pitch to my investors when I was raising funds for SmartCue? We were paying an agency about $12,000 a year for maintaining our website and to work on our SEO. And true to form, the spend wasn't producing anything I could point at. More importantly, and less frustratingly, it also looked, for the first time, like something I could take on with no domain knowledge at all, because AI had closed enough of that gap to make it plausible. The money we'd save was a nice side effect and nowhere near the reason. I fired the agency around March 2025 and rebuilt the site myself. Then, if I'm honest, we didn't replace them with much of anything for a while. Kshitij was deep in Shrtfrm, I was deep in my day job at OneDigital and in SmartCue, and we were also feeling our way around things. Being able to write a page and being able to leave a system running are different problems, and slowly i gained confidence that I could do it without spending inordinate amounts of time on it. Kshitij and I sat down one evening, him listing our competitors and nuances of the business, and me making notes on what I could do using AI now, versus what is a nice-to-have for the future. Fast forward to today - The site and the SEO run without me now. Competitor research, the weekly review, content audits, rewrites when a page goes stale. The site is on Cloudflare Pages and I spend $0 on it. Literally. All of the technical SEO stuff e.g. Google Core Web Vitals, Page Speed etc. are in the 95th percentile or higher. No agency. It happens whether or not I open my laptop. Against the agency's own best months: | | Agency, at $12,000/yr | Now, at $0 | Change | |---|---|---|---| | Pages ranking | 253 | **634** | **+151%** | | Monthly impressions | 229,982 | 225,315 | at par | | Annual spend | $12,000 | $0 | **$12,000/yr back in the business** | Clicks - 307 in March, then 474, 587, 742, and 1,278 in July. Rising month on month. 2.5x the surface area, the same reach, none of the money. So - website sorted. Better numbers than the agency ever put up, for $12,000 a year less. What we'd actually been paying them for all along was the fact that we couldn't do it ourselves, and that had stopped being true without anyone sending out a memo. That was the easy half though. A website is a thing you publish at the world. It doesn't need to know anything about your customers, or which engineer sat in their office last March. ## How it is all coming together You can't automate a business that doesn't keep records. And our team has been diligently typing in by hand, into Zoho, since October 2019. Which engineer went where, what broke, what was said, what got fixed. 6 years of it. We bought that CRM to be organised and it is turning out to be the backbone that no amount of frontier AI could solve. \[So - garbage in, garbage out still holds in the post-AI era!\] ![A long card-index drawer densely packed with plain filing cards, one card standing slightly proud with a small coral tab.](/notes/nobody-writes-the-playbook/mid.png) We started to take on meatier problems with more ROI. The business does two key things which are our bread and butter (or ARR, the more glamourous terms we all obsess over in SaaS) - License Renewals and Annual Maintenance contracts. With renewals - A customer's subscription comes up for renewal, an invoice goes out, they pay. That's the whole transaction. In practice it is phone calls, follow-ups, more phone calls, and sometimes somebody driving across Bombay to collect money from a customer who was always going to pay. Annual maintenance contracts, same shape. Easy to renew if you can show a customer what you actually did for them all year, and a slog to chase. So I automated the chasing sometime in June. Individual, personalized emails go out to the customer, from the rep who owns that customer, with perfect English and thoughtful touches. Our AI automation sent out **750 of them in 6.5 weeks**, and I've barely touched it. Our CRM now shows 406 contacts marked renewed. Maybe some had renewed through the normal sales channel, but a lot of it can be attributed to the automation. We're still trying to improve the attribution though. It's [a harder problem than it looks](/notes/did-they-get-better-or-were-they-always-good), even at our size. So take that success story with a grain of salt. We're doing the same thing for AMCs and i'll reflect on it once it's had a few weeks to marinate. Our whole goal here is to make it as easy as possible for Kshitij and I to automate a legacy business so we can spend more time on building our own IP and businesses. But without the legacy business taking a hit. To that end, we're trying to isolate jobs and tasks that used to eat somebody's week and compress it so that it now eats nobody's, and we're trying to get there without adding a person, removing one, or needing a budget. What our 15 people now do with that time is sell. One of them closed a deal worth about **$6,000** I don't think would have happened otherwise, because he finally had room to properly work the client. He used AI to write a proposal that read like it came from a much larger company, then to think through the negotiation, and closed it inside a month. In this business that timeline isn't normal. My own read of our license sales is that they're running **10 to 15% up month over month**, which means that the effort is not just keep the status quo, but the business is actually growing. With little to no manual effort or oversight from either of us. Looking back - Less effort, less oversight, less money, and more coming out the other end, faster. Same trade we made in 2019. Oh and - nobody had to lose a job for it to work! ## The agency's parting gift There's a coda to the agency story that still makes me angry. On their way out, they deleted our Google Business Profile. Roughly 5,000 reviews, collected over about 2 decades, gone. Spite or incompetence, I genuinely don't know. Google has no interest in the question and there's nobody to appeal to. Those reviews were the most valuable marketing asset a local business like ours had. 20 years of customers vouching for us, sitting in the exact place a buyer looks first. We're rebuilding it off the same Zoho record. When an engineer closes a job, that customer gets a note from that engineer about the actual work, asking for a review. Not a blast. And we ask everyone, including the customers we're not confident about. **341 asks in 6 weeks** have taken us from 5 reviews to 13. 13 against 5,000 sounds pathetic. But - nobody on our team has spent a minute earning them. Everyone's anxious about AI taking jobs and I don't think that's silly. But a fair amount of the loudest version of it comes from precisely the sort of operator who torches a client's twenty-year asset on the way out the door. Nobody is coming for the job of the engineer who did honest work for us for a decade. Whoever deleted that profile did more damage to their own future than any model has managed yet. I won't name them here, but if you're in Bombay and looking for who not to work with, send me a DM. ## What I think actually happened Every story you read about AI transforming a business is set somewhere else - too distant for small businesses like ours to think it affects us. A tech company, large conglomerates, shiny Silicon Valley-based new-age startups. Nobody writes the playbook for a 15-person mom-and-pop company (literally!) in Bombay selling someone else's accounting software to people who understand the product better than we do. There was never going to be a case study for us. We're not an interesting company. What we ended up doing was unremarkable and equally seminal. Do the dull things you're actually qualified to do, don't overcomplicate things and leave the rest alone. We did that in 2019 and it carried 15 people through a pandemic none of us saw coming. We did it again in 2025 and, by the measures that matter to us, the business is running better than it ever has. On infrastructure that three years ago would have needed a team we couldn't have afforded to hire. The next item on our to-do is wiring Tally itself into Zoho, so invoices, follow-ups and reconciliations stop being something a person has to waste time on. That's a simple, dull task though, not a grand plan. Our plan hasn't changed since 2019. What changed is how much of it we can reach. --- --- ## Did They Get Better, or Were They Always Good? URL: https://robinsinghvi.ai/notes/did-they-get-better-or-were-they-always-good Published: 2026-07-29 Tags: AI adoption, measurement, operator notes, OneDigital, AI workforce Description: We measure our AI program carefully, and the number we report is hours saved. Then I looked at what that number is made of, and at who is actually using these tools. A leader at my company asked me to write down how to do my job without me, for clients who will never have me. I wrote fifteen steps in an afternoon. Ten of them transfer cleanly to anyone willing to do the work, and most of what they describe is [how we hire, manage, and occasionally fire these things](/notes/hiring-and-firing-ai-coworkers), which I have written about already. The interesting part was the step I could not write. Step five. Before you build anything, decide how you will know the business actually got better. Not that the work got faster. That the company is better off. ## I have been reporting an input and calling it a return I want to be careful here, because the easy version of this admission is false modesty, and it would also be untrue. We do have a methodology. We built a measurement system for the program. It runs across every conversation our people have with our AI coworkers, it produces hours saved and dollars saved, and I would defend its arithmetic in a room full of people who wanted to poke at it. [I have written before about how hard it is to measure good AI use](/notes/no-playbook-for-measuring-ai-use), and that system is my team's best answer to it. Now look at what the number is actually made of. It takes an estimate of the minutes a given type of task normally consumes, and multiplies it by a burdened hourly rate. Sit with that for a second, because it took me longer than it should have. The same task, performed by a more expensive person, books more value. Change nobody's behavior at all, shift the same work to a higher-paid part of the firm, and our value number goes up. It is a faithful measure of what the time we saved would have cost us if we had spent it. It is not a measure of whether we won more business. Or served a client better. Or kept an account we were on track to lose. Or made a consultant's judgment sharper. Hours saved is an input. I have been reporting an input and calling it a return, and doing it sincerely, which is the part that bothers me. That would be a tolerable accounting problem if usage were free. It is not. Every consultant working with a coworker spends tokens, and that line item grows at exactly the rate of the adoption number I keep presenting upward as a success. There's a word doing the rounds for optimising the number you can see. Tokenmaxxing. Not mine, and I don't love it, but I've been close enough to it that I've stopped laughing. ## The two questions, and the one that keeps me up The first is attribution. Our people use these tools heavily. Are they winning more business because of it? The second is harder. The consultants using our coworkers most heavily. Were they already our strongest performers? Or are they people who were behind, and got better? Those two possibilities produce an identical adoption chart and opposite conclusions. If the heavy users were already the best, we've only bought an expensive amplifier for the people who needed one least, while the people who needed it most are absent from the data entirely. If instead the heavy users are people who were struggling and are now closer to the front, that is a different kind of company than the one we were two years ago. ## What the research says, and why it raises the stakes The best available evidence points hard at the second story. In a lab, though. [Researchers at Harvard ran 758 Boston Consulting Group consultants](https://www.hbs.edu/faculty/Pages/item.aspx?num=64700) through realistic consulting tasks, randomly assigning who got access to AI tools/agents. The consultants using it did more work, faster, at higher quality. But the finding that matters here is the distribution. Consultants who had scored below the average improved by around 43 percent. Those who had scored above it improved by around 17. The tool compressed the skill gap. It took what the strongest people already knew and handed it to everyone else. The same shape shows up elsewhere. [Another study focused on customer support](https://www.nber.org/papers/w31161) and found a 14 percent gain overall, concentrated among the least experienced agents. Two studies, different populations but same direction: AI lifts the bottom more than the top. But notice the word doing the work in both. Assigned. In each study, researchers decided who got the tool, which is exactly what makes the results trustworthy. Nobody assigned my colleagues anything. They opted in. ![A row of small identical wooden pegboards on a warm off-white wall, most holding a single neatly hung coral-handled tool, three of them completely bare.](/notes/did-they-get-better-or-were-they-always-good/mid.png) ## So I went and looked at ours, and I was wrong I had a tidy theory about what opting in selects for. Curiosity, confidence with new software, enough slack in your week to look clumsy for an afternoon. All of which, I assumed, correlate with already being good at your job. Our own data does not support that. The strongest predictor of whether someone here uses an AI coworker turns out to have almost nothing to do with the person. It is whether anyone has an AI coworker tailor-built for their job. Parts of the business with a dedicated one adopt at roughly double the rate of parts without. Every genuine dead zone in our numbers is an area where we simply never built anything. The second strongest predictor is their manager. If your manager is a sustained user, you are far more likely to be one, which is [the change-management argument I made a while ago](/notes/your-ai-deployment-is-failing) showing up in our own telemetry, and that holds inside every practice we tested, which rules out the comfortable explanation that our strong practices happen to have strong managers. Another finding in my data that vexed me - our newest hires adopt markedly less than our longest-serving people. When my gut told me that it would be easier to get new joinees to adapt to our way of working. None of that is about individual talent. It's about supply and social proof. Which means the most interesting group in our data is not who I thought. The people who have never logged in are not our laggards, our sceptics, or our dead weight. Overwhelmingly, they are people nobody built anything for. They are not un-curious. They are un-served. That is a far more uncomfortable finding, because it is our fault rather than theirs, and it is also far more fixable. These are important findings I can action on. However, it still does not answer my question. A small minority of our users accounts for most of our measured value, which sounds like a finding until you remember what measured value is made of: volume, task type, and hourly rate. It is not evidence that our heavy users improved, and it is not evidence that they were strong to begin with. The instrument cannot see the difference, and that is the whole problem. ## And heavy use is not automatically good either There is a second finding in that same Harvard study I've been thinking about. Outside the range of tasks the AI handled well, consultants using it performed about 19 percentage points worse than consultants working alone. And the boundary is jagged, so you can't tell from a task's apparent difficulty which side of it you're on. So a consultant using a coworker constantly might be compounding a real advantage, or might be producing worse work faster with more confidence. Volume cannot distinguish those two. Neither can a satisfaction score, which is the metric most programs lean on hardest because it is the easiest one to collect. This is why the most bureaucratic-looking thing we do turns out to matter most. When we write a job description for a coworker, we write down what it will not do. That looks like paperwork. It is us drawing that jagged boundary by hand, one job at a time, because nobody can hand us the map. I didn't plan on it, but that rigor has definitely helped ensure we're going down the right path. ## Why the studies will not rescue you You might reasonably start by looking up what others are doing. The most quoted statistic in enterprise AI is that ninety-five percent of pilots deliver no return. You have seen it. It usually arrives rendered as "95 percent of AI fails." Go and read [the actual report](https://www.artificialintelligence-news.com/wp-content/uploads/2025/08/ai_report_2025.pdf), because it is considerably more careful than its reputation. It reviews more than three hundred publicly disclosed AI initiatives, runs structured interviews with representatives from fifty-two organisations, and surveys a hundred and fifty-three senior leaders. And it is precise about what it counts. The five percent applies to custom and task-specific enterprise tools, where the funnel runs from half of organisations investigating, to a fifth piloting, to one in twenty reaching production. General-purpose tools like ChatGPT and Copilot run an entirely different course in the same report: over eighty percent explored or piloted them, and nearly forty percent report deployment. No one reports that second number. The report is equally explicit about what it means by failure. For task-specific tools it defines success as something users or executives remarked had caused "a marked and sustained productivity and/or P&L impact." That is a high bar, honestly stated, and it means a modest genuine return files as a flop. Then, in the research limitations, the authors write this sentence which makes me chuckle - They say their figures are "directionally accurate based on individual interviews rather than official company reporting," sample sizes vary by category, and, most importantly "success definitions may differ across organizations." Read that last clause again. The most cited number in enterprise AI, the one everyone reaches for to argue this is not working, carries a footnote from its own authors saying the organisations inside it do not agree on what success means. That is not a flaw in the research. It is the same wall I hit at step five, turning up in somebody else's data. And it is why the number got flattened on its way to your board deck: every qualifier that makes it true is a qualifier that makes it unquotable. ## Why I wanted people who could tell me no Researchers at Harvard and MIT are working with our data now, and I want to be precise about why, because "we are working with Harvard" is the sort of thing people say to sound impressive (I would be remiss if I said I wasn't proud of that association though!). The reason is less flattering. A selection problem cannot be settled by anyone with a stake in the answer, and nobody has a bigger stake than I do. I lead the team that built this program. I have spent two years arguing for it inside the company. If I design the study that grades it, I will find what I am hoping to find, and I will do it sincerely, which is exactly what makes it untrustworthy. No amount of personal integrity substitutes for not being the one holding the pen. The other reason is that this is a genuine open problem rather than a service engagement. Notice what both of those studies had that we do not: a denominator. Resolved tickets per hour. Scored deliverables on an assigned task. A benefits consultant's month does not come with one, and neither does a wealth advisor's or a lawyer's. That is not a failure of rigor. Rigor needs something to divide by, and knowledge work does not supply one. ## What the measurement is actually for I have been describing this as a measurement problem, and it is one. But I do not care about it because I want a better dashboard. Here is what I actually believe, and I am going to say it plainly, because softening it would be its own kind of dishonesty and because the people it applies to deserve to hear it straight. AI is going to take a lot of jobs. Not evenly and not randomly. It is going to take them from people who are mediocre at what they do, and from people who refuse to reinvent themselves. Anyone genuinely resistant to change is going to be displaced, and I do not think that is a controversial prediction so much as an unpopular one. I believed it before I ran a program like this. Running one has not softened it. I am aware of how that sounds coming from the person who runs the AI program at a firm of six thousand people. Which is exactly why the second half of the thought matters more than the first. If that is true, a company has a choice about what to do with it, and the choice is not really a technology choice. You can let it arrive on its own schedule, notice a year later which roles have quietly become redundant, and handle it the way companies have always handled that. That path requires no conviction and no effort, and I think a great deal of the market is going to take it. Or you can try the harder thing. Find the people whose work is being automated out from under them before it happens rather than after. Give them the tool, real training rather than a webinar, and a route into work that is worth more than what they were doing. Come out the other side genuinely more productive, with the same people still in the building. That is the version I want to be able to point at when this is over. Not that we are closing in on seventy percent of our full-time workforce using AI coworkers. That we armed everyone, that nobody had to go, and that we are measurably better off than we were. None of this is mine alone to worry about. My bosses, Vinay and Mike, have been making the same argument in public and in a book they have coming out: that the real win is keeping your people and turning them into 10x versions of themselves, rather than thinning the payroll in service of the technology. They have put their names to that position, which means they are at least as invested as I am in finding out whether it actually holds. And here is the uncomfortable part. Everyone in this industry says some version of that sentence. It is easy to say, it costs nothing from a stage, and I have watched people say it who have clearly never checked. The only thing separating a company that means it from a company that says it is whether anyone bothered to find out. That is what the measurement is for. If we cannot distinguish people who got better from people who were always good, then we also cannot tell whether arming someone changed their trajectory or whether we handed a capable person a faster horse. And if we cannot tell that, then "we reskilled our people instead of replacing them" is just a story we tell rather than a thing we know. It is not a problem of scale either. I ran into [the same wall in my family's fifteen-person business in Bombay](/notes/nobody-writes-the-playbook), where the CRM cheerfully reports a number it has no way of attributing. I would rather know. Including if the answer is that it did not work, which is the real reason I want the people doing the checking to be free to come back and tell me no. Because if the humane version of this turns out to be real, it is worth an enormous amount to prove, to us and to everyone we would then be able to show. And if it is not real, the people most affected deserve to find that out from someone who went looking, rather than from a layoff. You cannot begin any of that if the only thing you can see is who tokenmaxxed. --- ## We Fired an AI Coworker. Then We Hired It Back. URL: https://robinsinghvi.ai/notes/hiring-and-firing-ai-coworkers Published: 2026-07-22 Tags: AI workforce, AI coworkers, operator notes, OneDigital Description: We run AI the way HR runs people: job descriptions, internships, probation, promotions, and sometimes terminations. What hiring and firing AI coworkers taught us. In 2025, we fired a coworker named Piper. Piper was a sales coach. The job was to help our sales teams prep faster, pitch sharper, and get up to speed on our lines of business without waiting on a human expert's calendar. Piper spent months in the intern stage and never earned a promotion. We iterated, retrained, went back and forth more times than I can count, and gave the role more chances than we probably should have. Eventually we did what you do when a hire is not working out. We let Piper go. Piper was an AI. This year, we hired for the same role again. The new hire is called DeX. DeX came out with flying colors, cleared every stage gate we put in front of it, and is now one of the most popular coworkers among our sales teams and consultants. Same job, essentially. Opposite outcome. The easy explanation is that the technology got better between 2025 and 2026. It did, and it matters, and I will not pretend otherwise. But that is not the variable that flipped the outcome. What flipped it was management. Piper had a part-time sponsor. DeX has a dedicated team of supervisors who treat it like their newest hire. That sentence sounds absurd unless you know how we run AI where I work. So let me walk you through it. How we hire artificial intelligence, how we promote it, and why we sometimes fire it. ## Think of us as your hiring agency I run the AI program at OneDigital, an insurance and benefits consultancy of about six thousand people. For the past year and a half, my team has run what we call the AI Coworker program: AI agents built for specific teams, doing specific jobs, managed by the people they work for. We did not start with a framework. We started with the obvious pitch: we will use AI to help you do your job better. It did not land. What came back was fear, skepticism, and the quiet resistance you get when you ask people to step into a paradigm they do not recognize. Nobody wakes up hoping to be transformed by the technology team. So we stopped pitching AI and started asking about the work. What does your team actually do? Where does the time actually go? If you could hire one more person tomorrow, what would you hand them first? And somewhere in those conversations we noticed that the answers kept arriving in the shape of a job description. The need was never "we want AI." The need was "we need someone who can do this." So we changed the pitch to match the shape of the need. We stopped introducing ourselves as the AI team and told people: think of us as your hiring agency. When you have a job req, come to us first. We will try to fill that role with AI. We will help you hire an intern. I deliberately did not pitch myself or my team as AI experts. The expert pitch puts the business in the audience. The hiring agency pitch puts them in the driver's seat. It is their req, their hire, and ultimately their call whether the hire is working out. People got to the aha moment much faster that way, and I have come to believe that repositioning did more for adoption than any capability the technology shipped that year. ## An applicant tracking system for software Once the hiring frame clicked, we took it literally. We went to our People and Culture team and asked them to walk us through the real end-to-end employment process. How a role gets requested and justified. How a job description gets written. What onboarding looks like. How performance reviews actually run. What a performance improvement plan is for. How promotions happen, and how someone gets let go. Then we modeled the AI Coworker program as closely to that as we could. Not because the metaphor is cute. Because every single person in the company already knows how that system works. Nobody needs a training session on what an intern is. So here is what happens today when a team leader at OneDigital wants AI help. A request comes in, and we write a job description together with the business owner, the same way a hiring manager would. The problem this role exists to solve. Who feels that pain, and when. The two or three tasks it will do repeatedly. What is explicitly out of scope. And, before we build anything at all, the question our whole framework now hangs on: what would a human hire in this role be measured on? If we cannot answer that, we do not build. The coworker gets a resume. It gets hired as an intern and piloted with a small group of real users. If it clears its exit criteria, real usage, satisfaction above target, no critical incidents, evidence of actual value, it gets promoted to apprentice and rolled out to a wider group with a higher bar. If it keeps performing, it goes full-time: available to everyone it was hired for, embedded in real workflows, with a named operational owner and regular performance reviews. Underperform for long enough and it gets demoted back a stage for remediation, our version of a performance improvement plan. Fail that, and it gets retired. In the earliest version of our tracker, one of the first pipeline stages was literally labeled "Candidate Requested." We were running an applicant tracking system for software. I remember finding that funny at the time. I no longer find it funny. I think it is the reason any of this worked. ## The case against calling them coworkers I know how this sounds to half the industry. There is a genuine, ongoing debate about whether humanizing AI is wise, and the case against goes roughly like this: these systems are not people. Giving them names and job titles and performance reviews misleads users about what they are, invites misplaced trust, and gets weird fast. I take that critique seriously, because we did not adopt this framing casually, and I want to give it a straight answer. The answer is that the coworker framing is not branding. It is change management infrastructure. People do not know how to relate to an agentic workflow orchestration layer. They know exactly how to relate to a coworker. You onboard it. You train it. You give it feedback when it gets something wrong. You forgive an intern's mistakes in a way you would never forgive a production system's, and that forgiveness is precisely what an early AI deployment needs to survive its first rough month. You collaborate with a coworker. That is the verb we wanted, because collaboration is how this technology actually creates value: it augments and extends the person using it. [I wrote before](/notes/your-ai-deployment-is-failing) about the adoption version of this insight: an employee who suspects the tool is there to replace them uses it defensively, and an employee who sees it as the newest hire on the team trains it. The employment metaphor recruits every instinct people already have about working with other people, and points those instincts at the machine. And once the metaphor is load-bearing, you cannot use it halfway. If it is a hire, it needs a job description. If it has a job description, it has KPIs. If it has KPIs, it can miss them. If it can miss them, someone has to be accountable for noticing, and that someone has to be its manager, not my team. Managers, plural, by the way: every coworker we deploy has a named human manager on the business side who truly has to supervise it the way they would a human employee. And if management is real, then firing has to be possible. The moment we allowed ourselves to say "hire," everything else followed. The framing is only honest if the whole employment arc comes with it. That is the part I would defend hardest to the skeptics: we are not pretending the software is a person. We are borrowing the only management system everyone in the building already trusts, and applying it to a workforce that happens to run on servers. ## Ben, or what good management looks like Ben is the proof of what the arc looks like when it works. Ben is our employee benefits expert, and probably the most famous coworker we have. Consultants ask Ben the questions that used to wait on the busiest experts on their team. Ben has handled well over a hundred thousand client assignments. Harvard has published case studies on our program, including one titled *Building a Digital Workforce*, and Ben features in [the book two of our leaders have coming out later this summer](https://www.amazon.com/Workforce-Intelligence-People-First-Playbook-Transformation/dp/1394467230). Which is a strange set of sentences to type about a colleague that runs on a server. But none of that is why Ben worked. Ben worked because of Shelley. Shelley is one of our benefits experts, and from day one she took Ben on the way you would take on a direct report. She was a champion who believed in the mission, and she was methodical and deliberate about the work of supervision. She watched what Ben got wrong. She fed back corrections. We iterated. You could see Ben improving with every cycle, the way you watch a sharp new hire compound in their first year. Ben cleared the intern gate, then the apprentice gate, and went full-time. Here is the part people miss, and the part I now repeat in every internal conversation about this program: Ben went full-time and Shelley did not stop. She still runs workshops and training sessions. She still evangelizes Ben everywhere she goes. Being a coworker's supervisor is not a one and done activity. The full-time status is not a finish line. Just like a human employee, a coworker that stops being managed starts drifting, and a coworker nobody champions stops being used. Ben is famous because Ben is good, and Ben is good because Shelley never handed the job back. ![Two identical potted plants on a shelf, one thriving beside a small coral watering can, one wilting](/notes/hiring-and-firing-ai-coworkers/mid.png) ## Piper's autopsy Which brings me back to the firing. Piper's autopsy has two findings. The first is technological, and it is the one everyone expects. In early and mid 2025, the platform capabilities a sales-focused coworker needed simply were not there yet. We tried really hard. We kept iterating, kept going back, kept Piper in the intern stage while we searched for an angle that would make people happy with it. Some hires are ahead of what the organization, or in this case the technology, can support. That is a real cause of death and I will not minimize it. The second finding is the one I find more instructive. Piper never had a Shelley. Sponsorship of Piper was a side gig: attention arrived in bursts and then vanished, feedback came from time to time instead of on a cadence. I want to be careful here, because this was a structural failure more than a personal one. Nobody's primary job was making Piper succeed, and so nobody was there for Piper the way Shelley was there for Ben. An AI coworker with an absent manager fails exactly the way a junior human hire with an absent manager does. Slowly, and then obviously. So we retired Piper. And when we revived the role this year, one of my team members built DeX with that second finding in mind. The technology had improved, no doubt about that. But DeX launched with a dedicated group of supervisors who were absolutely bought into making it a success. They wrote a strategic rollout plan. They tested before they scaled. They ran dedicated feedback sessions with the sales teams. They built DeX around the way the sales team actually works, instead of asking the sales team to reorganize around DeX. Same role. Two attempts. One variable flipped. If I could show you only one thing from the last year and a half, it would be this natural experiment, because it settles the question people keep asking backwards. The question is never "is the AI good enough." The question is "who owns making it good." ## The termination that meant it was working Not every firing is a failure story, though. My favorite one is the opposite. We had two coworkers named Leigh and Samara, hired for specific, narrow tasks in the same practice area Ben serves. They did their jobs fine. But Ben kept compounding, iteration after iteration, until Ben could simply do what Leigh and Samara did. So we retired both of them and rolled their responsibilities into Ben. On an org chart, that looks like the program shrinking. In practice it was the program maturing. Our people should not need to memorize a directory of which of a dozen coworkers handles which task. That way lies sensory overload and analysis paralysis, and both kill adoption quietly, one small hesitation at a time. Now, for most things related to employee benefits, people just go to Ben. A team that consolidates two roles into a stronger third is not a team in decline. It is a team whose best performer earned a bigger job. The graduation framework has teeth in every direction: it promotes, it demotes, it fires for underperformance, and sometimes it retires a role because a colleague got too good. ## The scoreboard, and the missing playbook Does it work? The honest scoreboard, kept deliberately high level: roughly two thirds of our six thousand people actively work with AI coworkers today, a year and a half in, and the number has climbed every month since launch. For an enterprise technology rollout, that is the kind of adoption curve I had previously only read about in vendor decks. External people have taken notice in ways I still find surreal: the Harvard case studies, the book, academics studying the program's data. I list those not as trophies but as evidence that this is not a demo. This is an operating company running a meaningful share of its daily work through hired, managed, and occasionally fired AI. And still: the playbook does not exist. We are creating it as we go. The framework you just read about is itself on version two, because version one measured the wrong things. Our first scoring model was heavy on feasibility: how hard is this to build, how fast can it launch, how big is the potential user base. Reasonable questions, and almost completely beside the point. Feasibility tells you what is easy. It does not tell you what is worth doing. Version two starts from the question we now refuse to skip: what would a human hire in this role be measured on? Baselines and targets get written before the build begins, not reverse-engineered after. I have [written before](/notes/no-playbook-for-measuring-ai-use) about how little playbook exists for measuring good AI use at work, and this framework is my team's running attempt at one. I fully expect a version three. I have put [a blank, working copy of our scoring instrument](/scorecard) online if you want to run one of your own deployments through it. The other lesson cost us more pain to learn, even though half of us knew it from previous careers. Those of us in tech think AI is the next best thing since fire. Maybe it is. It still does not deploy itself. You still need to do what you did when you deployed your CRMs and your ERPs: get people to believe in it, get them to buy in, and get a few of them to champion it among their peers. Every result in this post that looks like a technology outcome is, underneath, an enablement outcome. Shelley evangelizing Ben in workshops after graduation moved our numbers more than any model upgrade we shipped. Enablement is not the boring part of an AI program. On the evidence, it is the program. ## Workday for AI agents Where does this go next? Today, the framework lives in documents, templates, and a handful of heads, mine included. Managers fill out the evaluation by hand. That worked at ten coworkers. It will not survive a hundred, and it undersells how much of this system wants to be software. So we are building it into software: an internal product we call HALO, which I think of as a Workday for AI agents. Hiring intake becomes a structured conversation instead of a form. Performance reviews generate from live usage data instead of a quarterly scramble. One screen answers the question every executive eventually asks: how is our AI coworker program actually doing? It is deployed internally and not yet fully rolled out, which is a candid way of saying it is early and I am not declaring victory on it. But the direction feels obvious to me now, and even as I write this we are reinventing the framework to become exactly that. If companies are going to employ AI at any real scale, and I think most of them are, then the HR stack for a blended workforce has to exist. Somebody is going to build the system of record for AI employees: the hiring pipeline, the performance reviews, the promotion gates, the terminations. We are prototyping ours from the inside, one fired sales coach at a time. ## The bottleneck When people ask how we got adoption this fast, they are usually expecting an answer about models or platforms. Here is the answer I actually believe. The models were never the bottleneck. Every AI deployment I have watched succeed had a Shelley: a named human whose job included making the thing work, long after launch day. Every deployment I have watched struggle had a Piper situation: real potential, part-time ownership, no one whose job it was to care. We did not deploy technology at OneDigital. We hired it. We wrote its job descriptions with the people it would work for, onboarded it, supervised it, promoted it when it earned promotion, and fired it when it did not. Implementing AI in a real company is not trivial. It is also very, very doable. But the discipline that makes it doable is not a technical discipline. It is management, applied without irony to a new kind of employee. If you are trying to stand up something like this where you work, my honest advice fits in three lines. Before anyone writes a prompt, write the job description. Decide what a human hire in that role would be measured on. And find your Shelley, because the hire is the easy part. It is the management that compounds. --- ## Vanilla Ice Cream, Balsamic, and a Glass of White URL: https://robinsinghvi.ai/notes/vanilla-ice-cream-balsamic-and-a-glass-of-white Published: 2026-07-20 Tags: wine, personal essays, travel, notebook Description: I kept notes on wine for thirteen years to map my taste. What they actually recorded was people. On why I never open a good bottle alone. A few months ago I carried two things home to Bombay from a trip to Italy. A couple of bottles of white wine, and a bottle of proper aged balsamic from Modena, the traditional kind that moves like syrup and tastes almost like chocolate. One evening at home I put a bowl of good vanilla ice cream in front of me, poured some of that balsamic over the top, and had a bite with a sip of the white on the side. Sweet, then sharp, then cold, then a faint bitter-almond thing on the very end. I do not know why it worked. On paper it should not work. But I have thought about that spoonful more than I have thought about most bottles I have paid real money for, and I would like to do it again before I die, ideally more than once. The white was a Vernaccia di San Gimignano. We had bought it at a farm called Poggio Alloro, a family place outside San Gimignano that has been run by the same family for four generations. Swati and I first went there more than a decade ago, and this year we drove back to see if it was as good as I remembered. It was. I liked the wine enough to carry a couple of bottles across two flights, which is not a thing I usually do. I only started trying to work out why any of this mattered because I sat down to write it down. And to do that, I ended up reading back thirteen years of notes I have kept on wine. A hundred and eleven bottles, rated and dated, with little comments I typed to myself and forgot five minutes later. I even had an AI help me sort through them, on the theory that it would hand me back a neat profile of my palate. It did. But what I could not stop looking at was not my palate. It was how many people were in there. ## I hated my first drink I did not have a drink until I was twenty-four. I was a teetotaler straight through engineering in Bombay. The way I finally got a drink into me is a small story, except that it keeps happening, so maybe it is the whole story. I was about to move to Oregon for business school. Before I landed, I did the anxious thing and started messaging my future classmates on Facebook. One of them, Sumit, lived in Delhi, and found out I would be passing through the city for one night on my way out. He offered to pick me and my friend Nikhil up from the airport. It was past midnight. I had never met him. Who does that? He showed up in a purple Maruti Zen, drove us to a TGI Fridays that looked shut, and cracked open a six-pack. I told him I did not drink. He said come on, just try it. So I tried it, and I hated it. I remember thinking, genuinely, that I could not understand why anyone did this on purpose. That was my first taste of alcohol. Sumit has been my best friend for going on fifteen years. A few weeks later Nikhil and I were on a trip through Ladakh, the two of us in shorts in the mountains because we were idiots from Bombay who had never been anywhere cold. On one leg we got put in a shared jeep with a couple and one other girl. I had bad altitude sickness and was in no mood to talk, and the girl asked Nikhil what exactly was wrong with his friend. He explained. She handed me a rum and Coke to help with the cold. I did not know it had rum in it. I said something about the Coke tasting really sweet. She said that is because there is rum in it. That was the first hard liquor I ever drank. The girl was Swati. I married her. So that is three drinks, and none of them are really about a drink. A stranger who became my best friend. A first beer I did not want. A rum and Coke from the woman I would spend my life with. The alcohol was almost incidental. What I actually remember, in each one, is who handed me the glass. ## Where it actually started The wine came later, and it came the way most good things came to me, which is to say by accident and by being somewhere. Oregon turned out to be a place where everyone was quietly serious about something you drank. Coffee, or craft beer, or wine. A senior named Josh picked me up from the Portland airport when I first landed, took me to a dark neighborhood bar in Salem, and started me on stouts and porters, which in a cold Oregon October taste more like chocolate than beer. That was the first alcohol I actually liked. But wine did not really land until the year I spent in Bordeaux on an exchange. They served wine at lunch in the school cafeteria, which as an idea still delights me. There were tastings. I went out to Saint-Emilion and drank things I did not know enough to know I should be grateful for. I was buying bottles at the local supermarket for five or six euros that turned out, when I got back to the States, to be hundred-dollar wines. That was the year it clicked. Bordeaux is where I fell in love with wine. Which is why it is a little funny that almost none of those Bordeaux wines are in my thirteen-year record. I did not know the app existed yet. The wines that actually converted me, the whole year of them, are the one stretch I never wrote down. The best year has no record. I only started logging once I got back to Oregon, so the diary opens in the middle of the story, in Willamette Valley Pinot country, and quietly pretends that is the beginning. ## What thirteen years of notes actually say I had expected the notes to be a record of my palate. They are a record of my life. They are full of other things. "With Swati." A bottle logged on Valentine's Day. A crisp white I loved, with a line underneath it admitting that I was drinking it by the bay in Cassis and the bay probably did half the work. Restaurants I have not thought about in years. A wine tasting a bunch of my friends threw for one of my birthdays, a rented bus and a designated driver and a loop through Oregon vineyards. The ratings tell on me too. My highest scores almost never went to the most expensive or the most correct wine. They went to whatever surprised me. "First cognac I have ever liked." "My first Sonoma Pinot, and I regret not trying one sooner." "Amazing rose, and surprisingly it is a Cabernet Franc." The wine that beat what I had walked in expecting, that is the one that got the 10. And I am, for the record, not a connoisseur. I have never pretended to be. My notes include the phrase "wayyy too sweet" with three y's and a sad face. I once described a Prosecco as perfect for when you have the taste for champagne and the budget for sparkling water. I pair wine with whatever I am actually eating, which is usually Indian food. Not to make a point about what is supposed to go with what. I just want to know whether this bottle works with this dinner, so I try it, and I write down what happened. There is no formula. Most of the time it does not quite work. I write that down too. The strangest thing the notes showed me is that I have gotten happier about wine over the years, not more critical. I would have guessed the opposite. I would have guessed that learning more would make me harder to please. It did the reverse. The more places I drank in, Bordeaux and Oregon and California and Italy and France and Georgia, the more there was to like. I never once caught myself turning into a snob about it. It just kept getting better. ## Wine is a thing I have with people ![A warm off-white table set for a few, two or three wine glasses gathered close around a shared board, empty chairs implied at the edges, one coral accent](/notes/vanilla-ice-cream-balsamic-and-a-glass-of-white/mid.png) Reading it all back, the obvious thing about me, the thing I somehow needed a spreadsheet to notice, is that wine is not something I do alone. It is something I have with people. Left to myself I will have a glass and stop. I am a lightweight, so a whole bottle on my own would mostly go to waste, but that is the boring half of it. The real half is that opening a bottle alone would miss the entire point. A bottle is a table with people around it. It is the pour, and the second pour, and someone reaching over to top you up. That is the part I actually like. The wine is almost the excuse. I own a few bottles. Not many, because a small wine fridge is all the room I have. And what I have noticed is that I keep them for when there is someone to open them with. I am not saving them for a special enough occasion or a good enough year. I am saving them for company. ## What I am actually saving them for I would love a real cellar someday. Room for a few hundred bottles, so I could finally buy more than one of the wines I love instead of drinking the only bottle and mourning it. For most of my life I could not picture a cellar because I could not picture affording to fill one. That part is not quite true anymore. For the first time, I think I could. And now the thing in the way is not money, it is a Bombay apartment, where there is nowhere to put a few hundred bottles even if I bought them. The wall moved. It used to be money. Now it is space. We will see if it ever comes down. In the meantime I have thirteen years of notes that turned out to be about people, a few bottles in a small fridge waiting for the right table, and one bowl of ice cream and balsamic and cold white wine I put together at home in Bombay from things I carried out of Italy, which I still cannot stop thinking about. The wine, it turns out, was never really the point. The point was who I got to have it with. That is the one tasting note I would stand behind for all hundred and eleven of them. What is even the point of experiencing something good if you cannot share it with people? I still want to do the ice cream thing again. But not by myself. Never that one by myself. --- ## How to Reach for Things You Haven't Earned on Paper (Without Being a Fraud) URL: https://robinsinghvi.ai/notes/reach-for-what-you-havent-earned Published: 2026-07-14 Tags: career, operator notes, AI and work, OneDigital, ambition Description: I keep taking jobs I'm not qualified for on paper. It looks like nerve. It is actually a rule: cap the downside, and tell them exactly what you are not. The honesty is what makes the reach safe. A little over a year ago I was offered a job I had no business being offered. The role was to run the AI program at OneDigital, a roughly 6,000-person company. On paper there was no reason to hand it to me. I am not an AI researcher. I have no background in enterprise change management. I had spent the previous decade as a product person and a founder, not as the head of anything at a company that size. I knew all of that. So here is what I said to the person who would become my boss. I told him, I'll do it, but you should know I'm not an expert. You are going to have to figure some of this out with me. He gave me the job anyway. For most of my life I thought stories like that were about nerve. The bold guy walks in, asks for the thing he hasn't earned, and gets it because he had the guts to ask. That is the version that does well on LinkedIn. It is also wrong, at least about me. I am not especially brave. What I actually have is a rule, and I have run it for fifteen years without ever writing it down. This is me writing it down. ## The pattern I didn't notice I had Once I started looking, the same move was everywhere in my history. Years ago, interviewing at a company called Edifecs, I asked for more than double what I was making at the time. Not because I had calculated my market value and arrived at a number. Because I already had a job I liked, and I thought, what is the worst that happens here. They say no, and I keep the job I already have. So let me really overreach. They said yes. They even added an extra month of salary and time off on top. I would never have asked for any of it if a no could have hurt me. A different time, I had just been let go from a company called Array Health. I was in the US on an H-1B visa, which means when you lose your job you have a small number of days to find a new one or leave the country. There was a conference I was already registered for. I probably should not have been spending the money. But the founder of a company I admired was speaking, I had done my homework on what they did, and I was pretty sure I would be a good fit there. So I went, and I more or less ambushed him in the hallway after his session and told him exactly that. The clock was ticking. There was no time to feel small about the layoff. That conversation did not turn into a job right then. It turned into a relationship that mattered for years. And then the OneDigital role, where my entire pitch was a disclaimer. Three different rooms, spread across fifteen years, same move every time. I kept reaching for things I had not earned on paper. I want to be precise about why that is not the brag it sounds like, because the mechanism underneath it is the whole point. ## It is not fearlessness. It is two rules. When I actually look at what those moments share, it is not courage. It is two conditions that both have to be true before I will reach. The first is that the downside has to be capped. I do not bet when losing the bet would end me. The Edifecs ask was basically free because I already had a job. The hallway ambush cost me nothing but a little dignity, and I was getting on a plane either way. I have never once made a brave-looking move where a no could actually sink me. When people call this boldness, they are watching the reach and missing the floor I quietly built under it first. The second is that I tell them, up front, exactly what I am not. I'll do it, but I'm not an expert. Here is what I have actually shipped, and here is where I would be learning on the job. I lead with the gap. That second rule is the one that took me years to understand, so let me stay on it for a minute. ## Why the honesty is the whole engine Here is something I am genuinely anxious about, always. Whenever I am around people who are obviously smarter than me, and I work with a lot of them, there is a low hum of fear that I will be caught with my pants down. That the work I have done will not hold up when they actually look at it closely. That someone will finally check and find out I was reaching past my grade. For a long time I assumed the way to handle that fear was to seem more qualified than I was. Project confidence. Don't show the seams. That is more or less the standard advice. Fake it till you make it. The opposite works, and it works for a reason that is almost mechanical. If I open by telling you what I am not, there is nothing left to catch me on. You cannot expose me for overselling if I never sold. The disclaimer is not humility for its own sake. It is the thing that makes the reach safe. Once the gap is on the table, the only thing left for me to do is close it by out-working it, and that part I can actually control. I run the same move in the work itself, not just in the asking. When I built the dashboard that measures what our AI program is worth, I found that an earlier version of the number had been propped up by research that did not hold once you read it carefully. So I revised our own headline figure down. On purpose. The instinct in a big company is to make your program look as large as possible. I made ours look smaller, because a number that survives scrutiny is worth more than a number that impresses once and falls apart the next time someone pokes it. Same rule as the job pitch. Show the gap, and there is no gap left to be caught in. There is a quieter thing under all of this too, which is that I genuinely like being the least-qualified person in the room. I seek it out. If I can spend my time around people who are sharper than me, the math is great. Worst case, I come across as a bit dumb. Best case, I learn things I could not have learned anywhere else. It is always a win. So the reaching has never really been about status. It is about getting into the room where I will get smarter, and the honest disclaimer is just the price of admission that also happens to protect me. And when someone sharp does bet on me anyway, the way I pay that back is not by pretending the bet was obviously correct. It is by making sure they never regret it. The over-preparing, the leading with the gap, the revising my own number down. All of it is in service of the same thing, which is that the person who took a chance on me should never have a reason to feel like a fool for doing it. ![A tall stack of smooth cream blocks rising from a wide, solid base, one block accented in coral](/notes/reach-for-what-you-havent-earned/mid.png) ## The floor I don't usually talk about There is a deeper version of the capped-downside rule, and I have only recently been able to say it out loud. For the past year or so I have assumed, fairly cheerfully, that I am going to be replaceable sooner rather than later. Not as a fear. As a planning assumption. So on the side, away from the day job, I have been building things, and some of them have nothing to do with my last sixteen years of expertise. I have written before about [the AI agents that now run those side projects while I sleep](/notes/four-ai-agents-running-my-companies). The reason I can build them at all is that the best AI in the world is available to me at the same price it is available to anyone richer or more credentialed. There is no superior model that the important people get to use and I do not. For the first time in my working life there is a real leveler, and I have my hands on it. What I do with it is up to me. That is the actual floor under everything else. I can reach at the day job, I can lead with my gaps, I can take the role I am not qualified for, because I have quietly proven to myself that I would be fine without it. When the worst case is "I go build something of my own with tools that do not put me at a disadvantage," the worst case stops being frightening. The capped downside at the scale of a salary negotiation turns out to be the same shape as the capped downside at the scale of an entire career. Build the floor first, and the reaching mostly takes care of itself. ## So here is the actual advice If you want to reach for things you have not earned on paper, the move is not to act more qualified. It is closer to the reverse. Build a floor so the reach cannot kill you. Have the other job, the savings, the side thing, the skill that travels. You will be surprised how bold you become the moment a no stops being fatal. Then lead with the gap. Tell them what you are not before they can find it out themselves. Not as false modesty, and not as a negotiating trick, but because it is true, and because it makes you impossible to expose. The honest version of you is the one that cannot be caught. Then close the gap by out-working it, which is the only part that was ever really in your hands. This is not fake it till you make it. It is closer to disclose it, then earn it. I am not going to dress it up as a universal law, because I have only ever tested it on one person. But it is the truest thing I know about getting into rooms you have not earned your way into, and every time I have actually followed it, it has worked. The method I am sure about. The part that still gets me is who it worked for: a mediocre student who kept telling people exactly what he wasn't, and kept getting handed the keys anyway. --- ## What I've Learned Running an AI Program at a 6,000-Person Company URL: https://robinsinghvi.ai/notes/your-ai-deployment-is-failing Published: 2026-07-01T09:00:00+05:30 Tags: enterprise AI, AI adoption, operator notes, change management, AI workforce Description: The two loudest stories about enterprise AI, that it deploys itself or that it replaces everyone, are both wrong. The real work is the boring middle. Notes from inside a 6,000-person AI program. A few weekends ago I was reviewing a late draft of a chapter in the book Vinay is writing. Vinay is my boss at OneDigital, where I run the AI program. He'd been writing about the ninety minutes of hands-on training every new employee gets before they're allowed anywhere near an AI Coworker, and he asked me for the line that explains what actually has to happen in that room for the training to work. I gave him this: > AI adoption happens when you help people do today's work better and with more confidence, rather than when you ask them to believe in the future. I gave him that line because it's the most honest summary I have of what we've actually learned in eighteen months running this program. It's also not the sentence I would have predicted in 2024, when I was reading the same vendor decks and analyst reports everyone in this work reads. Their thesis was that AI deploys itself. Buy the licenses. Get out of the way. Watch the productivity gains show up on their own. That is not what happened. AI does not deploy itself. It also does not take everything. The work happens in the boring middle, and almost nobody writing about enterprise AI right now has actually stood in it. This is what eighteen months in the boring middle looks like. ## Why both stories about AI are wrong The two stories you hear most about AI in the enterprise are mirror images of each other, and both of them are wrong. The first story comes from the vendor and analyst class. It says: AI is a horizontal productivity boost. Pick a model. Deploy it. Save 30% on cognitive labor. This is the story sold in keynotes. Ethan Mollick, in his Substack writing and in *Co-Intelligence*, has spent the last few years documenting what he calls the jaggedness of AI capability: it is superhuman on some tasks and useless on others, and the variance across people inside a workforce is wider than the variance across the model versions on offer. Whether your enterprise lands in the high-leverage or no-leverage cluster is not a function of which model you bought. The second story comes from the doom and labor-displacement commentary. It says: AI takes everything. The agents replace the workers, the workers replace themselves, the firm reduces headcount until there is no firm. I have not seen that play out in any practice I work with at OneDigital. Not one knowledge-work function has been fully replaced. Plenty of routine sub-tasks inside knowledge work have moved to AI. The function around them has not. The two stories share a quiet assumption: that the AI is the variable. Either the right AI saves the business, or the wrong AI sinks it. The truth is closer to what Andrej Karpathy was getting at with Software 3.0: when the AI is the foundation, the programming layer becomes the prompt and the workflow. The bottleneck moves from "do we have the right software" to "can we manage the new kind of teammate this software became." That bottleneck is a people-and-process problem. It is the same bottleneck that determined whether enterprise CRM rollouts in 2014 succeeded or failed. It is the same bottleneck that determined whether ERP rollouts in the 1990s succeeded or failed. The bet of our AI program at OneDigital is that we have to treat it that way. As an HR transformation, not a technology rollout. ## The methodology, in plain language I run an AI Coworker program. We call them Coworkers on purpose, not agents, not bots, not assistants. "Agent" describes what the software does. "Coworker" describes what the person sitting across from it is supposed to feel: this has a job, it can be trained, it can be wrong, and it isn't here to take my seat. That's not a branding choice. An employee who believes the thing in front of them exists to replace them uses it defensively, or not at all. An employee who believes it's the newest hire on the team actually trains it, corrects it, delegates to it, the way they would a junior colleague. None of what follows, the job description, the knowledge base, the named human supervisor, the probation cycle, works without that first move landing. Coworkers are conversational systems anyone in the company can talk to through our internal tools, practice-specific or cross-practice, and every one goes through the same three-phase lifecycle: Internship, Apprenticeship, Full-time. Internship is where a small group of users stress-tests a brand-new Coworker against real work, surfaces the failure modes, and feeds the corrections back to a human supervisor. I tell every cohort the same thing on day one: the thing in front of you is going to make mistakes; your job is to find them, not to be impressed by it. If people show up expecting a finished product, the program fails, because the bar is set wrong. If they show up expecting an intern, the bar gets met, and the Coworker gets better because of it. Here's what that actually looks like, not the version that fits on a slide. The Coworker most people at OneDigital would recognize handles benefits questions; everyone just calls it Ben. The supervisor who owns Ben and I ran the same loop, daily, for eight months. She'd surface a case where Ben got something wrong. I'd trace it to a gap in the knowledge base or an instruction that needed rewriting. We'd fix it. The next day's testing would expose the next weakness. Eight months. Not eight weeks, not a two-week beta. That is what Internship-grade iteration actually costs when you're doing it instead of demoing it. Apprenticeship is the validation phase. The Coworker is opened to a wider but still curated audience for two or three weeks. The supervisor tightens the prompts, expands the knowledge base, retrains the system on the edges that came up in Internship. Full-time is when the Coworker goes available to the whole company. Conversations are retained for context. Users share threads with each other the way they'd forward a good email. The structurally important detail, the one that does most of the actual lifting, is the supervisor. Every Coworker has a human supervisor, and that supervisor sits in the business unit, not in the tech organization. The supervisor is whoever is already best at the relevant job. That choice is expensive. Pulling a top performer off active work to encode their craft into an AI is an opportunity cost the program owns directly, on purpose. It is also the only way the Coworker becomes worth using. The Coworker is, at the end of Internship, a high-fidelity transmission of the supervisor's expertise. Mediocre supervisor, mediocre Coworker. The model is interchangeable. The supervisor is not. ![Three folders fanned left to right, growing thicker, with a coral tab on the last, suggesting a progression from intern to full-time](/notes/your-ai-deployment-is-failing/mid.png) There's a second layer under this that took me longer to see, because it isn't visible from inside any single Coworker's rollout. Every new employee gets that same ninety minutes of hands-on training before they're let near a Coworker at all. For a long time I assumed that if adoption still lagged after that, the problem was motivation: people who'd sat through the training but weren't convinced, or hadn't built the habit yet. When we finally pulled the numbers across every practice this year instead of going by feel, the actual gap was earlier and duller than that. The pattern was always the same: people show up, find nothing built for their actual job, and leave. Not because they don't want to use AI. Because there's nothing there for them yet. Everyone gets the same training. Not everyone gets something built for their actual work. Coverage, not motivation, is the real gap. ## What gets paved over in keynote decks A meaningful share of Coworkers don't survive Internship. They get cut. They didn't perform. We may revisit them in six months when the underlying models improve. Right now they're on the cutting room floor. The internal joke in the AI Programs team is that I have fired enough Coworkers by now that when AI becomes sentient I will be first in its firing line. The joke is sticky because it is operationally true. A non-trivial share of Coworkers that survived Internship are currently on Performance Improvement Plans. The Supervisor and I review their KPIs together; we agree on what better looks like; we set a timeline; we either retire the Coworker or we graduate it. None of this is hypothetical. None of it shows up in the brochure. The cheapest adoption lever we've found has nothing to do with the AI, and nothing to do with the Coworker's supervisor either. It's the person's own manager. When a team's manager actually uses the thing, and brings the team together for twenty minutes every couple of weeks to work a real, hard case live instead of forwarding a link, that team's usage can climb from around a third to about three-quarters inside a quarter. When the manager stays out of it, the team stalls, no matter how good the Coworker is. And I didn't just eyeball that across the company as a whole, where strong teams and strong managers travel together and you can't tell which one is doing the work. I checked it inside each practice separately. The manager gap holds within every one of them. The Coworker didn't change. The manager did. I am about a year into knowing this, and I still have to remind myself of it weekly. The instinct is to chase a new model release. The discipline is to get one more manager to run one more session. ## The next problem I do not have an answer to For all the methodology, there's one problem here I got wrong for a while, and a second one I still haven't solved. The one I got wrong: I used to think the goal was moving people from transactional use of a Coworker (quick question, quick answer) to collaborative use (a real back-and-forth that produces something neither of us would have produced alone). I built training and messaging around that distinction for months before I trusted the data enough to admit the distinction itself was the mistake, not the direction people were failing to move in. [I've written the longer version of how that fell apart and what replaced it elsewhere](/notes/no-playbook-for-measuring-ai-use). The short version for here is that the real question was never how long the conversation ran. It was whether the person's time actually came back to them. The one I still haven't solved: most people, even once they know a Coworker can handle the harder, more collaborative ask, don't reach for it. The ninety minutes gets them in the door. The tool can do more than they're asking it to do. The habit of asking for more doesn't form on its own, and I don't yet have a lever for it the way I have a lever for coverage or for supervisor cadence. I'd rather say that plainly than pretend the metric fix solved it. ## Why I trust this is real The honest test, when you're inside a program and can't tell whether you're looking at a real pattern or a flattering one, isn't whether outside experts noticed. It's whether the thing survives someone actively trying to break it. That's the test I apply to my own numbers first. Every dollar-value claim the program makes runs through a model I built and rebuilt, and when I tightened the methodology this year, the program's own headline value came out meaningfully lower, because the earlier estimate leaned on research that didn't hold up once someone actually read it. I published the correction anyway, with a section that does nothing but list what we got wrong. Same discipline as the Coworker lifecycle, aimed at my own numbers instead of the AI. A claim that can't survive a hostile reviewer isn't a number. It's a slide. The second test is closer to home. Vinay wrote the book about this program's methodology, and more than once, when I've pushed back on how he wanted to frame our own adoption metric, he's told me the critique was fair and asked me to go build a better one instead of defending his. In a lot of companies, the person who wrote the book about the program is the last one who wants to hear the methodology has a hole in it. Vinay isn't. The outside validation is real too, and it matters, just not as much as the two tests above. Harvard published a case study on what we did this spring; I wrote about that [when it landed](/notes/four-ai-agents-running-my-companies). [Vinay's book about the methodology](https://www.amazon.com/Workforce-Intelligence-People-First-Playbook-Transformation/dp/1394467230) comes out this summer, with the same set of mechanics described here at much greater depth. A joint Harvard, MIT, and UCLA research paper studying the same topic is in motion for later this year. None of that is why I trust the work. It's confirmation that the work was worth studying in the first place. What I actually trust is that the number survived me trying to break it, and that my boss would rather I broke his framing than protect it. ## What this means if you are buying AI If you're at an enterprise buying AI right now, my honest read is that picking the right model isn't what determines whether you succeed. The frontier models are converging fast enough that whichever one you standardize on this quarter, GPT, Claude, Gemini, whatever's ahead by the time you read this, matters less than whether you run a real change-management program around it. Write the job description for the Coworker you actually want to hire. Find the top performer in the relevant role inside your company and ask them to become its supervisor. Build the Internship as a real quality-assurance cycle, not as a beta test. Run the biweekly facilitations. Cut the Coworkers that aren't earning their seats. Resist the temptation to skip the supervisor cadence because users want access faster. None of this is futuristic. None of it is hard to explain. It is, on the inside, deeply unsexy. It is also the reason a 6,000-person traditional consulting firm has reached 64% workforce-wide adoption eighteen months in, while most enterprise AI programs stall out with only a small fraction of the workforce ever really using the thing. None of this is permanent. The models will keep improving. The supervisor model will shift as the tools get better at the parts supervisors currently do by hand. The word "Coworker" itself might not be the noun we're using for this in five years. But the discipline underneath it doesn't need the model to be right, and it doesn't need the noun to survive. It needs someone in the business unit willing to own a mediocre first draft, a training program people actually sit through, and a habit of showing up to the cadence instead of chasing the next release. That part isn't going anywhere, because it was never really about AI. It's the same thing that decided which CRM rollouts worked in 2014. We just keep forgetting it every time the technology changes costume. --- ## I Never Aimed at Meaningful Work. I Aimed at Fun and New. URL: https://robinsinghvi.ai/notes/i-never-aimed-at-meaningful-work Published: 2026-06-29T09:00:00+05:30 Tags: operator notes, career, meaning, retrospective, bet-debt Description: Meaning is retrospective. The operators who actually ship meaningful work didn't start by finding their why. They aimed at fun, new, smart people, and not letting down the people who bet on them. Here's the pattern up close. A few weeks ago I sat down with a chatbot for an interview that was supposed to surface my thesis, and I told it the most honest thing I had said out loud in a year. The chatbot had asked me whether I'd ever felt like I was running *toward* something. Money. Status. Some specific destination. I tried to answer the question and realized I could not. The closest I got was this: *"I don't know if I ever ran towards great meaning or wanting to change the world. I have always been running away from one thing or the other."* A few weeks after that initial conversation, in a different session with the same chatbot, I said this: *"This is the first time in 15 or 16 years of me being a working professional that I feel fulfilled and happy. I think what I'm doing is meaningful."* Both of these are true. Neither is the same person speaking. The first is the person who is honest about not having aimed at anything. The second is the person who is honest about the fact that something landed anyway. This is my attempt to write down what I think connects the two, because I think a lot of operators are quietly running the same protocol and not saying so. ## What I actually aimed at I aimed at fun. I aimed at new. I aimed at people I thought were smart and good. I aimed at not letting down anyone who took a bet on me. That is the full list. None of those four things involves meaning, mission, or impact. None of them maps cleanly to *find your why*. None of them would survive a strategy offsite. The closest the list gets to ambition is *not letting down the people who bet on me*, which is the opposite of running toward something. It is running away from a specific failure mode, the one where someone who took a chance on you regrets it. I have run that protocol for fifteen years. I went to a small private liberal arts university in Oregon on a full scholarship because my Dad did not want to bet on a mediocre student and I had to earn the bet myself. I joined hCentive in 2011 because Tarun and Manoj seemed smart and the work seemed new. I joined OneDigital in late 2024 because Vinay seemed like someone I could learn from and the work was new again. Each transition was an *escape from* dressed up, briefly, as a *move toward.* If you had asked me at any of those moments to articulate my mission, I would have failed the question. The honest answer was always the same. *I do not know exactly what I am running toward. I know what I am running from. I will report back when I see what I have arrived at.* ## What landed anyway The funny thing is that the answer the chatbot extracted from me about *the first time in fifteen years I feel fulfilled* is not the first time fulfillment has actually happened to me. It is the second. In 2010 I graduated into one of the worst job markets in modern American history. The Affordable Care Act had just passed. The federal government needed someone to build the insurance exchanges that would let people who had been priced out of health insurance for years finally buy a plan. Tarun and Manoj's team at hCentive built those exchanges for Colorado, Kentucky, and a few other states. I spent the first three years of my career inside the engine of one of the largest pieces of public infrastructure that had been built in my adult lifetime. I did not know, at the time, that I was doing meaningful work. I did not aim at it. What I aimed at was closer to: *Tarun and Manoj are some of the smartest people I know and they took a bet on me. So let's not let them down.* I would have told you, at the time, that I was working hard, learning a lot, and being paid reasonably well to do something interesting. I would not have told you I was changing anyone's life. I am pretty sure several million Americans got insurance because of the systems we built. That fact landed on me retroactively, in pieces, over the next decade. I am living through the same pattern now at OneDigital. I am running the AI program at a 6,000-person consulting firm, eighteen months in. I think we have figured out something genuine about [how AI actually deploys in a large workforce, distinct from the keynote version](/notes/your-ai-deployment-is-failing) that most enterprise software vendors are selling. [Harvard published a case study on it](/notes/four-ai-agents-running-my-companies). My boss has [a book coming out this summer](https://www.amazon.com/Workforce-Intelligence-People-First-Playbook-Transformation/dp/1394467230) that quotes me in five places. A joint research project with Harvard, MIT, and UCLA is in motion that has invited me as a co-author. I did not aim at any of this. I aimed at *Vinay seems sharp, the work seems new, I am tired of the existing thing.* The rest landed. It is landing right now, in real time, in a way that has the same retroactive quality the hCentive years did, except this time I am old enough and rested enough to notice it while it is happening. ![The same person at a 2010-era desk and a modern desk today, joined by a thin coral light](/notes/i-never-aimed-at-meaningful-work/mid.png) ## Why I think this is the actual pattern There is a whole orthodoxy in the operator world about *finding your why* and *starting with mission* and *aligning to meaning*. Most of it traces back, in one form or another, to a TED talk most of you have seen. I would not say this in a public talk because it would be needlessly mean and I might be wrong, but I will say it here: I have watched almost no one I respect, who has actually shipped something that mattered, frame their work that way at the start. Most of them ran the same protocol I ran. They aimed at *new + smart-and-good people + don't-let-the-people-who-bet-on-me-down + this will make me some money*. They then worked hard as hell. Something landed. They were as surprised as anyone, even if they don't tell that story to the VC they pitch when they raise money. The people in my life who have *started* with meaning, who have *chosen* their cause early, who have *aligned* prospectively, have largely either gotten lucky or burned out. I am not arguing they are wrong. I am arguing the pattern is rarer than the genre of business book pretends it is. There is a quieter alternative posture that I think is actually true to how operators who ship meaningful work get there. It looks like this: Pay attention to who you want to be in the room with. Pay attention to whether the work is new in a way that makes you walk to your laptop instead of away from it. Pay attention to who has bet on you and pay your debt to them by doing good work. Look at the spread of what you have built after a decade and notice what the spread is telling you. The pattern that emerges from doing that, if you do it long enough, is what meaning actually looks like. Not from the front. From the back. ## What I owe the people who bet on me The bet-debt is real. It is a quieter motor in my work than I usually let on. I am writing it down here once because it deserves to be in the record. I owe Tarun and Manoj for picking me out of the 2010 graduate market when nobody else was hiring. I owe my Dad for the bet he made that I would take his rejection as a challenge and score well enough on the SATs to make the scholarship cover the gap, and not take the L and continue being mediocre. I owe my brother for running the family business for the years I was not in the country, and even after I was, for letting me figure my own way (mind you, he is six years younger than me, but mature beyond his years). I owe my wife for picking up the relationship costs of my work hours, the constant ups-and-downs from our move back to India, and the absolute tough, tough phase through SmartCue. I owe Vinay for picking me, in late 2024, for [a job I do not think I could have gotten based on my credentials](/notes/reach-for-what-you-havent-earned). None of that is the engine of my work. It is the floor of my work. It is the version of seriousness that operates beneath whatever surface fun-and-new framing I am wearing on any given Tuesday. I do not chase it. I do not optimize against it. But I notice when I am about to violate it, and I do not violate it. ## What I would tell someone trying to figure out their "why" Stop trying. Pay attention to who you want in the room. Pay attention to what makes the new tab open at six in the morning instead of feeling like a chore. Pay attention to who has paid for you to be where you are and what you owe them. Then go do work that does not make any of those three people regret the math. If a meaning shows up, you can write it down ten years later. Until it does, the meaning is doing what it always does, which is hiding inside the texture of the days. ## Closing I never aimed at meaning. I aimed at fun and new. I aimed at not letting Vinay down the way Tarun and Manoj before him bet on me and I owe them. Twice in sixteen years that has accidentally produced something I think was worth doing. I really hope it stays that way. --- ## There's No Playbook for Measuring Good AI Use at Work. Here's How My Thinking Keeps Changing. URL: https://robinsinghvi.ai/notes/no-playbook-for-measuring-ai-use Published: 2026-06-25 Tags: AI adoption, operator notes, measurement, OneDigital, AI at work Description: I run an AI program for a 6,000-person company. I have tried three ways to measure whether people are using it well, and every clean metric measured something slightly off. Here is where my thinking has landed, for now. OneDigital is a roughly 6,000-person company. It is traditional, relationship-based, and not what anyone would call tech-forward. My job is to get that company to use AI. Not eventually, not become tech-forward first and AI-native someday after. The goal is to skip a step most of the industry spent a decade on and leapfrog straight to AI-native. There is no playbook for this. There are plenty of two and three person companies that are AI-native from the first day. There is no large, traditional company that woke up one morning transformed and left behind a manual for the rest of us. So we are writing the playbook as we go, which is a generous way of saying I am guessing in public, on a deadline, with real people's workdays on the line. Getting people to use AI turned out to be the easy half. The goal we set was to get 85% of the company actively using it, and we are well on our way. The hard half is the question sitting underneath that one: are they using it well? And the harder half under that one: what does "well" even mean? I have been turning that question over for months. My answer has changed three times. This is the honest version of where it has gone, because I suspect a lot of people running these programs are quietly stuck on the same question and would rather not say so out loud. ## First, I tried to measure the back-and-forth The first frame felt obvious. Some people use AI like a search box. Quick question, quick answer, done. Other people use it like a thinking partner, a long back-and-forth where the thing actually helps them work through something hard. The first felt shallow. The second felt like the real prize. So the instinct was to measure how much of each was happening and push everyone toward the second kind. Transactional versus collaborative. Someone whose judgment I trust put it to me with an example about his kid. If the kid asks an AI to write a history essay, that is the shallow version. The kid asked, the machine produced, nothing got learned. But if the kid spends an hour going back and forth with it about Napoleon, really getting into it, that is the good version. More turns, more learning. It is a clean, intuitive picture, and I nodded along. Then I sat with it and it started to come apart. The Napoleon story is about learning. School is a place where the back-and-forth is the whole point, because the goal is what ends up in the kid's head. But most of what happens at a company is not learning. It is work. And for work, the back-and-forth is not the point. The outcome is. Here is the example that broke it for me. Say you have two hundred emails to get through this week. If you can use AI to get through them in a fraction of the time it would otherwise take, that is real value. Clear, obvious, money-on-the-table value. But by the transactional-versus-collaborative logic, that is a shallow, transactional use, and I am supposed to gently disapprove of it. I caught myself doing exactly that. Looking at someone who used the tool to summarize an email and thinking, well, that one does not really count. I was being biased. There is nothing wrong with summarizing an email. If the email got handled faster, the tool did its job. The fact that it took one good prompt instead of ten does not make it worth less. If anything the one-prompt version is better, because the person got their time back faster. That is when I realized the word "collaborative" was quietly doing two different jobs at once. Sometimes it meant a style of using AI, lots of back-and-forth. Sometimes it meant a valuable outcome, the AI did real work that mattered. Those are not the same thing. A one-shot "build me this deck" is low on back-and-forth and high on outcome. Smush both ideas under one word and the word starts fighting itself. I had been struggling with this for weeks, and the more I looked, the less sure I was that transactional versus collaborative was even the right frame to be reaching for. There was a smarter version of the idea that tried to fix the turns problem by crediting outcomes directly. If the AI ran a real multi-step workflow to get something done, count that as the good kind of use. That is closer, but it breaks the other way. Over time, [every AI coworker we build](/notes/your-ai-deployment-is-failing) will have workflows wired into it, because that is the entire point. You ask for the thing, a workflow fires, the thing gets made. So eventually a person could type one lazy line, a workflow runs automatically, and the conversation scores as deep and valuable even though the person did nothing thoughtful at all. At that point the score is measuring what we built into the product, not what the person actually did. That is a different problem wearing the same clothes, and I will come back to it, because it turns out to be the whole game. ## So I tried to measure the money instead If the goal is value, I thought, then measure value. Stop arguing about interaction style and just put a number on the work. So I built a dashboard that does exactly that. Every AI conversation gets sorted into a kind of work. Drafting a client email. Comparing two benefits plans. Pulling facts out of a policy document. Each kind of work has a rate card behind it, grounded in published research and government wage data: how long the task usually takes a person, how long it takes with AI, and what an hour of that person's time is worth. Multiply, sum across every conversation, and you get hours saved and dollars saved. I like this approach. It is rigorous in a way the first one never was. It is denominated in the one currency every leader already understands. And it is falsifiable, which matters to me more than it probably should. Every number on the dashboard breaks down into the assumptions behind it. If you think a rate is wrong, you can say so and point at the exact cell. I told the people I share it with that everything about it, including the methodology, is up for debate. I meant it. It also forced me to be honest in a direction most people avoid. When I built it carefully, the value number came out lower than an earlier, looser version had claimed, because the earlier version leaned on research findings that did not hold up once you actually read them. So I revised my own headline number down. On purpose. In a company where the easy move is to make your program look as big as you can, I made mine look smaller, because a number that survives scrutiny is worth more than a number that impresses for one meeting and falls apart in the next. The dashboard has a whole section that does nothing but list what the number does not mean, and another that tells you how to argue with it. But the value model has its own blind spots, and they are real. It is an estimate, not a measurement. Nobody is sitting there with a stopwatch. It is a careful guess wearing good sourcing. It cannot see quality. A conversation that produced a brilliant answer and one that produced a confidently wrong answer score exactly the same, as long as they were the same kind of task. The dashboard has no idea whether the work was any good. And for the exact question I started with, "are people using this well," the value model is quietly circular. It assigns more dollars to the task types that involve real work and fewer to quick lookups. So if I use it to ask whether my deep users are more valuable than my shallow users, the answer is yes, but partly because I defined it that way. I built the conclusion into the math. That is not a discovery. That is a mirror. ![Two nearly identical abstract column shapes on a light surface joined by a thin coral arc, suggesting two different readings of the same thing](/notes/no-playbook-for-measuring-ai-use/mid.png) ## Then I asked whether "depth" even predicts anything At this point I had two ways of looking at the same thing and a nagging sense that neither was telling me anything new. So I ran a test on the real data to find out whether depth of use earns its keep at all. Does using AI for real work early on predict anything down the line that the dollar number does not already show? A few things came back, and they were not what I expected. The first: almost nobody quits. About three out of four people who try the tool become regular users, and the share who try it once and disappear is tiny. When everyone has access, "who is going to churn" is just not a real problem here. Which quietly kills the most common reason to build a usage score in the first place, the idea that it warns you who is about to drift away. Nobody is drifting away. The second: how people start is how they continue. Someone who brings real work in their first few sessions tends to keep bringing real work, and someone who starts with lookups tends to stay in lookups. The pattern is stable, and it holds regardless of how heavily someone uses the tool. So depth is a real, separate trait, not just a fancy way of saying "power user." The third one is the one that actually changed my mind. I looked at each person's first handful of conversations and where they ended up. The people who started with nothing but quick lookups did clearly worse. They were less likely to stick, and they got a lot less out of the tool over time, worth roughly half as much. But here is the part the whole "push everyone to be collaborative" instinct gets wrong. The people who did best were not the ones who went all-in on big, deep tasks. The best outcomes came from a mix. Some real work, some quick questions. Going all-deliverable was, if anything, slightly worse than a healthy blend. So the lesson is not "more collaboration is better." The lesson is much narrower and much more useful: do not let someone get stuck doing only quick lookups. That is the actual danger zone, and it is the one piece of the original transactional-versus-collaborative instinct the data actually backs up. ## The twist that humbled all of it Then came the finding that made me distrust my own conclusion. The people stuck doing nothing but lookups might not have a usage problem at all. They might have a coverage problem. If your job is something specialized and nobody has built an AI coworker for that exact kind of work yet, then quick lookups are not you using the tool badly. They are the only thing the tool can do for you. You are doing lookups because there is nothing built for your real work to reach for. Same exact symptom. Opposite fix. One reading says "coach this person toward bigger tasks." The other says "stop coaching the person and go build them a tool." And from the usage data alone, I cannot tell which one I am looking at. That is the moment the whole project flipped for me. I had spent months trying to build a cleaner measure of how well people use AI, and the cleanest signal I found might not be measuring the person at all. It might be measuring a gap in what we have built for them, wearing a costume that looks like user behavior. It is the same trap as the auto-firing workflow from earlier, just upside down. There, the product made a lazy user look deep. Here, a missing product makes a willing user look shallow. In both cases the metric is quietly measuring us, not them. ## Where I've actually landed, for now So here is where my thinking sits today, fully aware that it will probably move again. There is no single number that measures good AI use. I went looking for one for months, and I do not think it exists, at least not for a company like mine. I keep the dollar model, because value in dollars is the most honest and most defensible thing I have, as long as I stay clear-eyed about what it cannot see. I treat the basic-versus-advanced distinction as a way to talk to people and to spot the ones stuck in lookups, not as a number I would ever put in front of leadership as a score. And I have stopped believing the right frame is the same for everyone. A team doing repetitive, specialized work and a team doing open-ended analysis are not on the same curve, and pretending they are is how you build a metric that flatters one group and punishes the other. These days, before I trust any new way of measuring this, I run it through two questions. What decision would I actually make differently if this number moved? And does it tell me anything I do not already have? Most candidate metrics fail at least one of those. Transactional versus collaborative failed both, right up until I narrowed it down to the single thing it is genuinely good for. There is a bigger question hiding under the measurement question, and it is the one I keep circling with the colleague I mentioned. The 85% coverage goal is clear, and there is real value in hitting it. But coverage by itself is not the thing. The question is, so what. So 85% of the company is using AI. Did it make a meaningful difference in their work, and through that, to the company? [That is the question I actually care about](/notes/did-they-get-better-or-were-they-always-good), and no single dashboard tile answers it. ### What I think comes next The honest gaps are clear to me even when the answers are not. I want a real signal for quality, whether the AI's answer was actually any good, and when I get one, the headline value number will probably drop, and that is fine. I want a clean way to tell the difference between someone using AI shallowly and someone who simply has nothing better built for them yet. And I suspect the real answer is not one metric but a small set of them, each with a blind spot I can name, each right for a different kind of work. The temptation, the entire time, has been to land on one clean number I can put on a slide that says "AI is working." The honest version is messier and, I think, more useful. It is a handful of lenses, each one slightly wrong in a way I can describe, that I keep arguing with. I write elsewhere about [the four AI agents I have running my own companies on the side](/notes/four-ai-agents-running-my-companies). This is the day-job version of the same itch, except now it is six thousand people instead of one, and I cannot just trust my gut about whether it is working. I have to measure it. And the closer I look, the more I think the measuring is the actual work, not a thing you finish and move past. I am not going to pretend I have the playbook. I am writing it as I go, the same as everyone else who is actually doing this instead of talking about it. The only difference, maybe, is that I am willing to say so. --- ## I Built Eight Things to See If AI Changed the Rules. The GTM Gap I Thought Was Permanent Started Closing Anyway. URL: https://robinsinghvi.ai/notes/i-built-eight-things-to-test-ai Published: 2026-06-15T09:00:00+05:30 Tags: AI workforce, operator notes, portfolio, GTM, indie ops Description: Eight side properties as a curriculum, not a strategic portfolio. The GTM gap I'd lived with for fifteen years is closing, using the same AI-leverage that built the eight things in the first place. When I sat down a while back to articulate my thesis for this notebook, I told a chatbot that GTM was the consistent gap across the eight things I run on the side. I said I could build things with AI. I said I could rebuild a family business. I said I could ship an iOS app. I said I could maintain a real B2B SaaS company solo. And I said I had never been great at selling, and that the gap was still there, after eight tries. I was honest with the chatbot. I was prepared to live with the gap as a permanent feature. I have not lived with it. The Meta ads on [Gramms](https://gramms.ai) are now generated by a Claude agent that proposes creatives, targeting, and bid adjustments off the previous day's performance. The agent posts a recommendation; I approve or override; the campaign runs. The marketing videos for the same product are being generated by a pipeline that drafts a script, generates the visuals, animates them with Higgsfield, voices them with ElevenLabs and Cartesia, and schedules the post across X, Instagram, TikTok, and YouTube through Upload-Post. The cold-outreach to parenting-niche journalists, podcasters, and influencers is being run by an agent that researches each target through Apollo and Hunter, finds the right contact, validates the email, drafts a personalized pitch in my voice, and sends it. The DM-based equivalent uses Perplexity to find the social handles of the same influencers, follows them on the right platforms, drafts the DM, and engages. None of these existed when I told the chatbot the gap was permanent. The gap is not closed. It is narrower than it was, and it is narrowing faster than I expected. The mechanism that closed the distance is the same mechanism that built the eight things in the first place. Which is itself the case study. ## The eight things, in plain language I am going to walk through the eight properties the way I would walk a friend through them at coffee, because the per-property elevator-pitch posture would not be honest. Each one tested an *AI now makes X possible* claim. Some of the claims survived. Some did not. [Audio2TextPro](https://audio2textpro.com) tested whether a non-technical person could build a production-grade end-to-end SaaS product with a website that did not look unpolished, free trial, authentication, freemium, payments, the whole stack. The answer was yes. The product itself is not a real business, and the domain is now closest-to-dead in my portfolio. I keep it because the cost is essentially zero and the proof is durable. [RoastMasterRick](https://roastmasterrick.com) extended the claim past *web app* into Chrome extension territory. Different surface. Different review process. Different paywall mechanics. The answer was yes again. It is small. It works. [Snaplife](https://snaplife.ai) tested whether AI could be *under the hood*, not just *the thing that built the product*. Still images become videos with synchronized audio through a pipeline that stitches together several model providers under the hood. The proof of the claim showed up in the free-tool pages, which are quietly the strongest organic surface in the whole portfolio. [Mark IT](https://markitsolutions.in) is the family Tally partner business in Mumbai, started by my mother in 1999, run by my brother now. It tested whether a single operator with AI could replace an external web team and an SEO agency that had been costing us hundreds of dollars a month and delivering thousands of monthly visitors. About ten hours of weekend work, three and a half months, three thousand visitors went to sixteen thousand. The agencies were fired. The claim survived strongly. The flip side I am watching now is that a meaningful share of the traffic to Mark IT is intercepting queries meant for India's government tax portal, which is the kind of advantage you cannot rely on forever. The next move on Mark IT is a cluster of commercial-intent Tally pages that gives the site real first-party demand, independent of the parasite. [Shrtfrm](https://shrtfrm.media) is my brother's and my wife's company. They are the co-founders. I help. It tests whether brand-driven media with strong original content can run an SEO + AEO compounding loop without a generic content factory bolted on. Still early. The proof is incomplete. [SmartCue](https://getsmartcue.com) is the company I started a few years ago with outside dev. I let the dev agency go fairly recently. For the past few months it has been me and Claude maintaining the codebase, shipping features for real customers, and running the business. It tests whether a real B2B SaaS company with paying customers can be run solo with AI. The answer is, so far, yes. The risk profile is real because the customers are real. The amount of code that has shipped in the months since the agency left is meaningfully more than the team shipped in a comparable window the year before. Gramms tested whether I could ship a B2C iOS app, a category I had never built in. The product works. What I am watching now is the slow build of organic surface area: a year ago there were no queries pointing at this domain; today there are dozens of category-level queries about bedtime story apps starting to land on the site's pages. None of that is yet revenue. All of it is the prerequisite to revenue. This site is the eighth thing. The meta-bet is that operators and organizations who recognize themselves in the receipts will read the notebook, find something genuinely useful in it, and at some point reach out about working on something more meaningful together. The bet is not yet proven; [the first cornerstone post](/notes/four-ai-agents-running-my-companies) landed on it this week. Eight properties is not a strategic portfolio. It is a curriculum I did not plan and that taught me a lot of things I would not have learned by going deep on any single one. ![Five AI agents in a row, each handling a different task, linked by a coral workflow line](/notes/i-built-eight-things-to-test-ai/mid.png) ## The thing the curriculum kept teaching When I look at the eight properties together, the lesson is not that *AI built them*. It is that AI extended my output across them in ways I did not predict. Research, competitor analysis, QA on my own products, product management, the writing of the content, the optimizing of the content, the generation of social videos, the customer support: each of those used to be a job, or a contractor, or me spending a Sunday on it instead of with my wife. Each of them is now a Claude agent that I gave a brief and a budget. The work happens. I review. (Swati may, in fairness, dispute the math on whether those Sundays have actually been reclaimed for her or for the next agent I am quietly building in the next room, and her notes would be fair.) If AI can do all of that, the question is no longer *how much focus can I give to one thing.* The question is *how many bets can I run in parallel where the marginal cost of running another one is the cost of articulating it once.* The total annual maintenance cost of all eight properties, including domains, hosting, infrastructure, and the AI subscriptions, is a few hundred dollars. The downside of running eight bets at that price is bounded. The upside is whatever I want to read into the spread. ## The gap that did not survive The one place the curriculum had been silent was GTM. I have always known this about myself. I came from solution consulting, not from sales. SmartCue's biggest problem in its first three years was that I was good at the product and bad at distributing it. Mark IT's biggest historical problem was the same. Snaplife had no GTM motion. Audio2TextPro had no GTM motion. Gramms was the first time I had ever tried to run paid acquisition for a B2C product, and the learning curve was steeper than anything else I had ever tried to learn. When I told the chatbot the gap was permanent, the honest version of what I meant was: I did not believe I could *learn* GTM the way I had learned building. Building had concrete primitives. Code was code. Schemas were schemas. There was something to point at when you were wrong. GTM felt like taste and relationships and showing up to the right rooms, and I had spent fifteen years convincing myself I was not the right kind of person for any of that. What I had missed is that the AI does GTM too, and that doing GTM with AI does not require becoming a different kind of person. The five pipelines I described at the start of this post all came online in the months after I told the chatbot the gap was permanent. None of them is a magic shortcut. Each one took a careful brief, several rounds of correction, real money to test, and a Sunday or two of integration. What I noticed building them is that the *mechanism* I used to build each one was the same mechanism I had used to build each of the eight properties. Articulate the next thing. Hand it to the model. Look at what comes back. Correct it. Run it. Read the result. Adjust the brief. None of this is *me becoming great at GTM*. It is me, with AI, doing GTM at a level that is real enough to move numbers, which is the only definition of competence I have ever cared about. The body-of-work approach applies to my own learning curve too. I would not have known this if I had not run the curriculum. ## SmartCue, briefly I think about SmartCue differently than I used to. The product still works. The customers still pay. My day-to-day with it is [calmer than it has been in years](/notes/asking-permission) because the agency I worked with is no longer in the loop and Claude is. The amount of code I have shipped in six weeks of solo + AI work meaningfully exceeds the amount the team shipped in the same window a year ago. What I notice when I sit with this is not pride. It is the operator's version of grief: an awareness that if these tools had existed five years ago, SmartCue might have been a different company than it is now. I am not going to dwell on that here. The point is that the curriculum taught me what the right risk-to-reward calculus looks like *today*, and the calculus is different than it was when I started SmartCue. That is also a real finding. ## What I have not figured out I want to be specific about what I have not figured out, because the rest of this post is honest and the close should be too. I have not figured out how to value the smaller properties that cost almost nothing to keep alive and produce almost nothing on their own. The portfolio cost is bounded and the upside is genuinely unknown, but *unknown* is doing a lot of work in that sentence. I have not figured out the right ratio of building new bets versus deepening the ones that are already moving. The instinct after a small win is to leverage it. The instinct after a small loss is to spread the chips wider. Neither instinct has been reliable enough to trust without checking it against the data. I have not figured out whether running this many parallel bets is something I want to be doing five years from now or whether it is the right shape of work for *this* phase, where the tools are new and the leverage curves are still steep. The honest answer is I do not know yet. I have, however, figured out that I am closer to the answers than I was at the start of the year. The mechanism is the same one that built each of the eight things in the first place, and is now running each of the five GTM pipelines. Articulate the next thing. Hand it to the model. Look at what comes back. Correct it. Run it. Read the result. ## Closing Eight properties. Five GTM pipelines. The receipts are on the table. There is still a long list of things I have not figured out. I am closing the distance on each of them by doing the next thing, with AI doing the work I cannot yet do by hand. The work that used to require a team is being done by a curriculum of agents I built one at a time. The work that used to require expertise I do not have is being done by [articulating the brief more clearly than I used to](/notes/the-ideas-guy-isnt-a-slur-anymore). If the lesson of the last five years was *just start*, the lesson of the last few months is that *the gap you are convinced is permanent might be the next one to close*. I would not have predicted this earlier this year. I am not going to predict the next few months. I am going to write the next thing down and hand it to the model and read what comes back and correct it and run it. I really hope it keeps working. I will write again when something changes. --- ## The Ideas Guy Isn't a Slur Anymore. Here's What Changed. URL: https://robinsinghvi.ai/notes/the-ideas-guy-isnt-a-slur-anymore Published: 2026-06-01T09:00:00+05:30 Tags: AI workforce, operator notes, articulation, one-person company, indie ops Description: The 2010s operator gospel (ideas are cheap, execution is everything) inverted sometime around 2023. Articulation became the bottleneck. Here's what that looks like up close. I am, by traditional measures, an ideas guy. I have never been the engineer in the room. The dev teams I worked with at hCentive a decade ago and at [SmartCue](https://getsmartcue.com) until last year wrote the code. I described what I wanted built and they built it. The dynamic was honest, and old. The labor of building was the expensive part. The ideas were cheap. A while back, the dev agency I'd worked with at SmartCue for years had a cycle time, between *here is what I want* and *the feature is in production*, on the order of weeks. I knew this was the cost of being an ideas guy with no shipping muscle. I had paid that cost for fifteen years and stopped questioning it. Then, fairly recently, I let them go and started maintaining the codebase myself, with Claude. The cycle time collapsed from weeks to hours. The customers did not notice. The product still ships. The thing I had been paying for, for fifteen years, quietly became free. Fifteen years ago, calling someone an *ideas guy* was a quiet insult. Today it might be the most underrated job description in tech. This is my attempt to write down what I think has actually changed, and what I think most people, including a lot of very smart people, are still missing. ## What an "ideas guy" used to be I am old enough to remember when *ideas are cheap, execution is everything* was the operator gospel. The 2010s startup canon. The whole point was that the bottleneck was the building. The hard work. The shipping. The integration nobody wanted to write. The marketing nobody wanted to do. Anybody could pitch you on a marketplace for cats and a delivery app for groceries. Almost nobody could actually build either of them. The market reward went to the people who closed the gap between the pitch and the working thing. The pitch itself was worth nothing without the closer. I internalized this. I spent most of my twenties and early thirties trying to recruit better builders, sit closer to them, learn enough to talk to them, and stay out of their way. I did not consider that the bottleneck might move. ## Where I noticed it had moved The first time I noticed something had structurally shifted was in late 2024, on the side, with Mark IT. Mark IT is the family business. My mother started it in 1999, ran it for eighteen months solo, and then convinced my Dad to leave a stable job to join her. He ran it for two decades. My brother runs it now. It is a Tally partner in Mumbai, the kind of business that survives on word-of-mouth, on relationships, on patience. For most of its life Mark IT's website was an afterthought. We had been paying a web development team and an SEO agency for years to do something to it. The results were what you would expect. Three thousand monthly visitors. Slow page loads. A blog written by someone who clearly had a template and no opinion. Forms that worked sometimes. I had been telling my brother for years that we should fix the site. We never did, because fixing it required hiring people who would also need to be managed, and managing them was a job, and the job was not worth the upside. In a few hours, across two or three weekends, with maybe ten hours of total focused work, I rebuilt the entire site. I thought through what the site should actually do, who should land on which page, what the content layer looked like, what the SEO strategy should be. I described it. I tinkered. I corrected. I read the AI's output and pushed back where it was wrong. I tested the result. We fired the web team. We fired the SEO agency. Three and a half months later the site was doing sixteen thousand visitors a month. The bottleneck had not been *time* or *talent* or *budget.* It had been my willingness to describe what I actually wanted clearly enough for someone, or something, to execute against. The agency had been failing in part because I had never made them work to a brief. The AI did not fail, because the AI did the thing the brief said. This is the part that surprised me. The labor of building was no longer the expensive part. The labor of *describing* was. ![A small-town storefront transforming into a modern website, linked by a faint coral arrow](/notes/the-ideas-guy-isnt-a-slur-anymore/mid.png) ## The eight properties as a curriculum After Mark IT, I started running this on purpose. [Snaplife](https://snaplife.ai) was the test of whether one operator could ship and run an AI-under-the-hood B2C product without engineering hires. [Audio2TextPro](https://audio2textpro.com) was the proof of concept that came before, and is mostly retired now. [RoastMasterRick](https://roastmasterrick.com) was the test of whether you could build a Chrome extension end-to-end on the side. [Shrtfrm](https://shrtfrm.media) tests whether brand-driven media is a viable wedge. SmartCue had been my real business since 2020 and quietly became the test of whether you can run a real B2B SaaS company solo. [Gramms](https://gramms.ai) is the test of whether just AI and an ideas guy can build a production-grade, high-quality, commercially viable iOS app. And this site is where I note down how my experiences pan out. Eight properties is not a portfolio. It is [a curriculum](/notes/i-built-eight-things-to-test-ai). Each one tests a specific *AI now makes this possible* claim. Each one teaches me whether the claim is true, half-true, or fashionable hand-waving. Some are alive. Some are barely alive. One is basically dead. I prefer this to the *I will know once I have built one perfect thing* posture, because the lesson lives in the spread, not in any individual property. What I did not appreciate when I started is that the curriculum was secretly teaching me one thing across all eight: how much output an articulate operator can extract from current AI. The answer is *a lot more than the trade publications are saying,* and the limiting factor is almost never the AI. The limiting factor is whether you actually know what you want. ## The smart people who do not get this The thing that surprises me, week after week, is who does not see it. Some of the most credentialed people in my professional life will tell me, when I ask, that AI is *fine* but unreliable. That it hallucinates. That it takes too much coaxing. That after the third or fourth time they corrected something obvious, they gave up and went back to doing the work themselves. These are people whose careers were built on being the sharpest analytic mind in the meeting. By every measure I can verify, they are sharper than I am. In my own experience working with the same tools, the AI is rarely the limiting factor in those conversations. The brief is. I will not say this to their faces, because it is rude and because I might be wrong. But I have started to suspect that the people who dismiss AI as too-error-prone-to-be-useful are sometimes describing the quality of the conversation they had with it, not the ceiling of the tool. The model can only ship what you can describe. If your description is fuzzy, the model's output is fuzzy. If your description is sharp, the output is shockingly close to what you imagined. This used to be an asymmetric advantage of senior engineers. They could translate vague product asks into specific build instructions, because translation was their craft. Now the translation has been collapsed into the user. If the user can do it, the model can do it. If the user cannot, no model picks up the slack. Twenty years of operator wisdom was that *the idea is worth nothing without the closer.* The closer used to be a person. The closer is now a process that anyone with a clear head and a willingness to be patient can run. The idea is back. ## What this actually means for "ideas guys" I am not arguing that pedigree is dead, or that builders are obsolete, or that you can think your way into anything. The world still has hard problems that require deep technical expertise, careful systems thinking, hard-won taste. Building anything with stakes still requires someone who can tell when the AI's output is wrong, which is itself a skill that comes from having built things. But the entry-level bar to *shipping at all* has moved. A clear thinker who has never written code can now do many things that used to require a small team. They can build a working website. They can run real ad campaigns. They can run customer outreach. They can rebuild a family business's online presence on a couple of weekends. They can launch an iOS app. They can run a portfolio of side properties one person could not have run a decade ago. Most of the people I know who are doing this well started off being called *ideas guys* by people meaning it as a criticism. I include myself in this. I consider myself, in the most operational sense of the word, mediocre. I am not the most disciplined engineer or the most charismatic founder in the rooms I am in. What I have learned, slowly, is that articulating is itself a craft, and that the craft is having a moment. ## What I am worried about I do not think this advantage holds forever. The current generation of tools rewards clear thinkers because they are the only ones who can drive the tools effectively. As the tools improve, the *articulation moat* shrinks. Eventually the model will infer intent from less and less input. The premium on clarity of thought goes down again. I also worry about a generation of operators who never have to learn the underlying craft because the tools paper over the gap. I am one of them. I am directly downstream of years of working with great builders who taught me what good looks like, even though I am not one. I do not yet know whether someone who skips that entirely can build durable things. So I hold this opinion contingently. The ideas guy is not a slur anymore *right now.* Whether this is permanent or a window, I cannot say. ## Closing I am an ideas guy who can now ship. That used to be a contradiction. The contradiction died sometime around late 2023, and many of the smartest people I know are still operating like it did not. That is the part I keep being surprised by, even though I am the person watching it happen on [three different tabs every weekend](/notes/four-ai-agents-running-my-companies). I am still figuring out what to do with the surprise. This site is part of figuring it out. I really hope it stays this way for a while longer. I have a lot left I want to build. --- ## It's 8 AM on a Sunday and Four AI Agents Are Running My Companies URL: https://robinsinghvi.ai/notes/four-ai-agents-running-my-companies Published: 2026-05-25 Tags: AI workforce, operator notes, case study, OneDigital, indie ops Description: Harvard published a case study on the AI program I run. I'm a self-described mediocre operator. I'm still trying to figure out what changed. It's 8 AM on a Sunday in May. Swati is asleep in the next room. The pour-over is gone. I forgot to turn on the AC, so I'm a little sweaty, which is just gross. I've been talking into a chatbot for two hours about my own life, for a writing project that's supposed to end with five essays on what I think I've figured out about AI and work. In the other tabs of this browser, three things are happening without me. In one tab, an AI agent is running a deep security audit on [SmartCue](https://getsmartcue.com), a B2B SaaS company I founded in 2020 and still run on the side. In another tab, a different agent is doing competitive analysis on [Mark IT](https://markitsolutions.in), my family's Tally Partner business in Mumbai, and rewriting parts of its site in real time. In a third tab, a third agent is setting up the day's Meta ads campaign for [Gramms](https://gramms.ai), a B2C mobile app I also run on the side. I haven't touched any of those tabs this morning. I gave each agent its budget and its context yesterday. They are working. Harvard Business School published a case study on the AI program I run at my day job at OneDigital. It came out in April. It's called *Building a Digital Workforce*. The lead author is Shikhar Ghosh, a professor at HBS and a principal investigator at their AI institute, a person Fortune once called "Master of the Internet Universe." There is a setup case before it covering the strategic decision that led to the program. He chose to write both. My CEO and CPO co-wrote a book about the program; it comes out this summer. I am quoted in it five times. Harvard, MIT, and UCLA invited me to co-author an academic paper on the same topic; that one comes out later this year. I went to a small private liberal arts college in Oregon, Willamette, on a full scholarship. My Dad could have paid. He didn't want to bet on a mediocre student. So I had to earn the bet by scoring well enough to get the scholarship myself. That worked. I graduated in 2010 into the worst job market in a generation, took an H-1B at a healthcare startup called hCentive that built the insurance exchanges for the Affordable Care Act in Colorado, Kentucky, and a few other states. I lived in DC, then Denver, then in 2018 moved back to India to be closer to family. I founded SmartCue in October 2020. In November 2024 I joined OneDigital as the person who runs their AI program. That is 18 months ago, in elapsed time. It still feels like I just started. I am 40. I am not, by any traditional measure, the kind of person Harvard professors choose to write case studies on, or invite to co-author papers with. Or rather, I wasn't. I am still trying to figure out what changed. ## What I think might have changed Here is the thing I keep noticing. AI is good at doing the work I tell it to do, very precisely. It is bad at deciding what work to do. It is a tireless executor and a useless visionary. And the bottleneck for most knowledge work used to be the executor. There were a lot more people with ideas than people who could ship them. Calling someone an ["ideas guy"](/notes/the-ideas-guy-isnt-a-slur-anymore) was a quiet insult. I am, by traditional measures, an ideas guy. I am fluent in business strategy because I read a lot, I think about it a lot, and I have shipped enough in the last fifteen years to recognize when I am seeing the same shapes again. I am much less fluent in the granular execution work, the SQL queries, the React components, the YouTube ad-copy variants, the SEO grunt work. That is the work other people used to have to do for me, or that I had to learn just-enough-to-be-dangerous to do badly myself. That gap is what AI inverted. The execution layer got cheap. The articulation layer, knowing what to ask for, in what order, with what context, against what fitness function, got disproportionately more valuable. I am not claiming this as an insight. The people who actually study workforce transformation already know it; that is the thesis of the book my CPO co-wrote. The reason it bears repeating is that the practical implications are still being missed by smart people I know. AI didn't make smart people obsolete; it changed what "smart" buys you. If you can articulate clearly, AI gives you a ten-person team. If you can't, AI gives you a slightly faster autocomplete and a lot of slop. What changed for me, specifically, is that the articulation work became my entire job. At OneDigital, my team and I don't write the AI Coworkers' code; we write their job descriptions, their training programs, their performance reviews. We hire them, supervise them, fire them when they don't perform. (I have fired a lot of Coworkers, mostly versions of the same Coworker that didn't quite work and got replaced. There is a joke in the book that when AI becomes sentient I'll be first in its firing line.) On the side, the same articulation work runs my eight properties. The browser tabs open right now are the proof. ## The receipts Three weeks ago, in one of these biographer sessions, I told the chatbot the consistent gap across my eight properties is GTM. I can build with AI. I have never been great at selling, distributing, marketing. That was true three weeks ago. Today my Meta ads campaign for Gramms is running daily, on a budget I set, executed by Claude without me touching it. I literally just give it the budget. It knows the context that it needs for setting up the campaigns. It is, in the most boring possible sense, off to the races. I am also orchestrating an influencer campaign for the same property, also via AI. The gap isn't gone. It is narrower than it was three weeks ago. The same lever that closed the build gap is closing the distribution gap. A different property, Mark IT, is my family's Tally reseller and consulting business in Mumbai. Mom started it on her own in 1999, ran it for 18 months solo, then convinced Dad to join. Dad ran it for the next two decades. My brother Kshitij runs it now. I rebuilt its website using AI on weekends, mostly over about ten hours of focused work spread across a few weeks, and traffic went from roughly 3,000 monthly visitors to roughly 16,000. Most of the work was AI iterating on SEO basics and content. No agency. No external consultant. The hosting bill stayed about the same. The SEO bill went to zero. SmartCue, the B2B SaaS I founded in October 2020, has been running solo for the past year. Zero developers. The AI handles the engineering work I would have needed three or four engineers for at our previous size. Customers still call. Revenue still comes in. I have not had to hire to keep it alive. At OneDigital, the AI Coworker program has been live for about a year. In that time, adoption has reached 64% of the workforce. That number matters not because of the percentage in isolation, but because of the time. Adoption usually decays back toward zero once the launch champagne wears off. Reaching 64% workforce-wide adoption inside a 6,000-person traditional consultancy, and watching it rise rather than fade, is not normal. The thing that makes it possible isn't the AI; it is [the boring discipline behind it](/notes/your-ai-deployment-is-failing). Three-phase coworker lifecycle. Five-tier human fluency model. Mandatory training. [Supervisors running bi-weekly 1:1s with their AI Coworkers like they would with humans](/notes/hiring-and-firing-ai-coworkers). None of this is futuristic. None of it is hard to explain. It is, on the inside, deeply unsexy. ![A stack of bound case-study pages with a coffee cup beside it](/notes/four-ai-agents-running-my-companies/mid.png) ## The weirdness of being studied I keep waiting for someone to tell me they got the wrong person. The book chapter that quotes me four times has me as the deployment expert. The HBS case study has the program I run as the subject. The joint paper has me as a co-author, sitting in working sessions with researchers from three universities, contributing to something that will be peer-reviewed and cited by other researchers. None of that was something I aimed at. I joined OneDigital because the work seemed interesting and the boss seemed like someone I could learn from. Eighteen months later there is a book about what we did. When this kind of recognition started showing up earlier this year, my honest first reaction was bewilderment. I know people who went to Harvard MBA who are smarter than me; they are not getting case studies written about their work. I know operators in my Twitter feed who shipped more than I did; they are not getting quoted in books. I consider myself, in the most operational sense of the word, mediocre. I read the business books most operators read. I have the kinds of opinions most operators have. I have not had a single insight in my life that I could honestly call original. What I have done, repeatedly, is keep showing up to bets that other people made on me. Tarun and Manoj at hCentive in 2010, Vinay at OneDigital in 2024. And I have tried not to let any of them down. That is it. That is the entire operating principle. Maybe what changed is that the kind of mediocrity I have, the kind that is good at articulating, good at showing up, good at not letting people down, turns out to be the kind of mediocrity AI multiplies. Maybe the kind that doesn't get multiplied is the kind that needed perfect technical execution to defend its ideas, and AI ate that defense. That would be embarrassing for the people who built their identity on it. I don't know if that is what is happening. I am an operator inside one company, watching one program work; I am not an economist with a dataset. What I can say honestly is this: the people who study how AI changes work are looking at the work I do. So whatever I am doing is real enough to study. I just don't think the smart people in my Twitter feed have the right model of what they are looking for. They are looking for the brilliant builder with the perfect AI workflow. They are missing the mediocre articulator with the boring change-management program. ## What I'm not telling you I am not telling you ideas guys can ship now. I am one. I am still not sure I have shipped enough to say that. Three of my eight properties are basically dead. Two are toys. Two pay their hosting bills and a little extra. SmartCue is the only one that is a real business, and its biggest growth windows happened before AI; the current AI-augmented era at SmartCue is more about running it lean than about growing it fast. The body of work is real. It is also small. The honest version of my résumé is: 40 years old, two businesses that mattered, 18 months of running an AI program at a 6,000-person company, mostly because I happened to be the right person for the right job at the right time. I am also not telling you to be like me. I think the through-line in my career has been "why not, what is the worst that could happen", a borrowed line from my mother and one I keep using because it is accurate. That posture compounded in an era where the cost of starting things kept falling. It would not have compounded in a different era. I happen to be middle-aged at a moment when the leverage on "why not" got obscene. That is lucky. That is not strategy. What I am doing here, on this site, is writing down what I think I see while I still see it. Mostly for myself. So that if any of this changes, if AI plateaus, if the program at OneDigital falls apart, if the receipts stop arriving, I can come back and read what I thought was happening before any of it shifted. The first thing I am writing down is the case Harvard published. The next ones will be [the rest of the eight properties](/notes/i-built-eight-things-to-test-ai), each of them an experiment in something AI now makes possible. I will be wrong about some of them. The point isn't to be right. The point is to have a record. A notebook, not a manifesto. ## Closing It is 8 AM on a Sunday in May. The pour-over is still empty. Swati is still asleep in the next room. I am still a little sweaty, because I still have not turned on the AC. In the three other tabs of this browser, SmartCue's security audit is still running, Mark IT's competitive analysis is still going, and Gramms' Meta ads campaign is mostly set up. I will review what each of them produced later this afternoon. The work happens regardless. I am not telling you I figured something out. I am telling you the people who study this stuff are looking at the work I am doing. I am still trying to figure out what to call it. I really hope it stays that way.