Prathik Naidu: Using Acquisitions to Deploy AI in Services

Long Lake’s founding partner explains the investment and operational case for buying services companies and deploying AI inside them.

PNPrathik Naidu연사 · Long Lake
채널
AI Engineer
게시일
2026년 10월 19일
영상
18:51
읽기
6분
슬라이드
3
원문
영어
YouTube에서 열기
스크롤하면 영상이 오른쪽 아래로 작아져 계속 재생됩니다. 자막은 읽기 언어를 따릅니다.
읽기 언어2개 언어로 읽을 수 있음
이 글은 아직 한국어 번역이 없어 영어 원문으로 표시합니다.
요약

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.

  1. 1The deployment wallSecurity, old systems and user adoption make enterprise deployment difficult.
  2. 2Who captures value?A hypothetical contract illustrates how value can accrue to the customer.
  3. 3An ownership thesisNaidu argues acquisition provides access to people, data and established relationships.
  4. 4Selecting servicesHe looks for critical outcomes, human judgment and strong business fundamentals.
  5. 5The transformation J-curveInvestment and adoption precede measurable business outcomes.

핵심 정리

  1. Enterprise AI deployment requires integration, adoption and a way to capture value.
  2. Tacit knowledge and human judgment are essential to understanding services workflows.
  3. Ownership can align incentives and provide access to real work and feedback.
  4. Service economics vary; AI-driven improvements are a hypothesis to validate.
  5. Capacity savings become business impact only when teams put them to use.
전문

챕터별로 다듬은 전문 읽기

01

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.

02

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.

Access and data from ownership
슬라이드 1 / 3Access and data from ownershipThe slide summarizes two proposed engineering advantages of working inside an acquired business.

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.

03

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.

Labor cost and revenue in services
슬라이드 2 / 3Labor cost and revenue in servicesA schematic shows why labor-intensive services can be difficult to scale.

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.

04

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.

05

Turning adoption into business impact

He explains the J-curve and the teams needed for deployment.

Selecting businesses
슬라이드 3 / 3Selecting businessesThe matrix illustrates a focus on strong business fundamentals and AI opportunity.

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.

같은 채널의 다른 글

슬라이드 9장21:32EN
AI Engineer· 2026년 10월 29일Shy Ruparel on AI agent reliability and recovery after failuresShy Ruparel · TemporalTemporal’s survey finds a gap between frequent agent use and dependable deployment. Ruparel demonstrates a synthetic payout workflow that resumes after workers stop.에이전트관측 가능성과 안정성에이전트 엔지니어링+2
슬라이드 7장14:50EN
AI Engineer· 2026년 10월 29일Cole Gannaway on code review, cross-repository risk and AI software factoriesCole Gannaway · QodoA one-line rename can pass local checks while affecting distant clients. Qodo’s Cole Gannaway explains how review context, shared rules and independent agents can expose those risks.Code review & verification코딩 에이전트개발 워크플로와 테스트+2
슬라이드 5장11:47EN
AI Engineer· 2026년 10월 29일Revolut’s David Abitbol on self-hosting AI coding models at scaleDavid Abitbol · RevolutAbitbol shares engineering delivery trends, GPU-serving costs and latency tuning, then describes controls for operating the tools in a regulated bank.Local inferenceAI cost & performanceDeveloper productivity+2
슬라이드 4장21:47EN
AI Engineer· 2026년 10월 28일Patrick Smyth on Open-Source Supply Chain Security in the AI EraPatrick Smyth · ChainguardChainguard’s Patrick Smyth discusses faster exploitation, malware in dependencies, zero-days and the expanding attack surface around developer workflows.CybersecurityOpen-source ecosystemsAI security+2
슬라이드 5장14:09EN
AI Engineer· 2026년 10월 28일Taylor Luttrell-Williams on Finding Logic Vulnerabilities with SonarQube Hunter AgentTaylor Luttrell-Williams · SonarSonar’s Taylor Luttrell-Williams explains how a security agent maps a codebase, investigates logic flaws and presents validated findings alongside conventional scans.CybersecurityAI securityCode review & verification+2
슬라이드 5장16:29EN
AI Engineer· 2026년 10월 28일Chris Vela on Benchmarking vLLM Configurations with Runpod BenchPodChris Vela · RunpodRunpod’s Chris Vela demonstrates a dashboard for comparing LLM serving configurations and choosing performance settings with workload-specific data.InferenceBenchmarksAI cost & performance+2