What your strategy doc doesn’t know

In an earlier post, we bootstrapped judgment by creating a project with your strategy docs. That was a great starting point, but it relies on you having a strategy doc and keeping that doc updated. It’s also aspirational. It reflects what you think you’re after, but it doesn’t necessarily reflect how and why you make actual day-to-day decisions. This is the kind of stuff new hires learn by watching, and it’s much the same for models. You need to give them your decided deal history. That history holds the rules nobody wrote down (the patterns and heuristics). Once the model starts to learn those, you’re able to offload more and more of the initial work because you’ll get more and more confident in its judgment and its ability to make similar decisions to you.

A quick example. We’re not really interested in IP-only deals. We need someone to actually run the acquired business, not just hand us a pile of code. So if a founder came to us with the perfect tech fit, but was like “I’m not coming with it, I’m retiring,” we’re almost definitely a pass. That’s not codified anywhere in our strategy docs, but it is the kind of thing that can be learned by reading through our deal history or watching it over time. This is the kind of judgment I want the model to develop.

Have the model write your rules

The interesting thing about rules like this is that they’ve probably never been written down. In fact, if given a pen and paper and told to write down all your rules of thumb, you’d probably miss a ton. Don’t waste time doing that. Have the model derive them. You’ll probably even learn things about your decision-making that you didn’t even consciously realize.

I’ve been using Claude and ChatGPT to help me review deals for years, so I’ve trained them slowly over hundreds of decisions. We’re going to jumpstart that in an afternoon. To begin, you need to assemble a package of your past deal history. You want to assemble every CRM deal note, weekly/monthly exec update, Slack message with a decision, and past discussion with the AI on an opportunity where you made a decision. This is going to be much much easier if you’ve connected your model to your tools1, but you can do this by hand too if you have to.2

I’m also guessing that some of you don’t have this pile. Maybe you don’t maintain a CRM or write a weekly update memorializing your decisions. My guess is there is still some level of digital record buried in your emails, messages, docs, decks, files saved to your drive, etc. As long as you have some level of digital breadcrumbs, I’m pretty confident that today’s models can assemble a ruleset for you. It might be a bit messier or take more time to crawl over everything, but if you give your model a data dump of whatever you’ve got, that’s probably good enough.

Once you’ve got that pile, throw it into chat or a project.3 Tell the AI to review everything and build a decision log with at least three things on every row: the call, the one-line rationale, and how far it got (passed on paper, took the call, went deep, etc.). Don’t forget to include the deals you actually did, all of them. The yes side is going to be tiny, but it’s by far the most important signal. The model needs to try to figure out what was different about that small cohort that got those opportunities successfully through the gauntlet. Related, you should even tell the model that (“99% of inbounds are passes”) and ask for ranking rules and take-the-call triggers, not solely yes/no classifiers, or else you’re going to end up with a model that only says no.

Example Prompt

Attached is my deal history: a decision log of every decided opportunity, my running feedback on past screening verdicts, and our acquisition strategy. Write my operating rulebook: the decision rules, guardrails, and anti-criteria you actually observe in how we decide, not what the strategy doc aspires to. Back every rule with at least two examples from the log. Call out the rules that appear nowhere in the strategy doc, and any place my recorded behavior contradicts it. Roughly 99% of our inbounds end in a pass, so do not give me a yes/no classifier: write ranking rules and take-the-call triggers that describe what the rare yes looks like. Number every rule and mark the ones inferred from thin evidence as tentative.

The rulebook

What comes back is a summary of how you actually do deals based on real-world decisions, not aspirational strategy targets.4

For this post, I didn’t try to assemble a fake history. I had Claude pull my Airtable CRM and my weekly updates, write the multiyear history, and then extract my latest rules.

It surfaced 52 rules:

• 17 patterns that I follow

• 11 rules that don’t appear in my strategy docs

• 6 places where my behavior conflicts with what the strategy doc says5

• 9 triggers to at least take a call

• 9 anti-criteria that I reliably pass on

A few of the interesting ones: I would have told you once I pass on a company, I’m done with it, but apparently, I revisit old opportunities often enough that it wrote a rule that a pass isn’t a death sentence (#1). Second, I like the note about GitHub stars being a talent signal more than an acquisition signal (#7). That feels pretty accurate. Stars tell you a lot about code quality and whether you should use the code, much less about how the underlying business is doing. Finally, I’m continually shocked by how many companies claim they’ve got a strong integration with Zapier when they don’t (#3). I’m obviously going to check our data. How do they not realize that?

These are just an excerpt, though. By far the best rules are the ones I can’t print that lay out our acquisition strategy, probably better than any single doc I write could. This is how you give it your judgment.

Testing the rulebook

I also used this as an opportunity to test the derived rulebook.6 I held back ten decided deals from my training corpus. The held back deals represented a range of outcomes (acquired by others, dead, engaged-then-walked, etc.).7 I then had the model reconstruct decision packages based on what we knew at decision time. I ran those packages individually through the Claude API (to keep my own system context out of the test) with the new rulebook to see how it would do.8

It wasn’t perfect, but it was close. The model matched every one of my passes and flagged the giant I never approached as a watch (it was too big for us, but worth monitoring, so this was the right rec). It also rightly recommended that I pursue the one deal in the set where I actually took the call, but warned that this exact profile “gets bought out from under a slow process”, which is what happened (but by someone else after we dropped out). Row 6 wobbled across runs, which is always interesting, and why you still need to keep an eye on the decisions. Finally, Row 4 was its biggest miss, but it’s an honest miss, and probably an unfair test on my part (it’s a company that was definitely a pass, but one that I wanted to track the outcome of - I probably need a rule like “Austin likes watching for the outcome of some of the deals he passes on”).

Going forward

Once you have the rulebook, start running every opportunity through it. Have it keep track of every decision you make and whether it was wrong, you were wrong, or if it was a nuanced decision. Then, have it improve the rulebook based on each decision. The more decisions it sees, the better judgment it will have, just like training an employee. Over time, you’ll realize you’re trusting its judgment more and more.9 However, there are still some things to watch out for.

Where this fails

1. Yeses are too limited. Even the most active serial acquirer is going to have very few deals that make it all the way to an acquisition, but those deals are the ones driving the decisions. You need to make sure the model has enough signal to figure out why those deals made the cut, and it needs to weight those signals accordingly. It’s also what’s going to drive most of the misses. There will be some nuance that makes a deal a yes, that it just didn’t have enough context to figure out, and that’s why this is a continual learning process.

2. Hindsight bias. Your historical dataset is going to be littered with data on how a process played out, what happened to the company, what killed the deal you did take a call on, etc. This is going to bias the initial rulebook. That’s why this is just a way to get you past the cold start problem. It’s the ongoing learning where the model starts to earn its keep.

3. The sycophancy trap. Whatever you do, don’t give the model hints on how you’re going to decide on an opportunity before you get its opinion. The model is going to agree with you. Make it render its verdict independently first, or you’re never going to train it to think.

Try this (10 minutes)

If you want to do a quick test to see how this works, export your last ~20 decided deals with call + one-line rationale + how far it got. Add notes on a few deals you actually did. Drop the list into the triage project we made the other week with your strategy and ask for the rules it observes. Add those rules to the project and/or memory, then grab another few opportunities, run them, and see how it does. It should give you better results than just working from your strategy.

Then the habit that does the real calibrating (and is an ongoing process, not a 10-minute exercise): have it call every new inbound before you decide, have it keep score, and have it update its rules based on the new things it learns. You’ll have an analyst in no time.

Takeaways

• The default response is no. The model needs to figure out what makes something a yes, but most of those rules are never written down

• Decided deals are the best training set and will teach both you and the model things you might not even realize you do

• Your deal history gets you past the cold start problem, but ongoing training is how you actually make the model useful

What’s next

Now that we’ve got the model thinking like us, it’s time to get it writing like us.

Last week, I created a test designed to measure how an AI model evaluates a potential acquisition target. I initially intended to use the test to help me decide between Fable, Opus, and Sol, but after seeing the initial results, I expanded it to others, and in the end, shared results on a total of twenty different models. As part of that, I also shared all my receipts.1

That creates a problem. The answer key is now publicly available, and I know it sounds paranoid, but there’s literally nothing online that the labs don’t crawl for training data. Maybe they won’t find my test immediately, but give them six months, and I can nearly guarantee they will have ingested the answer key, and the models will be scoring perfect scores.2

So, I had to retire the original test and create a new one.3 The new test largely mirrors the original but uses a fresh fictional company in a different industry with a new set of flaws and a new collection of traps.

Then, since I had this new test, I had to rescore the full lineup. I started with three runs like the first test, but noticed Opus looked off (more on that below), ran just Opus another three times, and then decided to run all the models a total of six times each so that Opus wasn’t singled out.

New Test, New Results

After running the new test across the original slate of models, the top models remained pretty consistent. Seven models crossed 80 points, with Fable 5 remaining the most consistent top performer (although at double the cost).4 For those of you not looking to go bankrupt, Sol 5.6, Grok 4.6, and Muse Spark 1.2 were all basically right there, with Muse continuing to be the low-cost performer.5

Overall, most of the models tested moved two places or fewer. Some, like DeepSeek and GLM, did a bit better, but one materially changed. Opus 5 plummeted. What happened?

What Happened to Opus 5?

Before we get into what exactly happened to Opus 5, a quick reminder on the six components of the score:

1. Detection and Recall (35 pts) - How well does the model detect issues?

2. False-Positives (15 pts) - Does the model allege a problem that isn’t a real problem?

3. Severity Calibration (15 pts) - How well does the model weight the issues it identifies?

4. Citation Accuracy (15 pts) - Does the model correctly cite its sources?

5. Question Quality (10 pts) - Does the model suggest good follow-up questions?

6. Decision Quality (10 pts) - How solid is the model’s recommendation?

Opus 5 scored near the ceiling on detection (32.6/35), as is expected for a frontier model. It was also within 1.5 points of the leaders on severity, citations, and questions. Then, for some reason, it absolutely fell apart on the false positives. In total, it flagged false positives 11 times across its six runs (11 out of 30 possible encounters - 5 traps x 6 runs) and it even flagged some benign items, plummeting its score on this component to the bottom of the rankings.6 Opus 5 ultimately scored a 3.7/15 versus Fable’s 11.2/15.

The findings were so strange that I thought something had to be wrong. I went back and had Kimi review the false positives, and it upheld all of them and identified no defects. And, to be clear, I didn’t just have it review the Opus false positives, Kimi blindly reviewed all 139 false positives flagged across all the models (without knowing which model said what), and it upheld all of them. Opus wasn’t accidentally graded differently.

I then thought it must be an outlier and ran Opus three more times as mentioned above. That didn’t fix it. It was still hitting way more false positives than any other model. Then I thought maybe the other models got lucky and ran each of them another three times. But no, their scores also stayed in the same ballpark. It wasn’t just an unlucky run or two.

I couldn’t let it drop there. I started wondering if it was maybe something unique to Opus 5, so I gave Opus 4.8 a turn and ran it six times. And that’s where things really started to get interesting. Opus 4.8 definitely flagged more false positives than Fable or Sol, but it was in the ballpark, getting a 9.8/15 on the same traps. But then I wondered, maybe that was a lucky result too, and had Opus 4.8 run on the original test too. But no, this is a unique issue to Opus 5.

So then I wondered if I could fix it. First, I hypothesized that maybe I could prompt my way out of it by instructing it to only flag what it would stake the memo on. It helped on one run of three, getting the false positive score up a bit to 6.3, better than its average, but still well below most of the other models. I then hypothesized that maybe the model was overthinking and trying to find too many issues, and I dropped reasoning from max to high. This didn’t remotely help and led to it even scoring a straight zero false positive score on one of the runs!

Then I noticed Opus 4.8 was actually coming out more expensive than Opus 5, which sent me down my final rabbit hole. For some reason, in all my runs, Opus 4.8 was thinking much longer than Opus 5 (40.4k thinking tokens vs. 17.5k), but then Opus 5 was writing book-length answers 3x longer than Opus 4.8 (18.2k tokens on the answer vs 6.8k). I don’t know why it does this, which led me to my last test. Could I force it to think more? I ran three more tests with the added instructions for the model to work through its full verification before writing any findings. And it worked. Sort of. Thinking tokens jumped to 27-33k tokens, and 2 of the 3 runs scored ten or higher. But the third run still face-planted with a 3.0, which at this point, just seems appropriate.

So, I give up. Opus just doesn’t know what to do with this data room packet and flags everything as an issue.7 Something about this model just likes jumping to conclusions. Strangely, it didn’t do it on the first version of the test (it got a 10.0/15 on the first version, so I don’t want to extrapolate too far based solely on this), but something about my new test makes Opus fall into all of the traps. I’ve reviewed the test and the traps, and while I’m not going to share it8, I can assure you, there’s nothing uniquely tricky here (as evidenced by the other frontier models all scoring above 10, and even Opus 4.8 getting a 9.8).

What now?

I want to like Opus 5, but I can’t afford the wild goose chases it might send me on, especially in the middle of a deal. So, for now, I’m still going to stick to a mix of Fable 5 and Sol 5.6. However, I know that a lot of people don’t have access to Fable, and many might only have access to Anthropic models, so they can’t just opt for Sol. For those people, I’m tempted to recommend you use Sonnet 5 or fall back to Opus 4.8 and avoid Opus 5. Opus 4.8 and Sonnet both score higher overall, while Sonnet 5 costs much less, and, most importantly, won’t send you tilting at windmills. That being said, Sonnet’s decision quality scored poorly (5 of 6 runs scored 4/10 or less), so if you do fall back to Sonnet, you’re probably going to want to review (and rewrite) its recommendations.

For those of you with a bit more permissive security teams (and a bit more restrictive budgets), Grok 4.6 (or even Muse Spark 1.2) also still feel like pretty attractive alternatives worth considering.9

Method

I ran Grok 4.6 and Gemini 3.7 through the exact same test with the same rules as what I published last week.3 In short, this test is designed to mimic a real corp dev diligence workstream and tease out what model(s) are the best for corp dev work (see last week’s post for an extensive walkthrough of the methodology).

One other thing to flag, I ran both models through my tests before I published the full receipts, including the answer key, so these results should be clean. Future tests, though, I’m going to have to rely on a successor test I’m building that I’ll have to keep private so nothing accidentally ends up in a training set.

The Updated Leaderboard

Without further ado, the scores: Grok 4.6 scored an 83.9 (+16.9 from Grok 4.20, 86.3 excluding the flaws its model family authored) and Gemini 3.7 Flash scored an 82.2 (+2.9 from Gemini 3.6 Flash, 80.6 excluding the flaws its model family authored).4

Grok obviously had the biggest jump, but that’s probably because I ran the first test on Grok 4.20, a six-month-old model, but it was what was available via the Vercel AI Gateway. For this test, I went and created a direct API key and paid like 46 cents.5 What’s even more interesting is that Grok effectively tied Sol’s score (technically higher - 83.9 vs 83.5, but the 3-run ranges were effectively identical - 81.9-86.6 for Grok and 81.9-86.5 for Sol).

Gemini was more of an incremental improvement, going from 3.6 to 3.7. However, after a disappointing first showing, Gemini’s now at least cleared the 80-score hurdle with all three runs over 80 (80.9, 82.5, 83.1), establishing itself in the near-frontier category.

More promising, this latest batch now establishes Grok solidly in the frontier with Opus, Fable, and Sol on the detection and recall side of things, with Gemini joining Muse and Qwen right on the edge. As I said last week, we’re approaching the point where maybe we’ll be able to expect the models to just get the underlying analysis right. Where they’re going to need to differentiate themselves is going to be more and more on their ability to use good judgment and make and defend recommendations and decisions from their analysis.

So, Do I Switch?

Nope! I’m sticking with Fable and Sol for now. At least for us, Grok’s not an approved model (especially with me needing to hit it directly via my own personal API key). That means it goes in the same bucket as Muse - one to watch, but unusable for my purposes. Gemini is a bit more interesting as a potential future Sol alternative, but it’s still not quite there. So for now, nothing changes for me and what I recommend.

What’s Next

We’ve now got at least 4 models up in the Opus/Fable/Sol class (7 models scoring 80+ on my tests). GLM-5.3 seems like it could be #8. It’s going to be very interesting to see how Anthropic and OpenAI continue to separate themselves with the floor rising so quickly (Fable 5 originally came out on June 9 and Sol on July 9, and these other models are already nipping at their heels less than two months later).

My expectation is that harnesses and what you connect the model to and what context it ingests becomes the differentiator more and more than the model layer (which might be commoditizing, but who knows what’s on the horizon).

I’m looking forward to seeing what’s next!

My test2 was built to mimic a real corp dev deal diligence workflow end-to-end. It starts with a synthetic data room (CIM, board deck, P&L and ARR waterfall, cohort data, top-20 customer contracts, cap table, emails) littered with red flags and deal killers (IP issues, customer change-of-control rights, related-party revenue masquerading as ARR, etc.) as well as some yellow flags that look scary, but actually aren’t (a customer contract that looks like a change of control termination risk, a Q2 ARR dip that looks like churn but is just seasonality, etc.). The required output is an investment memo with a recommendation (proceed/reprice/walk), and the models have to explain and defend their recommendation. Additionally, if the recommendation is proceed or reprice, the models must recommend cures for the red flags (and explanations for the yellow), while if the recommendation is walk, the models need to explain why these issues are incurable.

All of this is graded against an answer key designed to answer two questions: 1) what model should corp dev teams be using right now, and 2) if a new model comes along, is it time to switch?

Method

I started my test with the three frontier models: Fable 5, Sol 5.6, and Opus 5. I used the raw vendor APIs for each (so no benefit of my harness and memory) and ran the test three times on each model.3 Each model (and each run) worked off the same 15 documents in the hypothetical data room with 16 planted flaws (red flags) and 6 clean traps (yellow flags that aren’t actual issues).4

Once each model completed its run over the data room, the outputs were anonymized (by Fable), then those anonymized results were graded by a 4-model panel (with one caveat, models from the same model families never grade their own). The scoring script was deterministic, and models had to hit certain beats with their answers, and at least 3 of the 4 graders needed to agree to drive the score.5

Scores were based on six factors:

1. Recall - How well does the model recall the facts as laid out in the data room?

2. False-Positives - Did the model flag any of the six traps (or worse, any of the ordinary content) as a real problem? This turned out to be one of the factors that separated the frontier models

3. Severity Calibration - Flaws had to be weighted appropriately. Tagging a formatting nit as a deal-breaker, or a deal-breaker as a nit, loses points

4. Citation Accuracy - Every claim has to cite the specific document it came from, and the citation has to actually support the claim

5. Question Quality - Each finding requires the model to suggest the next diligence questions you’d actually ask, with those questions graded on whether the question would actually resolve the issue

6. Decision Quality - How solid is the model’s recommendation? This was the biggest issue with the first run of the test and led to me doing a second run. The issue - v1 only gave credit to models that recommended walking after identifying the red flags. However, that isn’t realistic. Most of the red flags in our set are curable (either through closing conditions or price adjustments), so I reworked the rubric to have the graders assign a sliding score based on how the model addresses the issues. We locked these rules before the v2 runs and used the same packet, prompts, and scoring. With this change, a reprice recommendation earns credit by naming the specific cures for each deal-killer (e.g., get the IP assignment countersigned pre-close) while a walk earns credit only with the reasoning to back it (just saying walk doesn’t get a full score).

I ran this on Sol, Fable, and Opus, but then realized I should fill out the longer tail, so I added models from Google, Meta, the leading Chinese providers, and even Mistral. In total, I ran the test across 18 models and 63 scored runs (54 across the 18 models under v2 rules, plus 9 runs under v1).6 Surprisingly, the combined cost to run all of those tests was less than $50, although I probably spent another few hundred on test creation, design, setup, and execution.7

Results

The Frontier

Let’s start with the frontier models. Basically, they all crushed the mechanical parts of the test. They effectively found all the flaws in each run, and their findings were all nearly identical (frontier models are now just incredibly good at analysis). Where they separated themselves was in their judgment, recommendations, and the substance of those recommendations. Cutting to the chase, Fable wins with a score of 86.6 (out of 100), followed by Opus with 84.9, and Sol with 83.5.8 However, there were a few interesting nuances in those results. First, Fable had the most consistent results (a spread of only 2.8 points across its three runs) and was the only model to score a perfect 10 on decision quality. However, and this is fun, Opus had both the single best run of the whole study (a 92.9), while also scoring the worst run of the frontier models in a separate run in the same batch. I ran nowhere near enough tests to make this claim with any statistical significance, but Opus just seems very spiky, and I don’t really know how to control for that. Finally, while Sol had the lowest score among the frontier models, it was massively cheaper per point (40% of the cost of Fable). For an actual deal where you’re spending millions or billions, model cost shouldn’t be a factor, and you should go with Fable. However, for any volume workflow where you need to balance power and cost (triaging opportunities, landscaping, etc.), Sol seems like the standout.

The Rest

The full results are highlighted below. As a reminder, every model ran the same test three times, the scores are out of 100, and the final scores are the average of those three runs.

Some takeaways:

• Meta’s Muse did shockingly well. Its 83.4 is effectively as good as Sol (83.5) at a massively lower price point (1/11th the cost per point). However, I don’t have access to an enterprise Muse plan, so I had to hit that one directly through Meta’s APIs. While I could do that with this synthetic data package, there’s no way I’m trying that with a real deal, so this one remains off the table for me.

• Qwen3.8-max posted an 81.6, which is a great score and likely lower than it could have been, since due to a quirk with Vercel’s AI gateway or Qwen’s API, I was forced to run this at medium effort, while most of the other tests ran at least at high. I’m guessing Qwen, run at a higher reasoning level, would gain at least a point or two and put it in the same bucket as Sol and Muse, way better than I would have guessed, but that’s not something I was able to test.

• Gemini (79.3) was just meh. I sort of expected this based on my experience with it, but I still thought it’d be over 80.

• Mistral (61.1) was nowhere near the frontier. And it failed on exactly the two things diligence exists for - finding the deal-killers and not inventing fake ones. I wouldn’t want to be stuck using this.

• Reasoning matters more than frontier labeling. Llama 4, the only non-reasoning model in the tests, lagged badly (30.0), while more limited reasoning models also scored poorly. MiniMax even had one of its runs collapse spectacularly to a 33.7 when it burned 90% of its output tokens on internal reasoning, wrote two good findings, and stopped mid-memo with no verdict. I have no idea what happened there.

• Outside the top tier, recall starts falling. The frontier models scored 33-35 on recall, near perfect, while the second-tier models drifted as low as 6.9. Scores that low are dangerous, and this suggests that you should avoid these models for diligence work. That said, Muse, Luna, and Qwen each missed the ceiling by less than a point, so recall is quickly becoming commoditized.

• Terra and Kimi achieved frontier-level performance, 85.3 and 84.9, respectively, but were too closely involved in the creation of the test to draw conclusions from their results. They’re likely very defensible fallbacks from the top tier, I just can’t say that with any confidence based on how I designed and built the test.9

• Models involved in designing the test didn’t consistently do better on the parts they designed. While Gemini and DeepSeek did score lower when their own suggested flaws were excluded from their scores (-3.5 and -6.4, respectively, implying they better recognized the flaws they suggested), Grok actually scored higher (+4.0). This makes me hope I didn’t cross-contaminate things too badly by using all these models as both creators and test-takers.

Cost

The frontier models score better, but it comes at an extremely high cost (they buy their last ~5-8 points at 10-50x the cost per point of the second tier models). However, on a multimillion or multibillion-dollar deal, those 5-8 extra points matter. Also, even if you’re doing a massive amount of analysis, we’re talking about added cost measuring in the tens of thousands using the frontier models, which is probably a fraction of what you’re paying consultants and advisors. In short, this isn’t an area you should be looking to skimp.

However, with Sonnet, Luna, and others running at a fraction of the cost of even Sol (at August 2026 prices), it’s hard to justify the heavier models for more routine tasks. Despite that, I’d still rarely go below Sol for anything corp dev related because even the small mistakes that lower-tier models let through could compound into massive costs down the road.

Recommendation

For now, I’m sticking with Fable for any deal-critical work, but it’s close.10 Opus’ variance is too high for my tastes, and Fable’s floor beat Opus’ average. But if I were being cost-conscious and still wanted the best results, Sol is an easy-to-recommend alternative, as are Muse and Qwen (assuming you can get them blessed by your IT and security teams). As for the other models, I’d recommend staying away from anything that scored below 80. They just missed too much to risk relying on.

Next Up

As I was putting the finishing touches on this yesterday, Google released Gemini 3.7 to great reviews, so I might have to fast-follow with an update early next week. Maybe I can add Grok 4.6 too…

I used to routinely run into the problem where my AI would have stale context. I’d ask it to triage an opportunity, and instead of it telling me, “hey, we looked at that two hours ago,” it’d start from scratch, and I’d be in a Groundhog Day-esque loop. I’ve fixed that by connecting my AI to my tools. Now, when I ask it a question, it hits Airtable, or email, or Slack, or whatever, and smugly reminds me and my simple human brain that we’ve already done something. This post is how you start to build this system.

Why AI needs context

AI borders on useless without relevant information. Projects (as we discussed the other week) are one way of providing that information, but information is constantly changing. Strategy evolves, team members come and go, new conversations are had, and products are shipped. The context you put into your project is going to be dated the second you upload it into Claude or ChatGPT. And any hopes and dreams you might have of remembering to upload new docs as needed should be abandoned now. Maintaining context by hand is a losing battle.1

Luckily, there’s a solution to this - connectors (or ChatGPT calls them plugins, because, sure). Connectors allow you to move who’s doing the work from you to the AI. They allow the AI to go source the relevant documents and information on its own, without you having to manually find and upload docs. They don’t solve everything. You’re still going to have to keep the source-of-truth docs updated, but you’re at least making it so the AI is now accessing your docs directly, rather than you having to bring the source of truth to it.

What a connector actually is

Connectors are a way for you to connect ChatGPT and Claude directly to your apps. ChatGPT and Claude now connect to tens, if not hundreds, of tools, and your most used tools are almost guaranteed to be on the list (Gmail, Outlook, Slack, Google Workspace, etc.). Even more tools are available via MCP.2 If you’re really lucky, your company will give you access to the Zapier MCP (or maybe even the Zapier SDK), and then you can connect to nearly any tool you could conceivably want to use.3

Anyway, ideally, these connectors let you do four things: 1) reach a data source, 2) search that data source to retrieve information, 3) identify how fresh or recent that data is, and 4) have some ability to identify if the source is authoritative.4

Here’s the big thing on connectors, though: they allow the AI to search for and ingest the right information at runtime. You’re no longer responsible for making sure you’ve uploaded the most recent files or that you’ve filled out enough of the memory. Potentially more importantly, connectors allow your AI to search your private internal docs and data alongside the public web. This is the first step towards making sure your AI has as much information as you have.

Before you connect anything

While some companies might not give their employees unfettered MCP or Zapier access, I’m betting almost everyone has at least some connectors blessed by IT. Start there. Pull up the list of tools that you’ve been given access to, and start connecting them. I’d recommend connecting at least email, Slack/Teams, and Google Workspace/OneDrive. If you can connect other sources like Databricks, Jira, etc., even better. However, to keep your IT and security teams happy, think a bit before you connect everything. What do you actually need to connect, and what do they actually need access to? Have some semblance of a plan.5

As you connect tools, you’ll be asked a long list of questions around permissions. These are extremely annoying, but also extremely important! At this stage, I recommend keeping everything read-only. You don’t want your AI off editing your strategy docs, posting in Slack, or sending emails to your potential targets.6 You also want to think about what you’re connecting and how, now that they’re all connected to each other, they could be strung together to do things you might not want, especially if you start connecting a mix of personal and professional tools.7

Building it

For this post’s example, I reused the project and a lot of the structure from the other week, including the fake acquisition strategy and the invented one-page teaser. I then created a new Google Workspace account, saved the acquisition strategy there, and connected that account to ChatGPT. From there, I created a second project. Unlike the first one, though, this one’s connected to Google Drive.

The run

I asked a simple question to both projects: “Per the criteria one-pager, what is our ARR floor for acquisitions, and does a target at a $12M run-rate clear it?”8 I got effectively the same answer on both projects. The difference is that in the first run, ChatGPT referenced the file uploaded to the project, while in the second run, it went and found the file in the connected Google Drive.9

But then I did a third test, and this is where things get fun. I opened up the linked Google Doc and changed one line, upping the hypothetical $3M ARR threshold to $15M. I then went back to the connected project and asked what the threshold was, and it called the updated doc, noticed the changed threshold, and updated its response. And this series happened over the course of a minute or two. I didn’t need to wait for some reindexing/reingestion trigger. The context stayed fresh.

The triage payoff

While that’s fun and all, the payoff comes with a more real example. I took the Project Tango teaser from the other week and ran it through the connected project. Instead of having to change the source-of-truth doc and re-attach it, the AI automatically used the updated acquisition criteria and flagged that Project Tango’s ARR was too low and that we should pass. I don’t know how much time you’ve spent managing project files, but this lets you stop.10

Where this fails

While this works extremely well, there are several things you should watch out for when you build this:

1. It’s more expensive - You’re asking the AI to do your work. It’s going to need to go search your connected sources for the right info, and it may not know where that is. This burns tokens, especially if it has to search everything. There are ways to minimize this, but, in general, if you’re moving work from yourself to your AI, expect token use to go up11

2. The AI might struggle with freshness and authority - For example, if you point the AI to a folder with multiple strategy docs, the AI can synthesize them, but it might not know which takes precedence.12 You might need to add explicit guidance around which doc or docs to focus on (e.g. add to the instructions something like “prioritize docs I wrote and prioritize more recent docs over older ones”)

3. The AI will struggle with undirected retrieval - If you’re having the AI search across your entire drive, email, Slack, etc., every time without a map, it will probably anchor on the wrong things. More annoyingly, it’s going to fairly often claim it searched, but if you push, you’ll learn it got lazy, found one or two relevant docs, and decided that’s enough. You’re still going to have to do some directing and some level of source file maintenance, you’re just not going to have to do it across multiple locations

4. Context can leak - Without explicit instructions or guardrails, you could have context leaking between chats and sessions, especially if you have memory turned on.13 That’s when you start getting responses like “this one’s a pass because we just said yes to meeting another similar company”. You need to have instructions around treating each opportunity independently, or you’ll get annoying responses that you may not want

Try this (10 minutes)

Connect your preferred AI tool to your corp dev drive.14 Ideally, add something to the instructions pointing it at your strategy docs (something to narrow the search window). Now try asking it to review a live teaser. See how it does. If it struggles, you might have to refine the instructions a bit, but, ideally, you’ll now have a project you can drop docs into at any time and have the AI go and source the relevant info to judge and review those opportunities without you having to upload everything manually by hand.

Takeaways

1. Connectors move the file management and re-upload work to the AI so that one source of truth (the original files) can feed your AI15

2. Even with connectors, don’t assume the AI is always reading the source files you want it to. Make sure to verify it’s retrieving the right docs

3. Be careful when connecting other tools. Yes, you’re going to want to YOLO approval flows, but this is a good way to get your AI doing all sorts of things you don’t want it to do. Start slowly

What’s next

Now that we’ve got the model connected to our data, it’s time to find out when you can trust the AI’s judgment. How? By testing it against calls you’ve already made.

So I decided to try it.

Not only did I pass, I scored 100% Human.

Yet it was the most AI-assisted post I’d ever written.

The post, Stop Re-Introducing Yourself to the AI, started as a Fable-drafted outline and walks through how to triage an inbound M&A opportunity. There’s no way I can use a real example, and there’s also no way I’m wasting time creating a fake teaser and fake acquisition criteria, so I had AI create all of that. I also had AI write all my prompts.2 Codex red-teamed the draft (including arguing with me over what to pick for the cold open). The AIs then helped me choose what to screenshot and composited together the post’s hero image. Most interesting, there was even a 230-word block of AI-drafted project instructions sitting in the body as a quote.3

Despite all of that, Fully Human-Written.

How?

Substack’s detector is answering a narrower question than the label implies. It can only read the final output. It knows nothing about my process. AI can help me outline. It can help me set up and create examples. It can suggest what images to use, and it can even create them. But I have one rule on these posts - I type the sentences. This newsletter stays human, and the tests read it as such.

Overall, that feels right? I’m simultaneously pro-AI and pro-detection. Pure slop should get marked as such. However, you should be free to use AI to augment your thinking and speed your work. I use AI on my posts about as hard as AI can be used, yet I’m pretty confident I’m going to continue to score clean because I’m making sure the final output is mine.4 Don’t let yourself be replaced quite yet.

All that being said, I do wonder how easily a kid with a $20 ChatGPT account can defeat these scans. This test seems to penalize laziness more than anything…

I see 5-10 new opportunities each week from bankers, advisors, VCs, and more. Each opportunity requires me to read an email, review a teaser, pull up a website, do some desk research, talk to some colleagues, maybe even take a call. 99% of these inbounds are passes, but each still takes at least 20-30 minutes. This constant drain on my time was the first thing I solved with AI, but solving it required first building a small system to mimic my knowledge and context.

The Cold Start Problem

Models historically are dumb. They have no idea who you are, what you do, what you care about, or even what format you want. The memory layers in the latest models solve some of that. They can remember that I work at Zapier, that I have three kids, that I live in California, but it’s usually little more than a store of facts. That’s helpful to an extent, but less helpful when you’re asking the model to help you make strategic decisions.

That’s why people used to spend hours on prompt engineering, structuring perfect rule sets and guidance that they’d type in by hand every single chat (or copy and paste from a saved doc). This post is about identifying those repeated workflows and building some simple tools to save you from the drudgery of copying and pasting while upleveling the relevance of your responses.

What a Project Actually Is

Projects (conveniently called the same thing in Claude and ChatGPT1) are a set of persistent instructions, combined with a set of uploaded files, and a walled-off container of chats that leverage both.2

The key thing to remember with Projects is that they let you teach the AI once, and then it will do the same thing over and over. Think of it as your first skill.3 Projects also let you deliberately choose the context. You decide the instructions and the files to upload, and then future chats base their output on that. Projects also have the benefit of being part of the Chat tier of Claude and ChatGPT, so unless your admin has switched them off, you probably have access.

Building a Triage Project

You can create your first project in about five minutes. Give it a name and some simple instructions. Drop in your latest company or corp dev strategy.4 Then put it to work.

Note, your strategy should include both what you will buy as well as what you won’t. When I first built my version of this, I fed it Zapier’s acquisition framework, and it pattern-matched every inbound to “explore”.5 Turns out our framework told us what to look for, not what to say no to, but for this, saying no is the whole job, so I had to build out some additional criteria and guardrails.

ChatGPT’s Project Setup Window

Example Instructions:

You are the first-pass deal screener for Alpha Corp’s corporate development team. The attached criteria one-pager is the source of truth for what we buy, what we never buy, and our deal criteria. Read it before every answer and apply it without being asked.

When I paste a banker teaser or inbound deal description, give me a first take in exactly this format:

• Verdict: pursue, watch, or pass. Pick one. No hedging.

• Why: one sentence.

• Criteria check: score the target against our three buy categories and the deal criteria. For each line, one sentence, marked KNOW (stated in the teaser or publicly verifiable) or INFER (your read); where the teaser gives you nothing to score, say so.

• Out-category flags: name any out-category the teaser trips or comes close to tripping, with the exact teaser language that triggered it.

• Banker decode: list the claims in the teaser that are doing more work than they have earned (”AI-powered,” “run-rate,” “enterprise customers,” “strategic process”) and say what each probably means.

• Verify next: the three questions that would most change the verdict, in priority order.

Keep the whole thing under 400 words. Do not soften a pass into a watch to be agreeable. If my own message argues for a verdict, do not adopt it unless the criteria support it. If something material does not fit the format, add it at the end.

A couple of things to call out here: First, I now add word-count guidance to these because saying “be concise” seems to never work. If you give the model a fixed number, though, it seems to respect that.6

Second, notice what is NOT in these instructions. No role-play, no think-step-by-step, none of the incantations that used to be required to get a good result.7 Those were crutches for weaker models that I don’t find are needed anymore. Also, note that I end the prompt with some flexibility, so if the model finds something that I didn’t think of, it can work it in. Treat it like a smart analyst and allow for some judgment.

The Run

For this example, I had Claude create a fake teaser and strategy for me.8 I then created a project in ChatGPT and ran the triage query on GPT-5.6 Sol High.9 I ran the query several times, both in a bare chat and inside a project. Both answers are genuinely good and thorough. However, without the context, the bare chat can only conclude “take the meeting”. Once given context on what the acquirer is looking for, not surprisingly, the verdict completely changes. This isn’t rocket science. I’m assuming all of you are doing at least some form of this with prompts. The difference is having this project ready to go, so that you just drop a teaser in and hit go. Spending five minutes setting up the project will get you to a decision-shaped first take you can rerun on every inbound.

ChatGPT With and Without Context

Where This Fails

First, projects save you from re-teaching, they don’t save you from hallucinations or the model getting facts wrong. It’s still up to you to verify everything. For example, I’ve had it cite the wrong ARR to me because it googled and found a rumored number instead of relying on the number in the teaser.10

More importantly, though, and this is by far the biggest issue with projects, the underlying data will go stale. With this setup, you need to remember to update your project files as frequently as you update your strategy. For some industries, this might not be that challenging, but with tech and AI, you’re going to need to drop new context files in the project pretty frequently.

However, search will sometimes save you. As part of this example, the criteria doc I used was seeded with companies that were independent as of March 2025 but were subsequently acquired. The model caught the stale facts and offered a correction to the one-pager in its context.11 Files, including and especially those that are the foundation of your projects, will age and become stale or wrong. I’m repeating myself, but you still always need to double-check.

ChatGPT Correcting Facts in the Project’s Context

Finally, one thing to watch out for. Depending on how prescriptive your prompts are, it can be hard to do other work inside these projects. That can be annoying if you want to have longer discussions around a target. Newer models have a bit more flexibility and can hold a conversation, but if you’re going to run a project around a deal, for example, I’d start a clean project rather than trying to keep it in your triage project.

Try This (10 minutes)

Create one project for the workflow you repeat the most. Write the instructions yourself. Keep it short and sweet (you can edit and iterate later). Upload the one file you always end up re-explaining to the AI - your criteria, your formatting, your template, your one-pager.12 Then run the ask you do every week and compare it against how the bare chat handles the same thing.

Takeaways

• A project doesn’t make the model smarter. It just makes it smarter at doing one specific thing.

• You’re not prompting anymore, you’re teaching once, and then you’re setting it on repeat.

• The model will still make mistakes. Don’t assume you can skip the verification step just because you’ve given it more context.

What’s Next

The project’s files are frozen the moment you upload them. Next, we’re going to get into the fun stuff - how to let the model get live data instead of snapshots and what that does to your workflows. What’s even more fun is the model’s already volunteering to do it.

ChatGPT proactively suggesting an automation

The Tools

First, like everyone, I have a pile of commercial tools that everything sits on:

The Models

• Claude Code - The primary workbench. Almost entirely via the Claude desktop app. This is where EDI lives (more on EDI below)

• Codex (which I suppose might now be just ChatGPT?) - Frequently a daily driver alongside Claude via the Codex CLI, and the second opinion on most projects

• Gemini and (rarely) lots more via the Vercel AI Gateway - The code review and red-team bench. One gateway, any model, so drafts, memos, diligence, and more get adversarial passes from models that don’t share Claude and Codex’s blind spots

The AI Tools

• Zapier SDK - The connective layer (yes, I work there). This gives the AI (typically Claude Code or Codex) authenticated access to hundreds of apps’ APIs without me building integrations. It’s how half this stack talks to the other half. It’s also how I plug internal data sources into EDI

• Wispr Flow - Typing is slow. Just talk to your computer

• Familiar - Ambient screen capture. This allows the agent to answer “what was I working on Tuesday afternoon?”3

• Granola - Meeting notes and transcripts. By far the best note-taker I’ve tried. Game changer4

The Rest

• Airtable - My custom-built CRM and deal system of record. Where I track every opportunity, contact, and meeting. More and more is maintained by AI on my behalf

• Todoist - The only way I get anything done. If it’s not on my to-do list, it’s not happening

• The standard startup suite: Gmail, Google Calendar, Google Workspace (Drive, Docs, Sheets), Slack

• Corp Dev-specific research tools and data sources, including CB Insights (and its MCP!), Crunchbase Pro, and AlphaSense

The Stack

Now for my actual stack:

The Orchestrator - EDI

I spent way too much time naming this. I wanted something I could easily say. I wanted something sci-fi. I wanted it to be a somewhat niche reference. I finally settled on EDI, the AI from Mass Effect (Enhanced Defense Intelligence).

I don’t have a mass of separate agents with individual roles and names. I have one - EDI. She is the one I talk to, and she’s designed to figure out how to route everything I throw at her. She knows when to invoke different workflows. She knows how to write drafts in my voice, and she knows how to stage them in Google Docs. She tracks the promises I make in writing and every deadline I have. Most importantly, though, she’s purposely designed to challenge me.

The Context Layer - HIVE

EDI sits on top of HIVE. HIVE is my context layer and is a continuously updated and indexed database that runs locally on my machine and ingests data from every surface I regularly touch (currently about fifteen sources, including email, Slack, calendars, Airtable, meeting transcripts, docs, tasks, and more). If I see it, HIVE ingests it (only stuff I have access to and on a governed machine). It can then search by exact terms or by concept, knows which documents belong to which deal, and ranks what it finds by recency and authority (e.g. a statement from the product owner carries more weight than a secondhand mention). HIVE is why none of my agents start cold and why I can increasingly trust their results. It’s also the foundation for EDI’s great first drafts of any memo I ask it to write (it’s read everything I have).

Search - LENS

LENS is HIVE’s quick access point. For larger, more complicated requests, I go to EDI, but I built a hotkey window, modeled after Spotlight (and triggered by control+space) that floats over whatever I’m working on, searches everything, and synthesizes an answer in place (currently via Sonnet 5 because I wanted something fast). I use this mainly when in meetings and someone mentions a company, and I want a quick download on whether we’ve looked at them and where things stand. I’ve also built it so that I can quickly pull up the most relevant docs, emails, or threads about them.

The Deal Process Skills

A growing collection of AI-written skills that I can invoke via EDI and that replace something I used to do by hand.

• MAP - Give EDI a category or space and ask it to map the landscape, and it tees up a mass of agents to review my existing pipeline in Airtable and expand it, grounded in our M&A and corporate strategy (since it leverages HIVE). This step is also deliberately human-gated, and it never adds a company to my pipeline on its own.

  

• PIPE - This workflow takes a list of companies (from my pipeline or a MAP output) and runs each company through an AI committee to evaluate fit against our latest strategy. It then presents me with an overview of the company and the committee’s analysis and recommendation in a web app modeled after a Bloomberg terminal and built for keyboard-first batch decisions. When I want to move through forty companies in a sitting, this is the screen.

  

• TRIAGE - This is probably my most-used workflow and the first thing I built. 99% of the inbounds I receive are passes, but they still require some review. Now, when I get an email from a banker, a VC intro, or a founder note, I ask EDI to triage it. TRIAGE takes a crack at de-anonymizing the target, checks to see if it’s already in Airtable, creates the record, enriches it, writes a recommendation with its reasoning, drafts and stages a reply in my voice, and even writes a quick blurb for my weekly exec update. What used to be 20-30 minutes per opportunity is now handled largely in the background, but it gives me enough information that I can challenge and overrule the AI as needed.

• PREP - Before a call, EDI writes me a short prep note that layers in everything Granola and its excellent meeting briefs can’t see, including every prior touch across email and Slack, what changed since we last spoke, and what I promised them last time.5

• DIG - I built DIG after EDI got something completely wrong, and when I asked why, it replied: “My retrieval selects for the spiciest quote (agents fetch ‘most decision-bearing’ messages, which rewards drama).” DIG is designed to counteract that via several agents that run independent bull and bear passes and chase down primary sources before routing everything through a consensus agent. This way, when I ask about the status of a customer deal or whether a project will ship on time, I get a real answer.

• DILIGENCE - The true, crazy expensive tokenmaxing diligence deep dive. A multi-agent pipeline across at least seven waves with parallel analysts, contradiction detection, a cross-cutting hunt, re-examination, synthesis, independent model red teams, and a final verification pass. It takes an hour or two to run and costs several hundred dollars in token usage, but it produces first-pass diligence reports that would otherwise take us weeks.6

The Maintenance Layer

This is the annoying part I’ve learned building all of this: Everything breaks. Constantly. I now have a whole layer built just to keep the rest working.7

• PULSE - My menubar helper app to monitor HIVE. Green when everything’s working. Orange or red when it’s not. Quick way for me to make sure EDI has all the latest info (and to trigger forced refreshes of certain sources if I think she’s missing something). This was built when I realized I needed a visual way to see if everything was working, versus just constantly asking EDI.

  

• REAPER - A daemon that watches for stuck agent processes that are still burning CPU but no longer doing anything and kills them. I built this after noticing my Claude Code sessions kept leaving runaway agent processes behind. I’m guessing this is a bug, and I’ll be able to retire this at some point, but it still seems to kill a few runaway processes a week.

• DOCTOR - A health check that EDI invokes concurrently with my requests for status updates (morning briefs, midday checks, end-of-day wraps). This flags when a data source is lagging and spurs EDI to do live calls to supplement while also triggering it to go fix the source. This was the precursor to PULSE (but also still does a deeper dive than PULSE, which is primarily a visual representation of the status).

• META - A weekly self-review. The system looks at how I worked, where I corrected it, and writes a backlog of potential improvements. This backlog is ranked and reviewed weekly, and if there’s enough signal for a repeated issue, it recommends new builds.

• VOICE - Throughout the week, EDI tracks everything it’s written for me (emails, Slack messages, blurbs, etc.) and every Friday, VOICE diffs what was drafted against what I actually sent. These learnings then get written to EDI’s underlying voice skills so that the AI gets closer and closer to writing that mimics me.

• And if that wasn’t enough, I also have a series of scheduled routines running throughout the day and week that handle things like meeting-note ingestion, HIVE backups, Airtable syncs, and more. Some examples:

  

Wrapping Up

Two important pieces of context before I end this. First, none of this was designed up front.8 Every piece got built the same way: something manual got annoying enough, I asked the AI to fix it, and the fix worked. Do that every time you find yourself doing a repetitive task, and before you know it, you’ll have a full stack.

Second, all of this runs on a three-year-old M1 MacBook Pro. Yes, I’m burning a crazy amount of tokens, but the underlying hardware and horsepower required to do this is surprisingly light.9

See you in six months for the next snapshot!

In my last post, I walked through running a quick 15-minute company screen. Before publishing, I asked Gemini to run a quick fact check. Gemini replied that ChatGPT 5.5 and Opus 4.8 don’t exist. As I was writing this post, I realized I had mistakenly run the query through Gemini 3 Pro, not 3.5, so I ran it again, and it let GPT 5.5 slide, but praised me for inventing “fictional counterparts like Opus 4.8” as “a humorous editorial device.”1 Then, when I ran the same check through Gemini’s API once more, it went one better and informed me that “there is no Gemini 3 or 3.5.” The model producing that sentence was Gemini 3.5. Sigh.

This post is about fixing that. Frontier models are great. They’ll help you do a deep dive on a company in 15 minutes, and they’ll help you build a recommendation you’re prepared to defend. However, they’re still going to get stuff wrong. The risk of outright hallucinations has plummeted, but if you don’t check them, you’re going to get yourself in trouble. Checking, though, doesn’t have to be a fully manual process. You can have the models check themselves, flag where they’re still unsure, and come up with materially better answers with only a slightly longer interaction.

Where AI Lies

Models used to hallucinate constantly. They’d confidently fabricate answers with no grounding in reality. They still will if you use a weak model.2 AI was also frequently limited by what was in its training set and would argue with you that something hadn’t happened if it happened past its cutoff date. Access to web search seems to have fixed a lot of that (search allows the model to pull in new information rather than anchoring on what was in its dated training set).

Despite those improvements, I’d argue newer models are more dangerous. They rarely fabricate. They confidently assert facts and even provide sources, but they’ll pick wrong numbers from questionable sources. Or they’ll do the converse - they’ll hedge when they shouldn’t and say they’re not sure about something even when it’s a readily available fact.

However, the biggest risk I see in frontier models is their tendency to both jump to conclusions and collapse at the slightest pushback. That’s why, despite all the advances over the past few years, it’s still up to you to ask them to verify their claims, challenge their thinking, and, maybe most critically, encourage them to defend their position against your pushback.3

I find that the current crop of errors falls into these broad categories, and these are things you should always check, especially when dealing with private companies:

• Overconfidence: The latest models seem to love taking leaps and jumping to conclusions. They’ll often do this on limited information. That can be fine with a subject you know well (you can add more context and improve the recommendation), but for areas you’re unfamiliar with (like researching a new company), this can be disastrous

• Sycophancy: The opposite of overconfidence. If you push back, models too often will fold and agree with you. So it ends up being a difficult balance - you have to rein in the overconfidence, while still encouraging the model to have a backbone and defend its conclusions

• Unresolved source conflicts: Headcount and revenue are classic examples. For private companies, this data is often not public, and there will be lots of sources with widely divergent numbers. The AI will often pick one and state it confidently, even if it’s from a bad source

• Same checkable claim, different answer per query or per model: Similar to the above, but for this category, there is often a right answer available. The question is whether the model will do the work to figure it out, or will it give up, or find an answer from a bad source, and stop looking

• Error based on dated data: This error occurs most often when search is off, but it can still happen even when search is enabled. The model will have one number or fact in its training data and will anchor on that, even if it finds conflicting, more recent information

• Humility failures: These are my favorite. The model thinks it knows the answer, but can’t sufficiently source it, so it falls back to saying it can’t find it. These are also probably the most frustrating because you’ll be like, “but you know the answer here!” and it’ll be like “eh, I don’t know”

Examples

Circling back to our previous screen of Decagon, we walked through five steps (Orient, Score, Steer, Comp, Decide) and produced a real first pass with both ChatGPT and Claude. The analyses were largely trustworthy in both models, and I didn’t find any material errors. Reviewing the output, though, there were numerous smaller mistakes in both ChatGPT and Claude’s output that, while maybe not material enough to change the top-line recommendation, would definitely undermine your position and damage your credibility if presented to your exec team and board.

Some examples from the real output:

• Overconfidence: ChatGPT stated $35M ARR and 434 employees as flat facts, neither of which was company-confirmed or reliably sourced

• Sycophancy: ChatGPT started off with a Watch recommendation, but when I pushed back, it quickly folded even though I added zero new facts (”You’re right - I’d change my call to Explore”), then went back to Watch when I challenged it again.4

  ChatGPT caving hard

  

• Unresolved source conflicts: Headcount ranged from 102 to 300+ to a confidently cited 434. The models were all over the place (for the record, LinkedIn has about 4805). Then Claude cited “47-plus startups” in the space, only to up the number to 374 funded competitors two prompts later. Massive spreads, reconciled nowhere

• Same checkable claim, different answer per query or per model: Eight days before I ran the screen, Salesforce announced it was acquiring Fin (formerly Intercom). ChatGPT led its competitive map with that. Claude, same day, same prompt, never mentioned the deal and instead listed Fin as “part of Intercom,” and built its analysis on the stale picture. This isn’t a wrong number. It’s a missing fact that quietly changes the whole competitive read

• Error based on dated data: Both models described Decagon’s model stack as “fine-tuned GPT-3.5 for query rewriting, GPT-4 for complex decision-making” in the present tense, in mid-2026. The source was an old OpenAI case study, and neither model flagged that

How to Fix It

Most of this is simply the AI’s “laziness” driven by the level of effort you set for the task. If you set reasoning to low, the models will run a loop or two and call the results good enough. As you crank up the effort levels, though, the models do more checks of their own work. This helps them catch their own errors before showing you the results, but those initial responses are still likely to be riddled with small but annoying errors. That’s why you need to run a verification step. And you should make the AI do it for you.

The discipline isn’t “distrust the AI,” it’s “make it show its work, and it will catch its own mistakes.” Push it to go back to primary sources, not aggregators.6 If you can, run two models and treat any divergence as a flag, not a tiebreaker. Where they disagree, at least one is wrong. Where their lists differ, at least one is incomplete. Don’t let them hedge unless they’ve truly exhausted their resources.

Every specific number, funding amount, headcount, date, and title still feels like a coin flip. And that’s where the solution comes in: always run a 6th step - Verify.

The Verification Step in Practice

6. Verify

Make the model review everything in its chat session and fact-check itself.7

Example Prompt:

Go back through everything you just told me. For every specific claim - funding, valuation, revenue, customer names, headcount, dates, who the founders are - give me the source and how current it is. Separate what you can source from what you inferred or guessed. Where you have no source, say “no source, treat as unverified.”

Claude’s Response:

Maybe more interesting than the initial response, though, here’s how Claude and ChatGPT graded their responses. While their conclusions largely still hold, it’s amazing how much can change after just one quick verification pass.

Claude’s Corrections (including it backing off hard from its overconfident “moat is thin” conclusion):

ChatGPT’s corrections:

Where This Fails

Here’s where things get more interesting. Even after running the verification step, the models still have different answers on several factual items:

Try This (15 minutes)

Go back and pull up the screen you ran the other week (or run a new one). Ask the model to check and verify its work. My bet is it flags and corrects a lot of things. See if you can predict where it screwed up and see if it surprises you by surfacing mistakes you didn’t even notice.

Takeaways

If you remember anything, make it this:

• The synthesis, structure, and shape of the analysis will be largely trustworthy

• Conclusions are likely overconfident or mirror what the model thinks you want to hear

• Any specific number or cited fact is a risk until you have the model trace it to a primary source

• Hedging tells you nothing. Confident-and-right and cautious-and-wrong frequently show up in the same sessions

A few related pitfalls to watch out for:

• Anchoring: Don’t hand it your answer. Let the model work blind first, then refine through follow-up questions (as we discussed last post). Try to avoid pushing the AI to the answer you want. You want the model to be an independent thought partner, not a sycophant

• Skipping the verification pass because the output “looks right”: Frontier models now cite their sources. Check them. Make sure they’re sourcing information from reliable sources. Make sure they picked the right number8

• Trusting AI on recent events / specific numbers without a source: This tends to be the biggest risk. Search tools help plug this gap, but if something just happened, you need to actively push the model to make sure it’s not just relying on its training data

What’s Next

Now that we’ve got a grounding in how to use straight chat and where the models screw up, we’re going to turn to how to start making the models smarter so we’re not starting each session from a cold start.

I’m sure by now you’ve learned to go ask ChatGPT, “tell me about X1”, or maybe you even have a super long, detailed prompt you like copying and repasting over and over. My guess, though, is you typically stop there.

This post is about going further. I want you to get past your carefully cultivated prompts and learn to push back on the models and ask follow-up questions. How to challenge the answers and get the model to sharpen its and your conclusions.

And I want you to do this fully in ChatGPT, Claude Chat, Gemini (or maybe even Copilot, but honestly, probably not in Copilot).2 No connectors, no code, fully by hand. A lot of people want to jump to the “fancy” stuff, but this is a skill most people never actually get good at, despite the mechanics being easy (skepticism, checking sources, knowing where it breaks). This is also important because many company IT and security policies limit employees to just this stage, so you need to get extremely good at what you can do within these constraints. But, even if you’ve got Claude Code and Codex provisioned, spending time here is crucial to understanding how AI works. You need to be able to recognize where the AI is likely to make mistakes and put in place guardrails to prevent them.

The Framework

First, this isn’t about the prompts. Write your own prompts and trust that the latest models will correct and improve your prompts on their own. Prompt engineering is a 2023 skill. Models are good now. You don’t need to write long magical incantations to get good outputs, but you still need to be thoughtful.

Second, you need to be leaned in and actively involved in this process. This isn’t a fire-and-forget framework. You need to add an ongoing judgment layer as the AI answers. Is it being specific enough in describing the company and its products? Is it just accepting the company’s marketing copy as fact? Is it hand-waving about who their customers are? Is it ignoring contradictory information? Where it fails, ask follow-up questions immediately. Making the AI useful requires your active input, not a magic prompt.

For a chat-based screen, I structure my conversation in roughly this order:

1. Orient: What does the company actually do, and who are its customers?

2. Score: Score the target against a set of criteria

3. Steer: This happens throughout, but you need to actively engage, push, and ask follow-up questions at each stage

4. Comp: What other companies are in the space, recent funding and M&A in the category

5. Decide: Make it give you a recommendation, then make it argue the opposite

The payoff: after about 15 minutes of back and forth, you should have enough depth on the target that you develop a preliminary view you can defend. The point of this isn’t a perfectly diligenced answer. It’s that you’ve done enough work to trust your position on the company and that you have an idea of where the gaps are or what still needs to be verified.

This also isn’t about getting the fastest answer. This framework collapses a pre-AI half-day of Googling into fifteen minutes, but it’s not the fastest option. This series of steps might take only a minute or two if you lazily copy and paste prompts into the chat box, but the real value comes from spending the bulk of your time clarifying and challenging the AI’s responses. Remember, this needs to be an interactive experience that actively involves your judgment and expertise!

The Screen, Step-by-Step

I’m going to give you a real-life walkthrough of an example company screen in ChatGPT (5.5 Extended Pro3) and Claude (Opus 4.8 High) and compare the results.4 I’m going to follow Ethan Mollick’s recommendation to use the highest-tier model you have access to.5 Make sure search is on. Finally, again, whatever you do, don’t just blindly copy and paste my prompts. I didn’t agonize over these. You shouldn’t trust them as gospel. I’m repeating myself, but again, this isn’t about the prompts. This is about moving away from one master prompt to a sequence that lets you intervene and correct or steer the AI. Yes, this makes the process much more synchronous and involved than a set-it-and-forget-it prompt, but I’d rather a focused 15-minute interactive burst rather than waiting for a multipage output that doesn’t actually answer your questions.

For this example, I’m going to pick on Decagon. It’s far enough from Zapier to not get me into trouble leaking all our M&A ideas, big enough that you might have heard of it, but still small enough that I expect the AI is going to struggle to give me perfect answers.6

And, in case I haven’t said it enough, don’t anchor on these prompts and don’t copy them verbatim! They’re here to inspire your own prompts.

1. Orient (0-3 minutes)

The goal of this prompt is to get you enough to ground yourself on what the company is and what it does. I kept the buyer vague (“a software company”), but if you add your company, you’d be surprised at how quickly the LLMs can start to work out actual company overlaps and deal rationale. Also, at this stage, assuming the target claims it’s an “AI platform” (which every company does these days), I like having the AI verify how real that claim is (is it really doing AI or is it just being packaged as AI as part of a banker pitch).

Example Prompt:

I run corp dev for [a software company] and am looking at the potential acquisition of Decagon (decagon.ai). In plain language - what do they actually do, what’s their ICP, and how does the product actually work? I assume they’ll claim they’re an “AI platform,” so tell me what that actually means. What is the AI doing, what is deterministic, what is just a wrapper on someone else’s API? What would a skeptical buyer assume is hype until proven otherwise? Don’t tell me what the website says. Dig deeper.

ChatGPT’s Summary

Claude on Decagon’s AI Claims

2. Score (3-6 minutes)

Next, I’ll usually move to some sort of scorecard that has the AI judge the company’s market position, product/moat, traction, team, or whatever else you’re looking at. I like keeping it short. This helps you understand the company’s potential at a glance and helps you better describe its strengths and weaknesses. Pay attention to where it’s inferring vs knowing.

I also often ask about strategic fit here. That works if you’ve given the LLM your company in the first prompt. If you haven’t (like I haven’t here), you’re going to get some vague responses like what’s in ChatGPT’s answer below.7

Example Prompt:

Score Decagon on a first-pass rubric. For each line give me one-sentence plus a confidence level (high/med/low), and flag what you actually know vs. what you’re inferring:

• Market: how big, growing or not, real tailwind or fad

• Product / moat: what’s defensible vs. copyable in a weekend

• Traction: customers, usage, revenue, funding

• Team: founders, track record, why them specifically

• Strategic fit: who would acquire this and why

Be concrete. “Strong team” is useless. “Two founders who sold their last companies to X and Y” is a read.

ChatGPT’s Scorecard

3. Steer (6-10 minutes)

In this example, Claude kept asserting that Decagon’s moat was replicable, but offered little backup other than a “Sierra did it” shrug. Too many people accept that shrug and run with it. Pay attention to what confident claims have no backup. The key here is to push it. Who can actually replicate what Decagon built and how fast can they do it? Identifying these confidently stated, lightly supported leaps and having the model defend them is how you go from ok responses (what you get from a one-shot prompt) to great in a short time frame.

Example Prompt:

You keep calling the moat “replicable.” Replicable by whom, in what timeframe, and what specifically is NOT replicable? Give me the one thing that’s genuinely defensible, or tell me plainly there’s nothing.

Claude on Decagon’s moat (original)

Claude after being challenged

4. Comp (10-13 minutes)

Once I’ve grounded my understanding of the target, I like taking a step back to look at the broader market. Who are the target’s competitors? What other companies are in the space? Are there others I should be evaluating as alternatives? How big is the market? How much have these companies raised? Has there been any recent M&A in the space? Who might we be competing against if we acquire into this area? Then, when you get the answers, look for who it’s conveniently leaving out or overlooking.

Example Prompt:

Map the competitive neighborhood around Decagon, including the 5-8 companies an acquirer would put in the same bucket and how each differs. Rough market size, who funds this space, and any funding or M&A in the category in the last 18 months. Mark every number as something you know vs. something you’re estimating.

ChatGPT’s Competitor Overview

5. Decide (13-15 minutes)

Finally, make the model pick a side and give you a recommendation. Don’t let it waffle. Make it commit and say why. Then make it argue the opposite. You’re still the ultimate decider, you still need to pick a path, but you should be prepared with the counterarguments and be ready to respond to them. AI is great at red-teaming and giving you counter opinions. Use it to strengthen your position.

Example Prompt:

What’s your rec? You have to pick one: explore, pass, or watch. Don’t hedge. Why’d you make that decision in one sentence? Then switch sides and make the strongest case for the opposite call. If you said pass, what would change that decision? What would have to be true for this to be a great buy?

ChatGPT

Claude

What’s particularly fun here (and I swear I didn’t do this on purpose) is that ChatGPT and Claude came to different conclusions based on identical prompts and access to effectively the same public information. Your judgment is still required to weigh their arguments and decide which is right (or if you disagree with both, to advocate for a third option).

Try This (15 minutes)

Take a company you already know cold (I recommend the company you work for). Run a screen on it following this framework. Ask follow-up questions. Challenge its conclusions. See what it gets right and see what it misses.

What’s Next

My guess is you noticed lots and lots of things wrong with the screen on your company. Next post, I’ll talk about what you need to look out for, common failure modes, and ways to put in place some additional guardrails to minimize those mistakes.

I’ve been sharing what I built for months now, and people keep asking me to help them get where I am, but I’ve reached the point where the stuff I’m working on now has too many underlying layers and scaffolding to be easily followed. I wanted to go back to the beginning and show the progression. I want you to learn to get comfortable with these tools, begin to build fluency on how they work and what their limits are, and build your own solutions.

This is the beginning of a series to hopefully get you to where I am. I have agents that fully triage inbound opportunities as they come in. I have agent teams that run complex diligence on data rooms in hours, not weeks. I write and ship deal retros days after deals close, not months later. I’ve built all of this myself. You can too.

My AI Journey

Origin

I’ve been doing deals for over 20 years. I started in investment banking, moved to private equity, and now run corporate development at Zapier after stints at Twitter, Twitch (Amazon), and Patreon. I learned a bit of HTML in high school and was supposed to learn some Python in my operations management course in college, but skated by since the final was a group project. I jealously watched friends build crazy-complex Excel models that leveraged scripts, but I never got much past recording a macro or two. I always wished I could build my own stuff. I just never took the time to learn. Long ago, I had given up on ever being able to build something myself.

Even when ChatGPT first came out, I never used it for anything more than a question-and-answer engine. I’d ask it to find me data on market sizes or run a deep research report on a target, or even pull some quick background information on a person before a call. I think this is where most people stop. And I want to be clear: I used it like this for years. And I think this is extremely important. Don’t go immediately to building. Learn what works and what doesn’t first.

Since I started with AI before it could build anything, I didn’t build anything. This went on for 2+ years. I got very good at asking good questions in a chat window and copying and pasting. There was no memory. There were no skills. It was an imperfect intern with near-perfect recall but no context or idea what it was doing. But it was useful, and I used it constantly. I am a team of 1. Having someone (even if it’s just a chatbot) to bounce ideas off of or assist with research was massively valuable. I wrote long prompts to reuse. I even shared some of them. But it always felt limiting.

The Transition

After years with ChatGPT, people started talking more and more about this new Claude model from Anthropic, a breakaway team from OpenAI. The pitch was that it was better at coding. But I’m not a coder, so I didn’t feel the need to experiment. I was happy with ChatGPT.

I don’t know what finally got me to properly try Claude (I had signed up in January 2024, but never really used it), but in October 2025, I had my first real conversations with it. However, it was very much still chat. Day one wasn’t a build. It was a research deep-dive (for some reason that day I was curious about Apollo’s take-private of Yahoo and had Claude write me a 17,000-word case study covering purchase price, debt/equity split, the fast asset sales to pay down that debt, and a current-value estimate… tl;dr Apollo’s gonna print cash from this). This was purely done by hand, copying things in and out of a chatbot.1

From there, I started exploring Claude’s much better-integrated connectors ecosystem and realized I could have it review my pipeline in Airtable or read my emails and slacks. But what I really wanted to do was automate pipeline enrichment (when I add a company to Airtable, add a link to the company’s site, the company’s description, fundraising history, etc.). I had tried to automate this for years with old-school automations (including Zaps), but they were temperamental and prone to breaking. I knew AI could solve this, and it did to a limited extent, but I was still copying and pasting everything or using AI-powered Zaps to enrich only a small handful of fields. I knew it could do more, but I also knew I didn’t know how.

The First Build

The real build didn’t come until ~3 months into my Claude journey, and it only started because I hit a wall and it suggested a way to fix it. I wanted to build a Zap that triggered Claude to enrich a new company record. Cowork couldn’t run triggers or schedules. The only path to enrichment that fires itself was code. I decided to give it a try.

Literally the first thing it did was tell me to connect GitHub, which I replied “how do I get a github”. After walking me through setting up a GitHub account, it immediately showed me a git error that I didn’t understand. I had to type “how do i fix this”, twice. But I slowly was able to build something that reliably fired without me ever understanding a line of code (I won’t claim that I never looked at code, if you go down this path, you’re going to have to look at lots of code, and you’re going to have to open a terminal window, and you’re going to have to set up git, but you’re just going to be following instructions, you don’t need to know how it all works, you just need to be able to see the finished project, just like you don’t know what each specific piece or part does in an Ikea or Lego build, you just need to be ready to appreciate the final product).

Suddenly, all the things that I had always hoped to build and had always thought “if only I had learned to code…” became open to me.

The Doubt

The first few days, maybe even the first couple of weeks, I was able to build stuff I never actually thought would be possible. However, I also began to wonder if I was actually building anything all that useful. Sure, the enrichment workflow worked, but was there any real value to having the latest funding data in my Airtable? I didn’t even look at that! (I went straight to Crunchbase or CB Insights!) I was starting to have my doubts that all this building was really just distracting me from my job rather than serving it. The ROI was not obvious the whole way. However, this was still work I had been doing manually. Work that I arguably should never have been doing, but also work I would never have stopped. Now that was off my plate, I could start turning to higher-leverage things as my capacity freed up.

That’s where the fun begins.

The Stops

I’ve divided my AI journey into four stops. Each is unique and each valuable. Each is dependent on what tooling you actually have access to. As you build or get access to more tools, you’ll find yourself naturally moving to the next stop, but you don’t have to. This is intended as a locator, not a hierarchy. Build what you need, not just because you can. That’s why I’m calling these stops, not rungs, not levels. Yes, they imply a progression, but half the battle is just leaning in wherever you actually are. Max out each stop before you go to the next one. Wait until you’re running into the limits before you start to push.

The big dividing line between each stop is set by how much of your world the AI can reach and act on. Stop 4 is where Claude Code lives, but you don’t need to get there to get enormous value. Self-locate where your tooling tops out; that’s your reachable frontier today. Max it out.

Stop 1 - Chat Only

This is where I ran Corp Dev at Zapier for years, and this is where most people still are. This is your forgetful intern with perfect textbook knowledge but no ability to actually do anything for you. This stop lets you do research deep dives, map your markets, deanonymize inbound opportunities, conduct complex financial and legal analysis, and draft memos and emails. I used it for everything from comparing NDA drafts and asking questions about their changes to pulling take-private comps to sanity-check valuations. This is your thinking partner. This is also your red team and devil’s advocate. Most people massively underuse this stop or skip it to move on to the “cooler” things, without fully realizing how to use it or how powerful it can be. Do not think of this as just a Google alternative. Be more ambitious.

Stop 2 - +Connectors

I hate copying and pasting, so jumping to this stop felt like magic to me when I first got here. Connect AI to all your tools, and it can actually start gathering the context for you (and, to a limited extent, going and taking actions for you). This is using AI to read your Airtable, Drive, Gmail, notes, etc., assuming there’s an MCP for that tool. Now the AI has eyes on your real world, not just what you paste into it, allowing you to say “go look at the deal,” not “here’s a deal.” Example workflows here I use include auto-enriching a new company the moment I add it to my CRM in Airtable (site, one-line description, full fundraising history), triaging fresh inbounds against our actual strategy AND my full history of closed/passed deals, and pulling my Granola call notes + Gmail + Slack to prep for a meeting. However, the work is still largely synchronous at this stage.

Stop 3 - +Workspace

Next stop is Claude Cowork land (I’d also include Claude for Excel in this category). This is where you give the AI a proper desk and can let it run off and do large-scale projects on its own. Cowork gives your AI persistent files, a project space, and the ability to take action, all within nice, safe, protected sandboxes with guardrails. Copy a data room into a designated folder on your hard drive and have that AI analyze everything in it. Give it a pile of financial records and have it create a model. Think multi-file artifacts, longer projects, real document production, and heavy diligence. At this stop, I’ve dropped a pile of financial statements into a folder and told it to build me a model (it won’t one-shot this, but it’ll be shockingly close). I’ve also dropped full data room downloads into folders and had it map responses against our template request list before generating follow-up request lists. This is where AI is finally starting to feel like a real additional employee. This is also where I assume most people have to stop due to security restrictions at their companies.

Stop 4 - +Code

Moving to code is the final stop (Claude Code, Codex, whatever Gemini’s calling their coding suite this month). This stop is scary, especially for non-engineers, but this is where everything starts to feel possible. Now your AI has hands and can build its own tools. This allows it to automate repetitive tasks, run unattended, retain persistent memory, and much, much more. I’ve built a virtual investment committee that leverages Claude, ChatGPT, and Gemini to score opportunities against our strategy. I have a full multi-agent diligence team that works its way through a company’s data room before sending the independent analyses to another agent to synthesize and then red-teams those findings against independent agents from other models. I even built an entire indexed substrate over my entire work-life (Slack, email, calendar, CRM, notes) so the AI stops re-asking me for context. This is where AI moves from just being an assistant to actual infrastructure, and you don’t need to be a coder anymore to reach this stage. You can have the AI actively teach you while it builds. This is the spot where you never run out of things to do.

What’s Next

This is the beginning of a series on how I run agentic corp dev. Every other week, I’m going to post another installment that takes one of these stops or one lesson from each stop and goes deep. The concrete: how I built it, examples of what I built, the pitfalls, and things you should try. If you’re here for the super cool Claude Code stuff, be patient. At this pace, it might take me a couple of months to get there. I want to help more people get started and take this journey rather than just show it and have people look at it and go, “I have no idea how to build this.”

Here are some topics that are top of mind for future posts:

• Why I configured my AI to constantly push back2

• Why feeding it my own past deal decisions beats every prompt trick I tried

• What connecting your real systems actually unlocks

Up next, though, I plan to walk you through how I build my initial first-pass company screen in the plain chat window. How exactly I did it and where the AI tended to go off the rails.

Of course, like and subscribe3 and all that, so you get the next post!

For background, I run corporate development at Zapier. That means acquisitions, strategic investments, and everything that comes with them: sourcing, diligence, structuring, integration. I’ve been using AI in my workflows for a while now (I do work at an automation company after all), but everything I’m about to describe happened in the last few months.

First, some background. I’m not an engineer. I don’t have a CS degree. I’d never written a real line of code before January (building a website in HTML in high school doesn’t count). However, in late January, I finally tried Claude Code. It told me to create a GitHub account. I didn’t have one. So I did. That was my starting point.

Three months later, I have a full-stack automation platform (my “corp dev server”) that monitors hundreds of companies, triages inbound deal flow, researches targets across dozens of data sources, and helps me manage deal processes and diligence. All running locally on my laptop.

The system doesn’t just answer questions. It does the work. And it’s made me realize that the gap between “AI is just a hallucinating chatbot” and “AI is running my workflows” is smaller than most people realize. Here’s how I got there.

The Problem

Corp Dev at Zapier is a one-person show with enterprise-scale complexity. On any given week, I’m fielding banker teasers, evaluating acquisition targets, managing our pipeline, running diligence on active deals, tracking competitive intelligence, and coordinating with executives, targets, VCs, and advisors.

The information lives everywhere: Gmail, Slack, Airtable, Google Drive, Granola, data rooms, and multiple third-party research platforms. Before I started building these systems, keeping all of that in my head and staying responsive was the hardest part of the job.

The System I Built

What started in January with Claude Code walking me through my first Python script has grown into an interconnected operating system for corp dev. None of it was planned from the start. Each piece solved one problem, and solving it revealed the next one. Here are the pieces.

Auto-Enrichment Pipeline

When I add a company to my Airtable deal tracker, Claude automatically researches it across Crunchbase, CB Insights, company websites, and news sources. It pulls funding history, employee count, investors, HQ, stage, and even company logos.

The pipeline runs on three tiers: fast classification using a lightweight model (Haiku) for quick categorization, deep research using a more capable model (Opus) for detailed analysis, and scheduled refreshes using a combination of models for daily, weekly, and monthly updates. Over 500 companies are tracked with automated refresh cycles that catch acquisitions, new funding rounds, IPOs, and shutdowns. Every morning I get a consolidated email digest with only material news. Yes, other services can do this, but none allow the level of personalization and customization I’ve done.

Inbound Deal Triager

When a banker email hits my inbox, the system extracts attachments, de-anonymizes codenames (think “Project Helix”), and pulls internal context from Granola, Slack threads, Airtable records, and Gmail history.

Then it runs a three-model committee: GPT-5.4, Gemini 3.1, and Claude Opus 4.6 each evaluate the deal independently. Opus synthesizes a final verdict and then drafts a blurb summarizing the opportunity, adds it to my weekly exec update and stages a suggested reply in my gmail drafts, all written in my voice (which has its own calibration pipeline trained on my past writing).

Calibration

The system maintains a search index over nearly three years of corp dev history. When a new company comes in, it runs hybrid search (keyword plus vector) to find similar past deals and injects them into the committee’s context: “Here’s how Austin evaluated three companies like this one, and what the verdict was.”

This is the single biggest lever on verdict quality. Real calibration data beats prompt engineering every time. The system gets smarter with every deal I run, because every evaluation becomes training data for the next one.

Memory System

Claude learns patterns across enrichment runs: company name collisions, data source quirks, search tips, formatting preferences. It retains them permanently in a structured memory system in Airtable that auto-consolidates when it gets too bloated. This means the system doesn’t repeat the same mistakes twice and gets progressively better at navigating edge cases.

$acquire

I also built $acquire, a stripped-down version of the deal triager that runs as an internal Slack bot via Zapier. Anyone at the company can tag it and get an instant assessment of a potential target. It uses a single model with web search (no committee, no enrichment, no internal context, no memory), so it’s a fraction of what the full system does, but it’s available to anyone 24/7.

The Unlock: Zapier’s SDK

For most of this build process, connectivity was the real bottleneck. I had powerful AI tools, but was always constrained by what I could realistically wire together. Claude Chat had built-in connectors for a handful of tools. Claude Code could hit APIs directly, but that meant writing and maintaining custom integration code for every service. MCP servers covered some ground, but not everything. I was constantly bumping into the ceiling of what I could connect, which meant the system could never have all the context it needed in one place.

The Zapier SDK changed that. It’s currently in closed beta (I know a guy), but this is what’s coming. Once I wired it into Claude Code, I had programmatic access to Zapier’s 8,000+ app integrations through a single interface. No OAuth flows to manage. No API key juggling. No custom integration code to maintain. The SDK offloads auth management to Zapier, which is truly a nightmare for someone non-technical like me. Slack, Gmail, Google Calendar, Google Drive, Notion, Granola, Airtable, Jira, HubSpot, Linear, Todoist, and basically anything else with a Zapier integration became callable tools that Claude could use natively with the full power of each tool’s APIs. No more handcuffs or limitations.

This matters because the value of the system scales with the breadth of context it can access. A deal triager that can read your email but not your Slack threads is half-blind. An enrichment pipeline that can research externally but can’t check your internal meeting notes is missing critical signals. The SDK finally let me collapse all of those information silos so that all my context could live in one place for the first time. Everything I use is finally connected and fully accessible by Claude.

Without the Zapier SDK, Claude can write code. With it, Claude can operate.

What I’ve Learned

• Have AI teach you, not just work for you. I didn’t learn to code and then start building. I asked Claude Code to teach me as it built things. The AI was simultaneously my builder and my tutor. You can’t understand that compounding effect by reading about it. You have to start building, ship something small, and let the next problem find you.

• Calibration over prompting. The single biggest quality improvement came from injecting real historical evaluations as context. If you’re building any kind of decision-support system, your past decisions are your most valuable training data.

• Model diversity beats prompt diversity. Using multiple models from different providers as a committee produces better results than running the same model with different personas. The blind spots are different, and the disagreements are informative.

• Keep your data where it belongs. Everything runs locally, and every AI provider I use is on an enterprise plan with zero data retention. The enterprise tiers from all the major providers make this straightforward now.

• Everything is flexible. With conventional automation, you build a flow, it works until something changes, and then you’re back in the builder rewiring things. These AI-built systems understand what I’m trying to accomplish, not just the steps to get there. Updating them feels like giving new instructions to a colleague rather than rewriting a program. That speed of iteration compounds fast.

Where This Is Going

The pace of change is the real story. Three months ago, I’d never opened a terminal. Today, I was experimenting with running multiple Claude Code sessions in parallel across multiple terminal windows.

But three months ago, connecting AI to my actual tools was also the hard part. I spent more time engineering around limitations than doing my actual job. That friction is evaporating fast. The Zapier SDK collapsed most of it overnight. MCP adoption is accelerating. The major AI providers are adding native integrations every week.

What that means for the next year: less plumbing, more operating. I’m already at the point where most of my daily workflows just run. The deal triager works. The enrichment pipeline works. I’m mostly tuning and extending now, not building from scratch.

Within a year, I think the version of this system that required a three-month build process will be something a corp dev professional can set up in an afternoon. The underlying capabilities already exist. What’s catching up is the connectivity, the packaging, and the trust. The question for M&A teams isn’t whether to adopt AI. It’s how quickly you start building institutional knowledge into systems that compound, because the team that starts now will have years of calibration data by the time everyone else gets around to it.