What if the hardest part of pitching your bot startup isn’t the tech at all?
I’ve spent the last few years building conversational agents, automation pipelines, and the occasional over-engineered Discord bot that nobody asked for. So when TechCrunch revealed the next wave of VCs judging Startup Battlefield 200 contenders at Disrupt 2026, my first thought wasn’t about who these people are. It was about how brutally fast a live demo falls apart in front of people who evaluate pitches for a living.
The names: Nell Daly, Michael Palank, Aditi Maliwal, Chrystal Huang, and Grace Ge. They’ll be evaluating startups October 13-15 in San Francisco at Moscone West. And if you’re registering, rates go up on September 25 at 11:59 p.m. PT, with savings of up to $200 available before then.
Why a Judging Panel Matters to Bot Builders Specifically
Here’s what I’ve learned the hard way: agent-based products demo terribly under pressure. Not because they’re bad, but because they’re non-deterministic. A web app either loads or it doesn’t. A bot? A bot can technically work perfectly and still produce an answer that makes you look unprepared.
Five investors sitting in a row, watching your agent handle a live query, is the least forgiving environment imaginable for that class of software. There’s no “let me refresh.” There’s no “that’s a known edge case.” There’s a room and a clock.
So if you’re one of the teams in the running, or you’re building toward next year, the panel announcement is less a news item and more a deadline with names attached.
What I’d Actually Change in My Demo
I’m not going to pretend I know what any of these five investors want to see. I don’t, and anyone who claims otherwise is selling something. But I do know what breaks in bot demos, because I’ve broken all of it personally.
- Kill the live API calls you don’t control. Every third-party dependency in your demo path is a coin flip. If your agent calls a weather API to show off tool use, that API will rate-limit you at the worst possible moment. Cache it. Stub it. Be honest that you stubbed it.
- Show the failure mode on purpose. The most credible bot demo I ever watched included a deliberately ambiguous user input and showed how the agent asked for clarification instead of hallucinating. That single moment did more for trust than any accuracy metric.
- Have latency numbers ready. Not marketing numbers. Real p95 numbers from real traffic, even if that traffic is twelve beta users. Vague answers about speed read as vague engineering.
- Explain your orchestration in one sentence. If it takes you three minutes to describe how your agent decides what to do next, your architecture is either genuinely complicated or genuinely unclear. Either way, tighten it.
- Know your cost per conversation. Token spend is a unit economics question dressed up as a technical one. Investors ask it eventually. Better to volunteer it.
Three Days Is a Compressed Feedback Loop
The format matters here. Judging spread across October 13-15 means multiple rounds of evaluation, which means multiple chances to hear the same question phrased five different ways. That’s genuinely useful signal if you’re paying attention.
When five different investors independently poke at the same part of your product, that part is your weak spot. Not a matter of opinion. A pattern. I’ve gotten more architectural clarity from watching which questions repeat than from any amount of solo whiteboarding.
For those of us building bots, those repeated questions tend to cluster in predictable places: how you handle inputs you didn’t anticipate, what happens when the model is confident and wrong, and why a competitor with more funding can’t ship your feature in a quarter.
The Part Nobody Prepares For
Technical founders over-prepare the demo and under-prepare the narrative. I’ve done this. You spend three weeks making your agent handle forty edge cases, then spend twenty minutes the night before figuring out how to describe what it’s for.
The edge cases are invisible in an eight-minute pitch. The narrative is the whole thing. A panel of investors evaluating dozens of startups across three days isn’t grading your code. They’re deciding whether they understand what you built and whether they believe the market wants it.
That’s not a reason to build worse software. It’s a reason to spend real time on the explanation layer, the same way you’d spend real time on an API contract.
Disrupt 2026 runs October 13-15 in San Francisco. If you’re planning to attend, get your ticket sorted before the September 25 deadline. And if you’re pitching: stub the flaky API. Trust me on that one.
🕒 Published: