30 秒でわかる
Prathik Naidu argues that ownership can give AI teams closer access to workflows, expertise, feedback and established customer relationships. He contrasts this approach with selling software to an enterprise or starting a services company from scratch. He describes a selective acquisition process and a transformation J-curve: upfront investment, adoption and capacity gains, followed by the work of converting those gains into business outcomes. The financial examples are hypothetical.
- 1The deployment wallSecurity, old systems and user adoption make enterprise deployment difficult.
- 2Who captures value?A hypothetical contract illustrates how value can accrue to the customer.
- 3An ownership thesisNaidu argues acquisition provides access to people, data and established relationships.
- 4Selecting servicesHe looks for critical outcomes, human judgment and strong business fundamentals.
- 5The transformation J-curveInvestment and adoption precede measurable business outcomes.
ポイント
- Enterprise AI deployment requires integration, adoption and a way to capture value.
- Tacit knowledge and human judgment are essential to understanding services workflows.
- Ownership can align incentives and provide access to real work and feedback.
- Service economics vary; AI-driven improvements are a hypothesis to validate.
- Capacity savings become business impact only when teams put them to use.
チャプターごとに整えた全文を読む
The challenge of selling AI into enterprises
Naidu describes production, adoption and commercial barriers.
I am Prathik Naidu, a founding partner at Long Lake. I want to explain why acquiring businesses can be a way to deploy AI in the real world. Start with a familiar situation: you have built an agent that works for a narrow use case and now need an enterprise to use it.
Getting into production may mean security reviews, internal coordination and integration with systems that are twenty years old. After that comes adoption: changing the interface, training users and incorporating feedback. Who is responsible for driving use—the vendor or the customer?
Then there is the commercial question. Do you charge for tokens, seats or some combination? How do you address price sensitivity and measure return on investment? More broadly, how does the startup capture some of the value it creates?
These barriers reflect the difficulty of building from outside an organization. Models are improving, but deployment depends on more than model intelligence: companies are complicated systems of relationships, decisions and accumulated experience.
An org chart may show owners, managers and teams, but real decisions are embedded in a web of experienced people who interact across sales and operations. An outside vendor has to understand and work within that network.
Systems of record, documents and old email threads are useful, but they do not tell the whole story. Much of a complex business runs on judgment, exceptions, edge cases and the quick question put to an expert. Work with the people doing the job to understand what good work looks like.
Even if a vendor delivers end-to-end value, capturing it is difficult. Imagine a million-dollar annual contract: renewal and pricing are uncertain as models improve and alternatives become cheaper.
Suppose that engagement adds $5 million a year to the client’s EBITDA. At an illustrative ten-times multiple, that would imply $50 million of enterprise value for the client. This is a hypothetical arithmetic example, not a promised result: the vendor did the deployment work, while much of the impact appears in the customer’s business.
Building from scratch or acquiring
He compares a new AI-native firm with partnering through acquisition.
Another valid strategy is to start a business with AI at its core. You can improve the entire workflow, sell the work rather than one tool, and own the outcome. But it brings its own challenges.
A new company begins without customers or an established reputation, and specialist expertise can be hard to recruit. If a hospital is planning a surgical building, it may prefer a firm it has trusted for twenty years over a new AI architecture startup. Good firms spend decades earning customers’ trust and building teams.
Our alternative is to partner closely with existing businesses through acquisition. Ownership gives an engineering team access to the people doing the work and to veterans with decades of experience, helping it design for the wider operation rather than a single isolated task.

The business is also a live environment containing real tasks, edge cases and feedback on whether an agent was right. Those signals can help improve agents and models. Access still requires close collaboration with the people whose work is being changed.
I see incentive alignment as another advantage: the owner succeeds when the team and business succeed, rather than pursuing a separate vendor revenue target. That alignment can help resolve blockers and focus deployment on shared outcomes.
An established company can bring customer relationships, a trusted brand, expertise and cash flow for further investment. These assets are useful starting points, though an acquisition does not by itself guarantee trust or successful change.
My thesis is that access, data, aligned incentives, trust and scale can reinforce one another. Agents and people operate together, generate feedback from actual work, and use it to improve outcomes over time.
The economics of services
He outlines labor-intensive growth and the potential for AI operating leverage.
That leads to the services economy. Software commonly provides tools to people who do the work; services businesses take responsibility for delivering outcomes. We see that end-to-end responsibility as a large opportunity.

Services also face a scaling challenge: labor costs tend to rise with revenue. An HOA community manager can handle only so many associations, and an architect can design only so many hospitals or schools. More customers often require more hiring.
I use a simplified comparison: a software business might retain around $80 from an additional $100 of revenue, whereas a services business might retain around $20 after delivery and overhead. These are illustrative economics, not universal margins; actual businesses vary.
Our hypothesis is that AI can increase operating leverage and improve service quality, while expert people remain essential. Whether either benefit materializes depends on implementation; adoption, cost and quality must be demonstrated in each business.
Long Lake and its selection criteria
He introduces the firm and its focus on mission-critical services.
Long Lake describes itself as an applied-AI holding company that acquires and partners with services businesses to transform operations, grow and improve customer experience. At the time of this talk, I said we had raised $7.5 billion and partnered with around forty businesses.
I also mentioned our announced $6.3 billion take-private partnership involving Amex GBT, which would bring us into corporate travel. The announcement is an example of the thesis, not a claim that the transaction had already closed.
We look for mission-critical services where customers trust a business to own an end-to-end outcome, human judgment matters, and accountability may be shaped by regulation. The aim is to find companies with strong fundamentals as well as a meaningful AI opportunity.
The distinction is between drafting a message and taking responsibility for an urgent water leak; between extracting documents and handling a difficult tax decision; or between booking a flight and managing a last-minute disruption.
Such companies are rare, and their teams must also want the partnership. I described a large deal funnel followed by a tight filter: the intersection of attractive business and market fundamentals with a strong opportunity to apply AI.
Turning adoption into business impact
He explains the J-curve and the teams needed for deployment.

After a partnership begins, I picture transformation as a J-curve. First comes investment in the platform, technology, understanding workflows and the team’s time. Building with the business requires iteration, validation and sometimes training models for its particular data and work.
If the tools are adopted, they may free capacity: people can produce the same output in fewer hours. But time saved is not yet a business outcome. The next step is to put that capacity to work with the management team.
That could support growth or improve customer and employee experience, eventually showing up in the profit and loss statement. These are intended outcomes, not automatic consequences of deploying a model.
A shared platform and deployment playbook may make later transformations faster, rather than treating every company as a completely isolated project. I say we have seen this across our portfolio, although each company still requires its own operational work.
The work requires an M&A team to build relationships and acquire businesses, engineers to spend time with operating teams and build for the whole operation, and deployment and operations specialists to drive adoption.
Do not stop at an agent that saves time. Work with the business to turn that capacity into measurable impact and a better client experience. That combination of ownership, building and deployment is the opportunity we want to pursue in services.
同じチャンネルの記事
21:32EN
14:50EN
11:47EN
21:47EN
14:09EN
16:29EN