How do you diffuse AI into the real world? — Varun Shenoy, Long Lake

AI can book a flight, complete a support ticket, or produce code ready for review. Those demonstrations now feel plausible. Yet Varun Shenoy asks the audience to enter a 200-person property-management firm, where real employees manage real properties, customers, and money. There, he says, the work may look essentially unchanged. The talk begins with that discrepancy: model capability has arrived faster than operational adoption. 0:43

Shenoy treats that gap as normal for a general-purpose technology. His electricity analogy separates invention from diffusion: electrifying a factory required replacing motors and equipment, reorganizing production, and training workers—not merely connecting an existing process to a new power source. The historical analogy supports his main operating model: deploying AI means changing the surrounding system of work. His claim that diffusion takes a generation, and that AI diffusion will be a defining problem for the next 20 years, is a forecast rather than a measured timetable. 1:34

Long Lake approaches that problem through ownership rather than conventional software sales. Shenoy reports that the company had acquired 35 services businesses across areas including HOA and property management, architecture, and HR services. He describes a roughly 40-person Long Lake team spanning technology, finance, and operations, with more than half focused on products, data, and field deployment. He also cites a recently announced $6.3 billion take-private of American Express Global Business Travel to convey the scale of its operating environment. These figures describe the company at the time of the talk; they do not by themselves establish the effectiveness of its AI deployments. 3:01

Ownership changes the feedback mechanism. A software vendor can attribute weak adoption to a customer’s processes, implementation, or training. Long Lake cannot make that separation inside businesses it owns and operates: when an agent fails to produce the intended result, the failure remains its problem. Shenoy organizes the rest of the talk around three linked questions: how to increase agent autonomy, how to learn from operational data, and how to make improvement compound through enterprise learning loops. 4:17

Shenoy describes autonomy as a ladder rather than a binary choice between chatbot and coworker. Each rung changes who initiates work, how long execution lasts, and how much supervision remains:

• Copilot: A user asks a question and receives information, potentially through retrieval and connected systems.
• Synchronous agent: The user initiates a task and interacts with an agent that can call tools and work for roughly one to five minutes.
• Asynchronous agent: Work continues in the background and returns later; an external event or job queue can trigger it without a fresh user request.
• Long-running agent: Execution stretches across hours, days, weeks, or months.
• AI coworker: A proactive partner works alongside the employee and takes broader responsibility for getting work done. 5:21

The temptation is to start with the coworker because it is the easiest product vision to sell. Long Lake’s operating experience leads Shenoy to the opposite sequence: an agent must earn the right to do more. Some tasks still exceed model capability, and employees need time and close field support to understand where the system works. Gradual expansion also gives the deployment team opportunities to observe failures before granting wider autonomy. The talk does not specify formal promotion thresholds between rungs, so “earning” autonomy remains an operating principle rather than a quantified policy. 6:48

Coding makes the ladder concrete. A synchronous coding agent can inspect a filesystem, modify code, call tools, and receive immediate human feedback. To make it asynchronous, the developer can place essentially the same agent in an isolated sandbox, let it build and test, and receive a pull request when the task finishes. Shenoy describes this pattern as largely solved relative to the corresponding problem in services. 7:33

Engineers also already accept out-of-order completion. They may launch 10 jobs and remain comfortable when job seven finishes before job three. That habit matches asynchronous agents: each task can occupy a separate sandbox, while the person reviews results as they arrive. Traditional services work usually lacks both the sandbox and the habit. Employees clear an inbox one message at a time, and many business processes assume serial ownership of a case. 8:03

A synchronous services agent is easier to imagine: give it enterprise context, custom tools, integrations, and potentially MCP connections, then let an employee chat with it. The harder frontier is an asynchronous services agent that can safely fork real work. Code has filesystems, sandboxes, builds, tests, and pull requests as natural execution and review boundaries. Architecture and property management need their own equivalents: task representations, isolated workspaces, completion evidence, and interfaces for reviewing results. Shenoy poses this as an open problem, not something Long Lake claims to have fully solved. 8:33

His proposed research direction begins with a model capability that already works well: code generation. Instead of waiting for models to learn every services workflow directly, Long Lake asks whether knowledge work can be represented as code and executed by coding agents. But representation is only one part of the problem. The product must also determine which serial workflows can be parallelized and which interface fits each industry. A launch mechanism that works for code will not automatically fit architecture or property management. 9:24

The most valuable services tasks are often absent from public training data. Shenoy’s examples are deliberately mundane and difficult: closing the books when receipts are missing, scoping construction from a blueprint, and coordinating vendors to repair a broken roof. The procedure may live in a senior employee’s memory, a 20-year-old application, or an informal sequence of judgments. Before an agent can learn from this work, the organization must make the task and its hidden decisions explicit. 10:24

Long Lake’s proposed flywheel begins by having agents collaborate with employees on actual work. That interaction generates traces containing tool calls, corrections, exceptions, small frictions, and failed attempts. The trace is useful because it connects model behavior to an operational outcome. For the roofing workflow, the final question is whether the roof was repaired; for accounting, whether the books closed. Those outcomes provide stronger ground truth than whether a response merely sounded convincing. 10:53

Each observed failure can become an evaluation case. Shenoy says Long Lake hill-climbs against these benchmarks and turns each week’s benchmark improvements into regression tests. The intended ratchet is straightforward: real work exposes a failure, the team changes the agent, and the retained case checks that later changes do not reintroduce the same problem. The talk does not report benchmark sizes, pass rates, or measured business gains, so it explains the feedback architecture rather than demonstrating its quantitative effectiveness. 11:23

The traces support three parallel improvement mechanisms:

• Evaluation signals: Explicit feedback includes ratings and written notes. Implicit feedback includes the difference between AI-generated data and the version an employee ultimately submitted.
• Post-training data: Shenoy says Long Lake has begun internally post-training models on proprietary operational data that is out of distribution for many general-purpose models. He provides no comparative results for those models.
• Agent customization: The surrounding agent must account for differences among companies, individual employees, and clients. In a services business, those variations are often part of the expected service rather than noise to discard. 11:53

This is why polished demonstrations misrepresent the shape of the work. A benchmark task may look like a clear downhill route with success visible from the start. Operational work contains missing receipts, unusual client expectations, software quirks, vendor delays, and exceptions layered on exceptions. Shenoy’s sharpest formulation is that “the exceptions are the job.” In other words, handling the nominal path demonstrates capability; surviving the accumulated edge cases determines whether the system can operate. 13:04

Enterprise teams often separate continual learning from enablement. Research or platform engineering owns improvements to prompts or weights, while growth, deployment, or customer-experience teams try to persuade employees to use the product. Shenoy argues that this organizational split hides a dependency: the agent only learns from operational use, while employees only keep using it if learning makes it better. 13:43

The resulting loop is a snowball: more usage produces feedback, feedback improves the agent, and a better agent earns more usage. But a loop with no initial motion produces nothing. Giving a capable tool to an entire company does not guarantee adoption, especially in a 100-year-old firm where an employee may have closed the books the same way for 20 years. Technical quality cannot generate training traces if the product never enters the workflow. 14:29

Shenoy calls the response extreme software-service co-design: develop the software together with the people and processes that deliver the service. The analogy is to hardware-software co-design, where neither layer can be optimized independently. Here the service operation is part of the system. Product design, deployment, workflow changes, employee training, feedback collection, and model improvement must inform one another rather than pass work between isolated teams. 15:29

Software-service co-design starts by lowering the energy required to try the system. That can mean embedding the product where employees already work: Excel, an ERP, 3D design software, email, or other familiar tools. Asking people to leave their operational system for a separate AI interface adds friction before the agent has demonstrated enough value to justify a process change. 15:59

It also means observing work in person. Shenoy’s examples are intentionally unglamorous: lunch-and-learns, one-on-one or two-on-one training, running a cotton-candy stand at a company conference, and asking employees about day-to-day difficulties while mountain biking. These activities create opportunities to see tacit procedures and small frustrations that a support ticket or scheduled video call may never expose. They also let the deployment team teach the product while collecting immediate feedback. 16:29

The talk ends by making physical proximity part of the technical method. Shenoy argues that a services business cannot be co-designed adequately over Zoom or through support tickets alone. That is a strong operating judgment, not a controlled comparison of remote and on-site deployment. Its practical force comes from the rest of the talk: if valuable workflows live in people’s heads, if exceptions define the real job, and if improvement depends on traces from actual usage, then the deployment team must get close enough to see how work really happens. In his closing phrase, AI diffusion requires teams to “touch some grass.” 16:59