Unify your data, unleash your firm's AI

Deal Engine has appointed Michael Santos to its board of directors. Santos joins at a moment when private capital firms are shifting from broad AI experimentation toward platforms built to handle production-grade workflows. His background sits squarely in that shift. A career across the private capital technology stack Michael currently serves as Global Head of Sales at Chronograph, a leader in portfolio monitoring and investment data. Before that, he spent ten years at DealCloud and Intapp, scaling the business internationally across front-office deal management and CRM. Earlier in his career, he worked with iLEVEL in portfolio monitoring and Investran in back-office fund accounting, both now part of larger platforms. That arc means Michael has operated across the full private capital technology stack, front, middle and back office, with direct experience in how firms buy, implement and get value from each layer. Why he joined “I'm delighted to welcome Michael Santos to the board at Deal Engine. He brings a wealth of knowledge of Private Markets and strategic technology adoption. As firms look to gain competitive advantage through AI, the need for robust market data foundations are more important than ever. Deal Engine’s unique Intelligence Warehouse is now being selected as the strategic architecture by a host of leading PE and IB firms. Michael brings the expertise and senior relationships to help firms make the right technology decisions to stay ahead of the market.” Phil Westcott, Founder CEO Michael was drawn to the specific problem Deal Engine is built to solve: critical information locked inside documents, spreadsheets and disconnected workflows that never becomes usable data. "I joined the Deal Engine board because the company is solving a fundamental problem in private markets: turning complex, unstructured information into reliable, actionable data," said Michael. "Many firms believe they can build AI solutions internally, and getting to a proof of concept is deceptively easy. Getting to a secure, scalable, auditable production environment is a different problem entirely. As AI moves from experimentation into high-volume production workflows, token economics become a real operational challenge. Inefficient model routing, redundant calls, and uncontrolled cost-per-query add up fast, and most firms don't see the burden until they're already scaling. Successful platforms need to deliver the right intelligence while managing token consumption, routing work to the right model at the right cost, and maintaining trust in every output. Deal Engine has built a truly unique intelligence warehouse product with real rigor around accuracy, efficiency and trust, which is exactly what the market demands. I'm looking forward to helping the business scale." Where he will focus Michael will work with the team to sharpen go-to-market strategy, identify the highest-value use cases by buyer persona, and build a commercial narrative connecting Deal Engine's capabilities to measurable client outcomes. He also brings a clear read on where the market is heading. Many firms are experimenting with building AI solutions in-house, and reaching a proof of concept is often deceptively easy. Reaching a secure, scalable, auditable production environment is a different problem, and it's one Deal Engine is built to solve. See how Deal Engine works →

Origination is still, for most banks, a manual exercise. An analyst builds a target or buyer list from memory, from a database search, from whatever the senior banker recalls about who was active in a sector eighteen months ago. It works, until it doesn't. The list that gets built is the list the team had time to build, not the list the market actually contains.

Researched and written by Deal Engine R&D Engineer, Amir Ishmuhametov. We recently published a whitepaper on scaling AI in PE and M&A. One of the sections that has generated the most reaction is not the architecture framework or the operating model. It is the cost page. Not because the numbers are shocking, but because they are recognisable. One figure doing the rounds at the moment captures it well: a single person, at a single firm, running £280 in Claude costs in one day. Not a fund. Not a team. One person. It is an extreme example, but the pattern behind it is not unusual. Firms are starting to see their Claude spend climb in ways that are hard to explain and harder to attribute. The usage is real, the outputs are useful, but the bill does not quite match the value. In our whitepaper we set out the structural reasons this happens and what the right architecture looks like to fix it. This post pulls out the most common causes we see: the patterns that drive AI costs up quietly, and what each one tells you about what is missing behind your team's AI usage. If any of these sound familiar, the whitepaper goes deeper: How to scale AI in PE and M&A The problem is rarely the model. It is how the model is being used. 1. The same work is being done across your team, repeatedly Claude has no visibility into what a colleague looked at yesterday, what another analyst concluded last month, or what your firm as a whole already knows about a company. When five analysts run similar queries, screening companies in the same sector, pulling updates on pipeline businesses, prepping for the same conference, each one starts from their own personal context, not the firm's. The model does not know the work has been done before. It cannot. There is nowhere for that work to live across the team. So it rebuilds, pulls from your CRM, checks recent news, cross-references public data, and your firm pays for research it has already paid for. Token costs multiply not because individual usage is inefficient, but because there is no shared layer capturing and structuring what the model produces across the team. Every good output disappears at the end of the session that produced it. For a team of five running similar queries daily, that is not a marginal inefficiency. It is a structural one. 2. Every session spends money before it does anything useful That disappearing output creates a second problem. Because nothing is retained at a firm level, every new session has to gather context from scratch before it can begin. Claude pulls from the CRM, retrieves relevant documents, checks data sources, and assembles a picture of the company or market in question. That process costs tokens before a single useful output is generated. The difference is measurable. A session that starts with pre-built, structured context uses around 8,000 tokens to complete a typical triage workflow. The same session starting from scratch, pulling from multiple data sources in real time, uses closer to 40,000. That is an 80% reduction in token volume, purely from having the context ready before the session begins rather than assembling it during. Without that, every session pays a cold start tax. Multiplied across a team, across a year, it adds up to a significant and entirely avoidable cost. 3. One expensive model is doing everything The cold start problem is compounded by something else: most firms are running all of their AI usage through a single frontier model, regardless of what the task actually requires. Claude is handling investment memos and CRM field updates. It is generating nuanced thesis assessments and formatting Slack messages. It is doing the analytical heavy lifting and the administrative grunt work, at exactly the same cost per token. Not every task needs a frontier model. Routine screening, data extraction, structured formatting, and entity matching can all be handled by cheaper models at a fraction of the cost. But without a system that routes tasks to the right model, everything defaults to the most capable and most expensive option available. The output quality is often no better. The cost is significantly higher. When you combine pre-built context with deliberate model routing, routing cheaper models for volume work and reserving frontier models for reasoning and synthesis, the overall cost reduction reaches around 92%. That is the number behind the title of this post. It is not a token count comparison. It is what the full picture looks like when the architecture is working properly. 4. There is no visibility into what is driving spend These first three issues share something in common: they are largely invisible. There is no attribution, no audit trail, no way to know whether costs are being driven by one analyst running expensive queries, a workflow that has grown inefficient over time, or a structural pattern across the whole team. This is what makes the £280 figure so useful as a diagnostic. It is not just a striking number. It is what unattributed, unstructured AI usage looks like at its logical conclusion. Most firms will not hit that in a single day. But the conditions that produce it, no visibility, no governance, no shared structure, are present in almost every firm using AI at scale today. Without visibility, there is no way to manage it. Costs accumulate with no clear owner and no obvious lever to pull. By the time the bill becomes a problem, the usage patterns driving it are already embedded in how the team works. 5. You are paying Claude to forget The invisibility in point four makes the underlying problem harder to see, but it does not change what is happening. Every datapoint the model touches costs something. Every company profile it builds, every news summary it generates, every screening assessment it produces. If none of that is captured, structured, and stored somewhere the team can access, the next interaction starts from nothing and the cost clock starts again. This is the compounding version of points one and two. Over time, the gap between a firm whose AI usage builds on itself and one whose usage resets with every session is not just architectural. It is financial. One firm pays for research once and reuses it indefinitely. The other pays again every time. The savings from points two and three do not just apply to a single session. They apply to every session, every day, for every analyst on the team. The model is not the problem. The absence of anywhere for its outputs to go is. What this means in practice Taken together, these five patterns describe the same underlying issue: AI being used as a session-by-session tool rather than a system that accumulates value over time. The costs are real, but they are a symptom. The cause is structural. None of this requires switching models or rebuilding workflows from scratch. It requires thinking about what sits behind the model: how outputs are captured, how context is shared, how tasks are routed, and how usage is governed. These are engineering and architecture decisions, and they have a direct and measurable impact on cost. Our whitepaper sets out what that architecture looks like in practice, with real numbers from live workflows. Download the whitepaper