Most of us building bots don’t need more money. We need fewer bad reasons to spend it. That’s the contrarian case for paying attention to a capital allocator at a developer-heavy conference, and it’s why I think Jas Khaira’s session at TechCrunch Disrupt 2026 is the one I’d actually block off time for.
Khaira is global head of Blackstone N1, and he’s taking the Builders Stage with a talk called “Building the Next Generation of AI Giants.” Per TechCrunch, he’ll cover what Blackstone looks for when backing category-defining companies, how founders should think about capital as they scale, and what separates lasting businesses from early traction. Disrupt runs October 13-15 at Moscone West in San Francisco, with a theme built around enduring companies in the AI era.
Read that list of topics again as an engineer, not a founder. Every single item maps onto an architecture decision.
Early traction is a benchmark score, not a system
I’ve shipped enough agents to know the pattern. You wire up a model, a prompt, a tool-calling loop, and a thin retrieval layer. It demos beautifully. Three weeks later you’ve got a queue of users hitting paths you never tested, a token bill that scales linearly with adoption, and no way to tell whether a regression came from your code, your prompt, or a silent model update upstream.
That gap between a demo that works and a system that keeps working is exactly the gap Khaira is describing when he talks about traction versus durability. Investors look at it as revenue quality. We should look at it as engineering debt with a dollar sign attached.
The bot-builder version of the question sounds like this:
- If your best customer tripled their volume tomorrow, does your cost per task go down or up?
- Can you swap the underlying model without rewriting your orchestration layer?
- Do you have evaluation harnesses that catch quality drift, or do you find out from support tickets?
- Is the valuable part of your product the prompt, or the data and workflow wrapped around it?
Companies that answer those well look like solid businesses from the outside. The financial story is downstream of the technical one.
Capital as an architecture constraint
Khaira’s second theme, how founders should think about capital as they scale, is the one builders tend to skip. We treat funding as someone else’s department. It isn’t. Money determines what you’re allowed to build.
Cheap, patient capital lets you build your own inference stack, fine-tune custom models, and invest in eval infrastructure that pays off in year two. Expensive, impatient capital pushes you toward whatever API gets a feature shipped this sprint. Both are valid. But choosing one without knowing which you chose is how teams end up with an architecture that quietly contradicts their runway.
I’ve watched small teams burn months building abstraction layers for model portability they’d never use, while their actual bottleneck was a retrieval pipeline nobody had measured. I’ve also watched teams hard-code themselves into a single vendor’s function-calling format, then spend a quarter untangling it when pricing changed. Neither mistake is really about code. Both are about mismatched time horizons between the engineering plan and the money funding it.
What I’d want asked from the audience
If I get a mic at that session, my question isn’t about valuations. It’s about moats. When the model layer is a commodity you rent, what does Blackstone consider defensible? Proprietary data? Workflow lock-in? Distribution? Regulatory position? Because each of those answers implies a completely different build order for the rest of us.
The honest version of that answer would be more useful to bot builders than another keynote about agent frameworks. Framework choices are reversible in a weekend. Decisions about which data you own, which integrations you go deep on, and which parts of the stack you refuse to rent are not.
Why the framing matters for small teams
You might reasonably say that Blackstone’s criteria have nothing to do with a two-person team shipping a Discord bot. Fair. Nobody’s writing a growth check for your side project.
But the evaluation criteria of large, patient capital are a decent proxy for what survives. People who allocate at that scale are, by necessity, obsessed with what still generates value in five years. That’s the same filter you should apply when deciding whether to write your own vector store or pay for one, whether to chase a new model release or spend the week on observability.
Disrupt’s theme this year is enduring companies in the AI era. For those of us closer to the terminal than the term sheet, the translation is simpler. Build things that keep working when the hype cycle moves on, when the model underneath you changes, and when your usage grows by an order of magnitude. That’s not a funding strategy. That’s just good system design, with better incentives attached.
🕒 Published: