Pick one team, a few real workflows and a fixed window, usually four to six weeks. Connect AI to the firm's actual data, codify the prompts that work into shared skills or workflows, and make each one feed a common context so the next one gets easier. Measure hours saved and outputs used, then expand.
I hear a version of the same thing from platform and ops leads every week. Everyone at the firm uses AI, and nobody can say what it's done for the firm. An associate has a great diligence prompt. A partner keeps one chat thread going for LP emails. None of it is shared. And when the associate leaves, the prompt leaves too.
A sprint is how you turn that scattered use into something the firm owns. Platform or ops usually runs it, because they sit across every team and they feel the repeat work most. It doesn't need a consultant or a big budget. It needs a narrow scope, a few weeks and a clear order of operations.
Before the sprint: pick the team, the workflows and the owner
Keep the scope small enough to finish. One team, three to five workflows, one owner and one partner who cares about the result. The partner matters more than people expect, because a sprint without a sponsor gets bumped by the first busy week.
To choose workflows, ask four questions of each candidate:
- Does it repeat? Weekly is better than quarterly.
- Does it run on data we already have? If the inputs don't exist yet, it's not a sprint workflow.
- Can a person check the output fast? Five minutes of review is fine. An hour isn't.
- Does someone actually want it? A workflow nobody asked for won't get used.
Here's an illustrative shortlist for a platform and ops team:
- A one-page brief on a portfolio company before any partner or founder call.
- A weekly digest of portfolio news and signals.
- A first draft of the monthly portfolio newsletter.
- Draft intro emails for requests from founders, for a person to edit and send.
- A first draft of the portfolio section of the quarterly LP update.
Notice that nothing on that list sends anything on its own. Every workflow ends in a draft and a person. That's the rule for a first sprint, and for most work after it.
A six-week plan
| Week | Focus | What you produce |
|---|---|---|
| 1 | Baseline | Time spent on each workflow today, and where its inputs live |
| 2 | Connect | AI hooked up to those sources, with answers that cite where they came from |
| 3 | Codify | A written skill for each workflow that worked |
| 4 | Codify | Other people run the skills, and the owner fixes what breaks |
| 5 | Compound | Each workflow writes its output back to shared context |
| 6 | Measure | Hours saved, use by people other than the owner, a keep/fix/kill call |
Week 1 is the one people skip. Without a baseline you can't say what changed, and a sprint you can't measure turns into a story about how people felt.
Connect: put AI on the firm's real data
Most firms start with a chat window and whatever someone pastes into it. That gets you a nice demo. It doesn't get you a workflow, because the output is only as good as the context, and pasted context is partial and stale by next week.
Connecting means the AI can read the actual sources: the CRM, email, calendar, meeting notes, board decks and portfolio metrics. Public context helps too, like news, LinkedIn and X. If half of that is missing, every answer on top misses things too.
Two cautions. A context window isn't a database, so you can't throw years of portfolio data into one chat and expect reliable answers. You need a system of record underneath. And every answer should show where it came from. When a brief says a company's revenue grew, a person should be able to click through to the board deck it came from. That's how trust builds over the sprint. If you want the longer argument for fixing data before building agents, it's in what an agentic VC fund looks like.
This is the part Cura handles for portfolio data. Its MCP server lets Claude or ChatGPT query portfolio metrics, updates and signals directly, with each number linked to its source, so nobody has to paste anything in.
Codify: turn a good prompt into a shared skill
A good prompt in one person's chat history is a private trick. A codified skill is something anyone on the team can run and get the same quality. The difference is mostly writing things down.
A skill should cover:
- Name and trigger. "Company brief: run before any call with a portfolio founder."
- Inputs. The company name, plus anything the person knows that the data doesn't.
- Sources. Which systems it reads, in what order.
- Steps. What it looks for and how it decides what matters.
- Output format. Length, sections and tone, with one example of a good output.
- Review rule. Who checks it, and what they check for.
We learned this one the hard way at Cura. We built a feature into the product that almost nobody used. It turned out customers had already written their own Claude skills on top of our data through the MCP server, and they liked those better because they'd shaped them themselves. So now I'd rather give a team good data and a skill template than another button.
Compound: make each workflow feed the next
Here's where a sprint stops being a set of tricks. Each workflow should leave something behind in the shared context.
Some examples of the chain:
- Company brief → call notes saved against the company → a better brief next time.
- Intro draft → the sent intro logged from the email thread → a two-week follow-up → a value-add log that fills itself.
- Weekly signal digest → a founder ask spotted and routed → the outcome recorded against that company.
If a workflow's output only lives in someone's inbox, it doesn't compound. Ask of each one: where does the result go, and who benefits next time?
Measure the sprint, then decide
At the end of week 6, score each workflow on a few numbers:
- Hours saved per month, against the week-1 baseline.
- People using it besides the owner.
- Edit rate: how much a person changed the draft before using it.
- Errors caught in review, and whether they're shrinking.
Then make a call for each one: keep, fix or kill. Killing a workflow is a fine result. It means you learned cheaply. Take the keepers to the next team, and start the next sprint with a context layer that already has six weeks of work in it.
What does “connect, codify, compound” mean for AI at a VC firm?
It's a three-step order for AI work. Connect means hooking AI up to the firm's real data, not pasted snippets. Codify means turning a prompt that works into a shared skill or workflow anyone can run. Compound means each workflow writes its results back into shared context, so every later workflow starts with more to go on.
The order matters because each step depends on the one before. Codify a prompt that runs on pasted data, and you've shared a fragile thing. Try to compound without codified skills, and nobody knows where outputs should go. Most firms I talk to are somewhere in step one, and that's fine. Step one done properly makes the other two much easier.
Why do individual AI experiments fail to spread across a firm?
They live in one person's chat history, run on data only that person pasted in, and have no owner once the champion gets busy or leaves. Colleagues can't see them, can't trust the output and can't reuse them. The blockers are mostly trust and habit, not technology, so the fix is shared skills on shared data.
The trust part is real. A partner who once got a confident wrong number from a chatbot will hesitate to rely on anyone's AI output, and sources on every answer are what win them back. Privacy matters too. Some GPs won't allow note-takers in certain meetings, and a sprint should respect that and write down what data the AI can and can't touch.
The habit part is simpler. People reuse what they can see. A ten-minute demo at the partner meeting, a shared folder of skills and one person who answers "how do I run this?" questions will do more for adoption than any memo about AI strategy.