Patrick Coggins

Since July, our team has had more than 100 calls about AI implementation with CEOs, CFOs, CTOs and PE operating partners. These 12 questions came up most often: 1. “Where do we start?” Where your customer would feel it first. Pick one workflow, run it for a month, then decide what comes next. Start with a long list of ideas and you’ll end up shipping none of them. 2. “Can’t we just build this ourselves with Claude?” For a lot of it, yes. Reports, research, content: get your people using agents every day. You don’t need a firm for that. You need one when the work touches a system of record, patient data or payment data, or when it has to run every day without somebody babysitting it. 3. “How do we measure ROI?” Name the number before you build: days to close, denial rate, hours per onboarding. If nobody can name it, you’re buying a demo. 4. “How do we know the AI is right?” You test it. Build a golden set of answers your business agrees are correct, then score every release against it. Anything below the bar goes to a person. 5. “Who owns it, and who keeps it running?” You do. Your cloud, your repo, your accounts. Before kickoff, name the person on your side who will run it. Make your first AI hire somebody who can operate it and keep it healthy. 6. “Is our data safe?” It should stay in your environment. Ask where it goes, who at the vendor can see it and what the model provider keeps. Expect a plain answer to all three. 7. “Do we have to fix our data first?” Only the data your first workflow touches. Then build in order: a simple pipeline that runs every day, a layer that defines what your numbers mean, and then the agent. One prompt can’t do all three. 8. “What happens to our people?” Start with them. You can’t expect agents to work on top of a team that doesn’t use them. 9. “Which model should we use?” It matters less than you think, and you’ll change it. Pick a setup that lets you switch. Your workflows, evals and data are what you keep. 10. “What will it cost to run?” Get it in writing before the build: tokens, hosting and licences, with costs broken down per month and per transaction. 11. “Do we pay for time or for outcomes?” Either works as long as you can walk away. Work month-to-month, with no lock-in and a checkpoint after the first month. 12. “How do we tell a real AI partner from one that started last year?” Before you sign, ask to see something they built that’s running in production for another customer today. Then call that customer. After you sign, give them one team for a month. If nothing changed, throw them out. The question I’d add to the list: what happens if it works? Who runs it, who improves it, and what does your team do with the time it gives back? Ask it before you start.

Before you pay a premium for an AI company, check what it actually owns. A PE firm asked us to look at an acquisition before close. The company had $4.2M ARR, growing 40% year over year, and wanted 12x revenue. Management had 14 slides explaining its “foundational model architecture.” We opened the codebase. GPT-4o, a system prompt, a React frontend and roughly 600 lines connecting them. The proprietary model described in the deck wasn't there. The buyer walked. A company built on OpenAI can still be a valuable business. Customers, distribution, data and software embedded in daily operations all matter. But you need to know which of those you're paying for. In my view, AI diligence needs to answer four questions before close: [1] Model dependency. If OpenAI, Anthropic or Google changes pricing or retires a model, what happens to the product's quality and margins? How much work would it take to move? Ask the team to demonstrate an alternative against the same customer tasks and quality checks. Being able to switch models is a strength. The next question is what customers would still pay this company for if every competitor had access to the same model. That might be years of integration work, a useful dataset or a workflow customers depend on. Get specific. [2] Training data liability. “Proprietary data” needs more explanation than a line in the deck. Where did it come from? What do the licenses and customer agreements allow? Is it used for training, fine-tuning or retrieving information when someone asks a question? These are different uses. Permission for one doesn't automatically cover the others. Have those rights checked against what the product actually does and what you intend to do with it after the acquisition. [3] Talent concentration. Headcount tells you very little about this. Ask someone other than the original builder to deploy the product, investigate a failed run and explain how they test a change before it reaches customers. If every answer requires the same person, you need to understand that dependency before close. Documentation, shared access and a second engineer who can run the system are basic hygiene. Put the work to close those gaps into the acquisition plan. [4] Integration failure rates. A product working for its existing customers doesn't establish what it will take to work inside your portfolio companies. They have different systems, data, permissions and people responsible for approving actions. Pick one intended workflow. Have engineers inspect the systems it needs to connect to, identify the changes and estimate the work. Name the person who will own it and define the outcome you expect. Do that before counting the savings. The financial model can show you ARR, growth and expected synergies. Someone still needs to check the assumptions against the software. Get engineers with hands on the keyboard into the engagement during exclusivity. By close, you should know what you own, what you depend on and what it will cost to deliver the outcomes in the investment case.

PE operating partners often ask me how to introduce an AI partner to a portfolio company. The least useful introduction is a vague one: "Meet Limestone, they do AI." The CEO takes the call, everyone agrees AI matters, and two weeks later the interest has faded. Portfolio companies are busy. AI gets attention when someone connects it to a specific problem worth solving. A menu of services won't do that for you. The operating partner's useful contribution is helping the company identify where to look. Here's the sequence that works: 1. Pick one portfolio company. 2. Name one problem: call-to-cash at an industrial company, billing at a healthcare company, or reorders that customers still have to phone in. 3. We scope it for free. 4. We ship it. If we don't deliver, they don't pay. 5. Make the next introduction with a result attached. Before the first build, I'd want three things made explicit: > Process owner: who can show us how the work happens and make decisions when it needs to change? > Baseline: how long does it take today, how often does it go wrong, and how much human effort does it require? > Acceptance criteria: what observable result will count as delivery? Without those, even a technically impressive pilot can leave everyone arguing about whether it helped. My first filter is the customer touchpoint. Will this make onboarding faster, get an answer to a customer sooner, or remove a delay they keep chasing? That gives the business a reason to participate. It also gives the operating partner something concrete to discuss with the next company. Our best introductions have started with a nudge: look here, this is where it hurts. A CEO who knows the roadmap is stuck gives us somewhere to start. You can assess repeatability across the portfolio once the first workflow works. A shared problem doesn't mean every company has the same systems, permissions or exceptions. If you're introducing vendors across a portfolio, a one-line description of the problem is worth more than the warm introduction.