{
  "video_id": "B0fjR3yaZFU",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "How do you diffuse AI into the real world? — Varun Shenoy, Long Lake",
  "duration_seconds": 1066.0,
  "url": "https://www.youtube.com/watch?v=B0fjR3yaZFU",
  "upload_date": "",
  "transcript": "[music]\n>> Hi everyone. I'm Varun. I'm one of the\nco-founders at Long Lake and I'm excited\nto share a little bit about what we've\nbeen up to for the last 2 years.\nIt all comes back to a question all of\nus have asked time and time again.\nThe models are getting better,\nbut the real question is how do you\nactually deploy the AI into the real\nworld?\nHow do you get the models to complete\neconomically relevant tasks?\nLet me start by saying everyone has seen\nthe demo. Think of the agent\nautomatically booking a flight, the\nagent automatically completing a ticket\nin some kind of customer service portal.\nThink of an agent completing a block of\ncode ready to commit and go.\nThe reality is we've all seen this and\nit feels like magic. 2 years ago any of\nthis would have been complete science\nfiction. The capabilities are real.\nNow, walk with me into a 200-person\nproperty management firm.\nReal people, real properties,\nreal dollars, real customers all across\nthe US.\nYou would expect AI to show up by now,\nbut the reality is nothing has changed\nat all.\nHere's the thing.\nThis is totally normal and maybe in fact\nI'd argue this is what we should expect.\nThis is true for every general-purpose\ntechnology. You know, take electricity\nfor example.\nElectricity was invented in the 1880s\nand it was first demoed at Edison's\nPearl Street Station Dynamo Room over in\nManhattan.\nThis was the magic demo of its time.\nThe reality is it took a long time for\nelectricity to be fully adopted.\nConsider a Ford factory.\nIt's not enough to just have\nelectricity. You have to rip out the\nexisting motors and equipment. You have\nto bring in the new equipment. You have\nto go and train everybody to use that\nvery same equipment.\nHere's a picture of a Ford electrified\nmoving assembly in 1924.\nThese things take time.\nDiffusion of any technology takes a\ngeneration. And since everyone here in\nthis room today is talking about AI, I\nwould argue\nAI diffusion is perhaps the single most\nimportant problem for the next 20 years.\nThe models are going to keep getting\nbetter. The big question is how do we\nactually get these models to be in the\nreal world, complete real tasks, uh and\nmake people more efficient, happier, and\nprovide better service.\nSo taking a quick step step back, who\nare we? Uh we are Long Lake. Over the\nlast 2 years, we've raised over $3\nbillion from Elad Gil, General Catalyst,\nand AlphaWave since our founding.\nHere's the strange part. We we don't\nsell software. We actually go out and\nacquire and partner with real services\nbusinesses in the world. Uh we've\nacquired 35 businesses across HOA and\nproperty management, architecture, HR\nservices, and a lot more.\nTo give you a little bit more flavor, we\nhave roughly a 40% team right now split\nbetween technology, finance, and\noperations. More than half our team is\npart of the technology team focused on\nuh building products, data, and\ndeploying the core products into the\nfield. Uh we're in a collected group of\nfolks, a bunch of ex-founders who've\nworked in the services before,\nex-military, folks from Palantir, Ramp,\nGlean, uh and from the finance side,\nBlackstone, H.I.G., et cetera. We are we\nare not selling them to these companies\nabove from the outside. We're actually\ndeploying into these companies and\nfiguring out how to get the technology\nto work.\nAnd just to show you the scale we're\nplaying at, we announced recently our\n$6.3 billion take private of American\nExpress Global Business Travel, the\nworld's largest corporate travel\nplatform.\nWe own these businesses.\nSo, when the AI doesn't work, it's not\ntheir problem. We're not the vendor.\nIt's our problem.\nConcretely, again, we are not the\nvendor. We are the operator owners. And\nwe work very closely with our teams\nwithin the businesses to drive real\noutcomes.\nNow, I want to step back and get to the\nconcrete about the how. What are the\nlessons we've learned over the last 2\nand 1/2 years? And what we've learned\nfrom deploying AI into companies we've\nowned.\nThree quick lessons. One, how we move\nagents from co-pilots to co-workers.\nTwo, how we leverage real-world data\nwithin these businesses.\nRemember, we're seeing all of the work\nthat's being done in these real services\nbusinesses. There's a lot of interesting\nproblems and solutions embedded within\nthat.\nAnd then finally, perhaps the most\ninteresting and exciting is how do you\nactually get all of this technology to\ncompound over time by learning loops in\nthe enterprise. We'll get to that at the\nend over here.\nSo, starting off from co-pilots to\nco-workers.\nThere's a spectrum of how much autonomy\nyou can give an agent.\nOn the left here, you see a co-pilot.\nThis is, you know, your simple rag\nchatbot from 2 years ago. It's very\nquick. You can ask a question. Maybe\nit's integrated with some systems. It\ncan give you information back very, very\nquickly.\nThe second step is a synchronous agent.\nConsider something like Claude code,\nCodex, Claude co-work. It's real-time.\nThere's this two-way interaction. It's a\nbit more sophisticated than a co-pilot.\nYou can go let it run off for 1 to 5\nminutes. Uh it'll call tools, maybe use\nits skills. Uh it's still synchronous.\nYou still need to step in and ask a\nquery. So, the next obvious rung of the\nladder is the asynchronous agent.\nYou can come in here, still ask a query.\nThe agent will go off into the\nbackground, do some work, and then come\nback. Uh and what's really interesting\nabout asynchronous agents is that the\nuser does not have to be the one that\ntriggers them.\nYou can have external triggers as well.\nMaybe someone completes a certain task\nand there is an async job queue uh that\nallows the async agent to pull off from\nand proactively offer advice to the end\nuser.\nThen, I'd argue the next step is a\nlong-running agent.\nHow do you get these agents to work for\nhours, days, weeks, months, etc.? I\nthink this is currently a very core\nproblem that a lot of the labs are\nfocused on, as are we.\nAnd then finally, at the end, the holy\ngrail, an AI co-worker.\nThis is where most people start off.\nYou want a proactive partner that gets\nwork done just alongside you.\nThis is what everyone wants to sell you,\nbut what we've learned from owning the\noutcomes in this business is\nyou have to earn the right to do more.\nIt's it's not enough to jump to the\nco-worker immediately,\nright? For for a bunch of reasons. One,\nfor certain tasks, the models might not\nquite be there yet. And two, you\nactually have to work with these\ncompanies in the field, interact and\niterate very, very closely, so that they\nunderstand that this is the beginning of\nAI, and you can work up the rungs over\ntime.\nI think a really unique lens to look at\nthis problem through is the that of the\njagged frontier. We all know that agents\nare incredibly good at writing code. So,\nwhat does the, for example, synchronous\nagent for code generation look like?\nThis is super simple. This is just your\ncoding agent, maybe it's Codex, Cloud\nCode, just running on your desktop. It\nhas access to a file system. You\ncollaborate within real time. You get\ninstant feedback and you iterate.\nThe next step is, you know, if you look\nat code code generation, what is the\nasync agent? This is also fairly\nstraightforward and largely solved. You\ntake the exact same coding agent, you\nwrap it in a sandbox, and you just let\nit go run. It can build, it can test,\nand once it's done with its work, it can\nprovide the code in the form of a PR.\nOne thing that's really unique about\nengineers is folks are incredibly good\nat already paralyzing their work.\nIt's very commonplace to launch 10 jobs\nand be comfortable with the fact that\njob seven might finish before job three.\nSo, engineers are incredibly good at\nusing these async agents.\nNow, when we come to services, the\nequivalent of a synchronous agent, what\nwe talked about a little bit earlier,\nit's a co-working agent. It's an agent\nthat has deep context about your\nenterprise. It interacts potentially\nwith MCPs, custom tools, custom\nintegrations, uh and you can chat with\nit synchronously just like any of these\nother products.\nI think this is a frontier here in the\nbottom right.\nWhat does it mean to build an\nasynchronous agent for the services?\nWhat does it mean to paralyze work in\nindustries where work is traditionally\ndone in a very, very serial manner?\nThis is where we spend a lot of time and\nthis is what I wake up every morning\nreally excited thinking about, you know,\nwe've we've figured out what the async\nand forking mechanism for code is. You\njust spin up a bunch of sandboxes and do\nwork. What does that look like for the\nrest of the world?\nSo, here's a couple questions we think\nabout pretty seriously. One, you know,\nthe models are trained on code, they\nwant to write code, they're incredibly\ngood at writing code. How do we leverage\nthese coding agents for actual knowledge\nwork? You You rather than wait for the\nmodels to catch up on doing services\nknowledge work, what if we just use that\ncode knowledge and represent knowledge\nwork as code?\nTwo, as I mentioned, engineers are used\nto paralyzing work. How do you paralyze\nwork that's traditionally serial? You\nknow, people clean out their inbox one\nemail by one email, not 10 emails at\nonce.\nAnd finally, how do you move up the\nladder here both in terms of product and\nuser enablement?\nWhat are the right form factors? And I'd\nargue this varies dramatically from\nindustry to industry. Just because you\nhave one way of launching an async agent\nfor code, doesn't mean that same way is\ngoing to work for architecture or\nproperty management.\nThe second point I want to cover today\nis leveraging real-world data.\nWe all know this. Frontier models have\nlearned from everything humanity has\nwritten down,\nbut the most valuable tasks are not on\nthe internet.\nHow do you actually close the books when\nyou're missing receipts?\n>> [snorts]\n>> How do you scope a building for\nconstruction in a blueprint, potentially\ncollaboratively?\nHow do you coordinate vendors for fixing\na broken roof?\nAll of this knowledge lives in people's\nheads, in 20-year-old software, uh in\nthe way that one senior person on one of\nthese teams just knows how to do it. How\ndo you make this information explicit\nand create tasks that you can actually\nlearn from?\nSo, we've constructed a little bit of a\nflywheel. We get our agents to\ncollaborate with our employees to do\nreal work. And this allows us to\ngenerate rich traces of data and\ninformation. Tool calls, the hiccups,\nthe papercuts, everything that goes\nwrong with doing real work.\nThis in turn allows us to build\nreal-world evals.\nThere is a ground truth here. In the\ncase of the roofing example, the\nquestion is, did the roof get repaired?\nDid the books get closed?\nAnd this allows us to hill climb and\nbuild better agents, which leads to more\nand more impact. And what's really\nexciting is it ratchets up. Every week\nour hill climbing benchmarks\nbecome a regression test. So, our agents\nget better and better over time.\nJust to drive a little bit deeper here\non the traces, there's three upshots of\nbeing able to collect these rich traces.\nOne, we get to generate amazing evals\nthat are built and scored automatically.\nUh and we're able to gather both\nimplicit and explicit feedback. Explicit\nfeedback in the sense of thumbs ups and\nthumbs down, maybe people provide a note\ntelling us whether this response was\ngood or not. Uh and also implicit\nfeedback. Right? Again, we have the\nground truth. Maybe there's some data\nthat the AI generated and there's a real\ndiff between the data that the AI\ngenerated and what was ultimately\nsubmitted. That's rich information that\nalmost no one else has.\nTwo, we've started post training models\ninternally on\nall of the data that these businesses\noperate on and produce, generally\nspeaking.\nThis is all data that is completely out\nof distribution for most frontier labs.\nThink of the task I showed at the\nbeginning. A lot of the models A lot of\nthe frontier models today just can't do\nthese tasks yet and we're trying to post\ntrain our own models internally to be\nable to do that on the rich source of\ndata that we own.\nAnd then finally, the actual agents\nthemselves.\nThe real world is incredibly hairy and\nmessy and you want customization per\ncompany. Every company does things very\ndifferently. Customization per user. The\nway each user does their work is very\nunique. And customization per client.\nThe way you work with every client is\ndifferent. It's a services business and\nyou want to uphold those standards.\nI love this picture\nbecause it's the whole thing in a single\nimage. Um the the way we usually talk\nabout LLM tasks is the top panel. Right?\nYou just It's It's a slope. You got a\nbike. And but there's clear sight to\nsuccess.\nThe reality is most work is not like\nthat. And And you and I both know that.\nUh there are hills and ravines. Uh\nthere's death by a thousand paper cuts.\nBut But that's what real work looks\nlike. That's the entire job. The\nexceptions are the job.\nThat's That's the demo.\nThat's the actual job.\nNow, on to the final thing I want to\nchat with you guys today is learning\nloops within the enterprise.\nI'd argue there's two hot trends\neveryone's talking about in 2026. One,\nit's continual learning. How do you make\nan agent better over time with feedback?\nI think there are plenty of sessions uh\nthis week on how you can use continual\nlearning, whether it's in the prompt or\nin the weights.\nAnd two, enablement. How do you get in\nthese enterprises and actually get them\nto adopt and use AI?\nTraditionally speaking,\nthese two initiatives are owned by two\nseparate teams. Right? The continual\nlearning is owned by your research team,\nyour platform engineering team.\nEnablement's owned by growth or\ndeployment or customer experience. Uh\nusually pretty siloed, not much\ninteraction between the two.\nWe think these are part of the exact\nsame loop.\nThe agent only improves if people\nactually use it.\nAnd people only use the agent if it's\nworth adopting.\nSo, here's a little graphic of a\nsnowball. More usage drives continual\nlearning, which drives a better agent,\nwhich drives more usage again.\nAll this to say, there's still a really\nbig elephant in the room.\nHow do you get the initial usage?\nI think a lot of people, you know, will\nuse Claude Code or or give it to their\nwhole enterprise, expect folks to just\nstart using it.\nEveryone assumes the usage just shows\nup.\nBut as we all know, that's simply not\nthe case. It never does. Right? Getting\na 100-year-old firm to change its\nprocesses is hard.\nYou could have the best AI coworker on\nthe internet or on Earth. And if the\npeople if the person who's closed the\nbooks for the last 20 years continues to\ndo things the same way,\nnothing changes. Nothing happens.\nSo, what can you actually do about it?\nWhat you know, this this seems like\nincredibly hard. What what's the upshot?\nHow do you actually get this stuff to\nwork? Well, I think a lot about Jensen\nand how he dominated the market in his\nwords with extreme hardware software\nco-design. Designing the chips and the\nsoftware together as one system.\nWe look at this through the lens of\nextreme software service co-design. How\ndo you co-design our products with the\npeople and the processes at our\nbusinesses? And I'd argue this is only\npossible from being within under the\nsame roof.\nWe need to meet the people within these\ncompanies both metaphorically, for\nexample, bringing products to their\nsystems so that the energy required for\nenablement is kept low, and also\nphysically. Get on a plane, show up, say\nhi, learn what people actually do.\nYou know, maybe you build a product\nthat's natively embedded into Excel or\ninto their ERP system, maybe their 3D\ndesign software, or or maybe even their\nMicrosoft products like Outlook, Gmail,\netc.\nOr you show up in person. You do a lunch\nand learn with a bunch of folks at one\nof the companies. You go to their\nconferences and you create cotton candy\nand run a stand for them. You go\nmountain biking and ask them about all\nthe difficulties that they have with\ntheir actual day-to-day jobs.\nOr you show up in person one-on-one or\nsometimes even two-on-one in this case\nand just show them how to use the tools\nand learn from the feedback because this\nis what the rest of the world really\nlooks like. It's not like the folks in\nthis room or in San Francisco. It's a\nlot more like this. You cannot co-design\nsoftware with the services business over\nZoom\nor over a support ticket. You you have\nto be there. You have to be in person.\nAnd I'd argue this is the part that\nactually makes it work. In order to get\nAI diffusion to work, you have to touch\nsome grass.\nThank you so much. I'll be around for\nthe rest of day if there's anything I\ncan help with. My email is up there.\nAnd yeah, thank you.\n>> [music]",
  "transcript_chars": 16735,
  "ingested_at": "2026-09-03T10:30:40.587709+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": null,
    "like_count": null,
    "channel_id": null,
    "categories": null,
    "tags": null
  }
}