How we built the AI operating system for our VC fund, and how it works

Most of what we publish at Heal looks outward: companies, markets, regulation, the occasional AI announcement of questionable credibility. Today, we do the opposite: We openly share our internal AI stack and where we stand.

Why? When it comes to AI adoption, we’re all on a journey. Speaking with others and exchanging learnings has helped us massively as a fund over the past years. We’ve had hundreds of conversations with other VCs and AI-pilled founders.

Hence, we decided to make that conversation public, so everyone can learn. Two objectives:

1. To share what we have actually built, in enough detail to be useful to you rather than promotional (no “just hand your entire fund to openclaw” nonsense). Great if we inspire/help others

2. To be challenged! If you are doing this better, have taken a different approach, or see risks, we want to hear it

What follows is the story of how we moved from a question we could not answer to an internal system used across the fund. It explains the choices we made, the experiments that did not stick and the setup we use today.

To tell you the full story, I’ve teamed up with my colleague Felix, who’s been at the core of our AI initiative from the start. Since Arda joined, the two of them have been building HealOS together. The following are Felix’s words, with my amateur remarks added as quotes in between:

It started with a fairly normal request. Someone on the team asked me to look across the care-at-home companies we had seen at seed and Series A, identify the business models that kept recurring, compare their traction and understand aspects like why we had passed on the ones we did not pursue.

It sounded straightforward. Instead, I ended up exporting a CSV, searching across company names, descriptions and notes, and piecing together an answer that still felt incomplete.

The problem was not a lack of information. We had years of company records, meeting notes, decks, funding details and reasons for passing. The information was there. We just could not use it reliably.

When I joined, we were on Affinity, and before that the fund had used Pipedrive, so the database already carried several generations of structures and habits. At one point, we had more than 120 fields. Some existed several times under slightly different names, some held the same information in different formats, and others had been introduced for one purpose, used briefly and quietly abandoned.

You are never quite sure which field is current, which one the team actually uses, or whether an empty value means “unknown”, “not applicable” or simply “nobody filled it in”.

So, mostly out of frustration, I ran a substantial cleanup: merged the duplicates, removed more than half the fields, and built a consistent taxonomy around five areas: identity, traction, fundraising, people and decisions. The intention was never for the team to fill all of this in manually. I wanted a healthtech-specific enrichment system that could read our existing notes and records, extract what it could with confidence and populate the fields automatically. The people fields remain the most subjective and are still a work in progress.

That forced a lot of thinking about definitions. Is a company primarily diagnostics or care delivery? When does something count as recurring revenue? These distinctions sound pedantic until you try to compare several thousand companies. If everyone interprets a field differently, it is not structured data. It is free text with a dropdown menu.

Building the taxonomy also clarified what is actually valuable in a fund’s own data. Crunchbase, Dealroom and the rest will happily tell you that a company raised five million from a certain group of investors. What they do not show are the rounds founders tried to raise and never closed. Inside a fund, you see both: the initial targets, the valuation expectations, the round that shrank and the reason a process stalled. That is a much richer view of the market, and almost all of it lived in thousands of individual notes.

Lucas’ Note: The lesson here? Clean data is the least glamorous part of this whole story, but it’s also the part everything else depends on. Note that we didn’t do it for the sake of a clean CRM - but rather to make years of deal flow comparable without reopening every company by hand

With a clearer data foundation, we were ready to start building on top of it. The obvious first step was to connect the CRM to Claude or ChatGPT. In practice, the model was only one part of the problem. A useful system also needed access to notes and other internal sources, a way to write information back, and responses fast enough to matter in the moment.

We built several things before finding what people actually returned to. The lesson was familiar from working with startups: a technically good product does not automatically become part of someone’s workflow.

Here is what happened:

1. We bolted point solutions onto our workflows. Didn’t work.
   Our first instinct was to build narrow tools: a vectorised search across meeting transcripts, weekly calendar reminders and a handful of small automations built with tools such as n8n, each aimed at one part of the investment process. Some were useful, but most stayed as point solutions. They solved one problem in one place, usually behind their own interface, and relied on people remembering that they existed. It was not wasted effort, but it taught an old lesson worth repeating now that software is so easy to build: a tool producing a good answer is not the same as a team coming back to it. If it needs another login, or depends on people remembering it exists, it dies

   

2. The breakthrough was a telegram bot that reads/writes to our CRM.
   The thing that truly landed was almost embarrassingly simple. Once we had a flexible, queryable copy of the CRM, we connected an early agent to Telegram. You could look up a company, pull its previous notes, ask why we had passed, or write something back into the CRM, all conversationally, and it got real usage almost immediately. VC work does not happen in front of a CRM. Somebody mentions a startup at lunch, at a conference, or between meetings, and you want to know whether anyone at the fund has seen it before. Previously that meant opening the Affinity app and digging around. With the bot you asked the question the way you would ask a colleague. The data, the interface and the moment of use finally lined up

3. From there, we moved from a bot to an operating system. The bot proved that conversational access could work, but it also exposed a bigger issue: every new use case was starting to bring its own logic, data and interface. Arda joined around that time, and the two of us spent a lot of time working out where the boundaries should sit. What should the CRM remain responsible for? What needed to live outside it? And which capabilities, such as identity, context, permissions and memory, should be shared across every workflow? That led us to a different setup. The CRM would remain the system of record, but it would no longer have to be the whole application layer. HealOS would sit around it, connect the other systems we use and carry context from one workflow to the next. Instead of building a separate tool for every new use case, we could extend the same underlying system.

Bottom line? Every fund these days will need to decide how much control they want. I know multiple funds that simply center their AI stack around a modern CRM (mostly Attio) and Claude Cowork. Attio holds the data and Claude is the application layer. Add a few connectors (email, calendar, sourcing tool, …) and you can get very far that way! It’s certainly a bullet proof solution. But there are also limits: Claude Code/Cowork still doesn’t have a great memory or context solution, Attio’s API can be limited and the setup overall is slow.

The idea behind HealOS is straightforward: one internal system rather than a growing collection of small products, with our CRM, notes, documents, email, calendars and workflows operating from the same context.

This wide access to tools is what makes it powerful beyond a simple Claude or ChatGPT instance - some examples:

• After startup calls, the meeting notes are matched to the company in the CRM. The enrichment system then uses that information to update the relevant taxonomy fields. It for examples labels deals that are relevant for certain LPs

• The agent can not only analyze, but also act. It can draft one-pagers or memos in our standard format using CRM notes and documents from OneDrive. That’s convenient (no file upload required), and excellent quality

• It can work through pending emails and prepare replies, or process an inbound email with a PDF of startups to identify which companies we already know

• You could even ask it to clear your calendar on a Friday morning, by replying to all meetings with alternative time slots

There are countless more use cases. Instead of listing them all, I’ll walk you through the main design and architecture choices we made, and the components behind them:

The same assistant is available through the web app, Telegram and Teams. It feels like a traditional LLM chatbox, but has all the tool access mentioned above and some company-specific knowledge and guardrails baked in. It’s powerful, but sensitive actions (sending an email, deleting a company record, …) still require approval.

In terms of routing, we use a fast generalist agent to handle straightforward requests. More involved work is passed to focused agents with smarter models for research, meeting preparation or pipeline tasks. Multiple agents can run in parallel. So our team interacts with one assistant, while the work is divided in the background.

Notes. Meeting notes automatically appear in the OS and are matched to the relevant company. They can be reviewed before being added to the CRM.

Insights & Funnel. The reporting layer analyses our full pipeline history, including conversion, deal velocity, bottlenecks, valuation expectations, traction and reasons for passing. Because the data is structured, we can examine narrow cohorts. For example, something like “pre-seed and seed cardiology focused companies in the UK and France”.

Portfolio support. Our portfolio view is meant to do more than track ownership and marks. For each company, we bring together its full fundraising history, including rounds before Heal invested, the terms and co-investors involved, our ownership, previous notes, relevant documents and current plans. That gives everyone at Heal the same visibility, rather than leaving most of the context with the original deal team.

This becomes particularly useful when a company is preparing its next round. Alongside the portfolio data, we maintain a structured network of more than 300 funds, covering their geography, sector/stage/geo preferences, cheque sizes, fund history and the people we know there. We can match a company and its target round against that network, identify the most relevant investors and see who at Heal has the strongest route to each one.

Heal Call. Call scheduling sits inside the same system, so the agent can compare calendars across the team and find times that work for an IC, founder call or internal discussion. It’s essentially our Calendly clone.

Similar to Claude’s scheduled tasks, we have recurring workflows to handle things such as weekly pipeline summaries, meeting preparation and scans for deals that have gone stale. Every team member can pick from templates but can of course always individualize their workflows. Just ask the agent to do it.

Funnel management is one of my favourite use cases btw! I now have a very smart agent that supervises my early deal funnel. It flags which inbound emails I forgot to add to the CRM, reminds me of conversations I need to close, and responds on my behalf. One voice note to the agent in Telegram can simultaneously trigger an email to the founder, a note in the CRM, and an updated deal status. One interface instead of three, and less mental load - feels like speaking with a colleague.

Long-term memory preserves useful context across conversations, including relationships and previous discussions. The enrichment engine is deliberately conservative: it leaves fields blank when the evidence is weak and protects manual edits from being overwritten.

The most useful change is that information created in one workflow becomes useful in the next. A meeting can improve a company record, which can improve future research, reporting and the support we provide to that company.

Investment firms naturally organise around individual deal owners, and much of what the firm knows stays with the individual. HealOS does not replace good notes or conversations between colleagues, but it makes that knowledge easier for the whole team to find and use.

Thanks Felix! And back to me, Lucas, with an important context question:

Instead of all this “boring” admin work, you might expect us to work on AI that screens every pitch deck and decides which companies we should pursue. That is deliberately not what we are building today. We think about that path in two stages:

1. Removing admin & gathering data. At the moment, we want the AI to take over everything that keeps us from the decisions that matter. We think our current setup realistically frees up several hours per person per week. It mirrors what is happening in law and healthcare: the biggest current use of AI is not autonomous decision-making at the moment, it is shifting human time toward the parts that need judgement

   

2. AI decision-making. Do we think autonomous decision-making is coming? Yes, absolutely. But it requires enormous datasets, which mostly do not exist yet. Especially in our vertical, healthtech, we do not have sufficient data yet to find reliable predictors of success. And nobody wants to miss a unicorn just because an AI bot dismissed their pitch deck. We don’t want a “you’re completely right, this was a potential 5x fund returner”-moment. The opportunity costs are prohibitive. Sure, some funds are testing such automated strategies, and we respect it. But we chose to do our homework on the admin and workflow layer first. And the beautiful part is, the admin tools we run today build that dataset for us! They label companies, enrich records, and capture what we decide in dealflow meetings

In a few years, we should have a truly continuous record of how and why we made our decisions. Much deeper than any traditoinal CRM. We are moving towards a “world model” of Heal Capital. It will likely start by outsourcing lower-risk decisions and will grow from there.

We live in amazing times, and I love how AI frees up time for tasks that actually create value. Investment memos written in minutes, emails automatically triaged, company-wide knowledge easily accessible… all this frees up capacity for the important things: speaking with founders and posting memes.

And now? Let us know which element of our stack we should deep dive into! We are also very happy to compare notes with other people building AI systems inside funds, especially where you have taken a different approach or found failure modes we have missed.

Speak soon,
Felix & Lucas