AI diffusion takes years because companies must change equipment, processes, and employee habits, not just buy better models.
2
Services work needs asynchronous agents, but the right way to reach more autonomy is to earn trust through useful, bounded deployments.
3
Real-world traces and ground truth can create evals and learning loops, while adoption requires building software with operators in person.
Summary
Varun Shenoy argues that the hard part of AI is no longer demonstrating what models can do. It is getting them to complete economically useful work inside real companies. He compares the current moment with electricity, which needed new factory equipment and retraining before it changed production. Long Lake approaches this problem by owning the services businesses where it deploys AI, including property management, architecture, and HR companies. That gives the team direct responsibility when systems fail. Shenoy describes a progression from copilots to synchronous and asynchronous agents, long-running agents, and eventually AI coworkers. Services still lack the equivalent of coding agents that can safely parallelize work. Long Lake uses operational traces, feedback, and measurable outcomes such as whether a roof was repaired to build evals and improve its systems. Shenoy's answer to adoption is software-service co-design: work directly with employees, embed tools in their existing systems, and spend time with them in person.
AI diffusion requires changes to the workplace, not just better demos
Shenoy opens with familiar agent demos, such as booking flights, completing customer-service tickets, and producing code ready for a pull request. Then he contrasts them with a 200-person property management firm, where AI has not changed daily work. He says this delay is normal for general-purpose technologies. Electricity was demonstrated at Edison's Pearl Street Station in the 1880s, yet Ford's 1924 electrified assembly line required replacing motors and equipment and training workers. His conclusion is that AI diffusion will take time because companies must change how work is done, not simply add a model to existing processes.
Owning the businesses makes AI failures an operating problem
Long Lake does not sell software from outside the companies it works with. Shenoy says it has acquired 35 businesses across HOA and property management, architecture, HR services, and other areas. The company has raised more than $3 billion and recently announced a $6.3 billion take-private of American Express Global Business Travel. More than half of its team works in technology, focused on products, data, and deployment. Because Long Lake owns the businesses, a failed AI system cannot be blamed on a customer. The company has to work with employees and fix the process itself.
Agents should move up an autonomy ladder as they earn trust
Shenoy describes a progression from a retrieval chatbot, to a synchronous agent that works interactively, to an asynchronous agent that continues after the user leaves. Asynchronous jobs can also start from external triggers rather than a person's query. After that come agents that run for hours, days, weeks, or months, and eventually an AI coworker that works proactively alongside a person. Shenoy says companies should not jump straight to the final stage. Models may fail on particular tasks, and employees need repeated interaction with the system before they accept more autonomy.
Coding agents expose the missing services equivalent
Coding agents already support asynchronous work in a straightforward way. A system can run in a sandbox, build and test code, and return a pull request. Engineers are comfortable launching ten jobs and accepting that job seven may finish before job three. Shenoy says services work is different because people usually process tasks serially. They clear an inbox one email at a time, for example. The unresolved problem is how to parallelize work in property management, architecture, and other services where tasks depend on messy context and are usually handled in sequence.
Shenoy asks whether coding agents can be used for knowledge work instead of waiting for models to become naturally good at every services task. His proposal is to represent knowledge work as code so that existing coding capabilities can help execute it. He also says the right interface for launching asynchronous work will differ by industry. A pattern that works for software development may not work for architecture or property management. Product design and user enablement therefore have to change with the work itself.
Operational traces turn messy work into measurable training data
Many valuable services tasks are absent from internet training data. Shenoy gives examples such as closing books when receipts are missing, scoping construction from a blueprint, and coordinating vendors to repair a roof. The knowledge often lives in an experienced employee's habits, old software, and unwritten decisions. Long Lake has agents collaborate with employees on real work, collecting tool calls, failures, and small points of friction. Those traces support evals with ground truth. The question for a roofing task can be whether the roof was actually repaired, and the question for accounting can be whether the books were closed.
Continual learning and enablement form one adoption loop
Shenoy connects continual learning with enterprise enablement. These efforts are usually handled by separate teams, but he argues that they depend on each other. Agents improve when people use them and provide feedback. People keep using them only when the agents are useful. Long Lake treats this as a snowball: more usage creates more learning, which improves the agent and drives more usage. Its benchmarks can become regression tests each week. The harder first step is getting people to use the system at all, especially in older firms with established processes.
Software-service co-design requires being physically present
Shenoy says adoption depends on designing products with the people and processes of the businesses where they will run. The software may need to live inside Excel, an ERP system, 3D design software, Outlook, or Gmail so that the cost of changing behavior stays low. The Long Lake team also meets workers in person through lunch-and-learns, trade-conference booths, one-on-one training, and informal conversations such as mountain biking. Shenoy's point is that services work cannot be co-designed over Zoom or a support ticket. The builders have to observe the work and learn directly from the people doing it.
"You cannot co-design software with the services business over Zoom or over a support ticket."16:55
Who should watch
You are building AI tools for property management, architecture, HR, travel, or another services industry where work happens outside public internet data.
Your team is deciding how to move from a copilot to agents that run asynchronously or act with more autonomy.
You own enterprise adoption and need a way to connect product learning, evals, training, and day-to-day workflow changes.
