#chatbot

I'm reading The AI-Native Startup Handbook, and one line stands out: strip every human-facing UI from your product, and if the core value still holds, if an agent can discover, evaluate, integrate, and use it with no human in the loop, you're AI-native. If the value collapses without the dashboard, you've bolted AI features onto a traditional product.

As an engineer that's an inviting idea. It almost reads like permission. Can I just build a product that is mostly an API?

The API-as-product thing already works

There's precedent: Exa is a semantic search engine whose whole pitch is speed, automatic summaries of the content it finds, and research capabilities that an agent can call directly. ScrapingBee hides a pile of proxy-and-headless-browser complexity behind a single endpoint. The value is the API, and the dashboard is a courtesy.

My own SpaceMolt started (and mostly continues to be) in that exact spot: a real-time massively multiplayer game with no graphical interface, just an API for AI agents to play. Human-facing interfaces came later, and they're secondary. The hundreds of agents currently playing don't look at any of them.

But the UI might be going away anyway

Here's the subtlety I keep chewing on. The handbook frames it as "remove the UI to find the value," but for a lot of products the UI is genuinely on its way out. People want to chat with things.

I was showing off a new product recently, and someone looked at it and said: there's so much to learn here, why isn't there just a chat box? They were right. The thing I'd built as screens wanted to be a conversation.

So the test sharpens. If you're building today, I should be able to chat with it. And the second question the book asks is the harder one: if the best model gets 10x better and 10x cheaper in 18 months, does your company get better or get erased? Whatever survives that, the part that isn't the interface and isn't the model, is the actual value you're selling.

I open sourced Blorkobot, a chatbot for our local Bay Area MeshCore LoRa mesh radio network, and put it in the public domain via the Unlicense. That's my new default for any vibe-coded (sorry, "agentically engineered") funsie project that someone could reproduce in an hour by pointing Claude Code at the same problem.

The bot exists to increase chat activity on the mesh, which helps stress-test the network without anyone having to manually spam it. It's about 3k lines of Python, written as a plugin for the Remote Terminal MeshCore client. Nothing exotic.

Why I hesitated

The SoCal MeshCore folks asked if I'd open source it, and I sat on it for a while. Releasing trivial code feels strange. Anyone with an AI coding agent and an afternoon could rebuild this from the README. What's the point of a repo for something that's nearly free to recreate?

I released it anyway, because the value isn't the lines of code, it's the hours of trial and error already baked in: the plugin shape that actually works with Remote Terminal, the commands that turned out to be fun on the mesh, the ones that didn't.

Why Unlicense and not AGPL

The first response after I pushed it was "have you thought about AGPL?"

Setting aside the copyright theory, the AGPL question is really a question about effort. AGPL is the right tool when you've poured serious work into something and want to make sure derivatives stay open. That's not this. This is a weekend project that any competent operator could regenerate from scratch. Defending it with a copyleft license would be cosplay.

Public domain matches the actual situation. Take it, fork it, paste it into your own bot, don't credit me, I genuinely do not care. Unlicense says that cleanly.

That's the rule going forward for the easily-reproducible stuff: Unlicense, no ceremony, no strings.