In my most recent post (May 1st post), I mentioned, "If you pitch to prove you are right, you get a pat on the back. If you pitch to find out where you are wrong, you get free consulting." I want to share more on where that came from.
This semester I got to demo two projects, Agent-Parry and Latent, at Capital Factory as part of a class. The teaching team (Josh Baer, Andrew Busey, Eric Hennenhoefer, and TJ Clark) said they were impressed, but the useful thing wasn't the compliment, it was the feedback. None of it was the kind of deep, mechanistic-interpretability discussion you'd get from an AI alignment crowd. It was highly practical and product-oriented, and it was exactly the reality check you need after a week of being buried in your own codebase.
The one-week constraint mattered, because building under that kind of pressure forces hard choices about what to show and what to fake. Demoing forces a different kind of hard choice: which of the things you built is actually useful, versus which you just found interesting to build.
Agent-Parry: the bricks, not the wall
Agent-Parry is a security proxy and evaluation suite for MCP-based agents. I built it to sit between an agent and its tools and inspect the JSON-RPC traffic going past, so it can flag and block things that look like adversarial probes. When you're deep in schema-driven adversarial probing, you assume the underlying mathematical defense layer is the most important part of the product. It's the technically interesting part, so it's the part you want to show.
But during the demo, the moment that actually landed wasn't the interception logic. It was when I showed how the automated RuleGenerator was creating YAML rules in real time that protected the agents going forward. The audience didn't just want to see a wall block an attack; they wanted to see the wall build itself in response to what the attack had looked like. The value was in the feedback loop, not the block.
Latent: a map is not a debugger
Latent was a different kind of lesson. I built it as a collaborative 3D workspace, basically Figma for neural networks, letting multiple users explore and annotate a model's architecture together. The instructors liked the 3D canvas and the real-time syncing, but they pointed at a gap I hadn't really wanted to look at: it would be significantly better if the tool actually told you why certain attention heads were misfiring.
They were right. The gap they were pointing at was basically the whole reason a user would actually open Latent twice, and it's one of those gaps I knew was there but hadn't fully sat with, mostly because there's only so much you can build out in a week.
That feedback has actually been rattling around in my head ever since, because I'll be in San Francisco soon to intern at Sentry this summer. Sentry's whole product is built around actionable error tracking for traditional software, and the obvious extension of Latent, the thing it would need to grow into to be genuinely useful, is something like Sentry for tensor activations: granular, state-aware tracking applied to a model's internal representations, so you aren't just seeing that something misfired, you're tracing where it came from. I'd never have framed the problem that cleanly without someone in the audience essentially saying "the map is nice, but where's the rest of it."
What demos are for
This whole experience reminded me a lot of the political scientist James C. Scott's concept of legibility, from his book Seeing Like a State. Scott's argument is that to manage complex, organic systems (a wild forest, a sprawling city, a peasant economy), authorities have to force those systems into simplified, measurable grids that can be read at a glance. The forest gets rationalized into rows; the city gets rationalized into blocks. The grid is never the real thing, but it's the only version of the real thing the state can actually work with.
Building software, especially under a one-week deadline, is existing in the forest. Demoing is the act of forced legibility. You have to translate the chaotic, half-finished reality of your codebase into a clean enough grid that a judge or a user or a potential customer can digest it in a few minutes. And when I demoed Agent-Parry and Latent, the lesson wasn't that I needed a better grid. It was that the grids I had built (the interception logic, the 3D canvas) were misaligned with what the outside world actually cares about (the closed feedback loop, the active debugger). The legibility test surfaced a misalignment I couldn't see from inside the forest.
When you build in a vacuum, you optimize for what you find technically interesting. Pitching to a room full of founders and investors forces you to optimize for what's actually useful. It's an uncomfortable transition, and it's exactly what the free consulting is for.
Things I referenced
- James C. Scott — Seeing Like a State (1998)