← All articles Vision

Why we built OBTO headless-first

OBTO Team · Insights from the Glass Box

Most AI platforms start with a chat box. It's the first thing you see, the thing the demo revolves around, the thing the screenshots sell. We went the other way. The model providers already build excellent chat — Claude, ChatGPT, Cursor — so we didn't try to out-build them; we put our energy into the part none of them owns for you: the tools and the audit trail underneath. OBTO started there and treated the interface as optional. That choice still surprises people, so it's worth explaining what "headless-first" actually means — and why we'd build a company around it.

The durable layer of an AI system is the governed tool and the record of what it did — not the surface you happened to type into.

That's the bet in one sentence. Chat boxes are commodity, and they're temporary. The model behind one gets deprecated and repriced. The client changes: last year your team lived in a single chat app, this year it's three, next year it's an agent with no human in the loop at all. If you build your platform around the surface, you rebuild every time the surface moves. We didn't want to keep rebuilding, and we didn't want to make our customers rebuild either.

What headless-first actually means

Concretely, the unit of the platform is a tool, not a screen. On OBTO an MCP tool is a record — a name, an input schema, and a handler — that you create, version, diff, and roll back at runtime. It isn't a function compiled into a binary you redeploy to change. It's data. That sounds like a small distinction, and it's actually the whole thing: when your tools are data, you can ship one today, change it next week, and audit every version in between, without taking anything down and without touching a UI.

Because the tool is the unit, anything that speaks the Model Context Protocol can call it — Claude, GPT, Cursor, your own application, a scheduled job, another agent — the same tool, with the same guarantees, no per-client rebuild. The interface becomes a detail. You bring the model and the client; the tool stays put.

Why governance has to live below the UI

The deeper reason is trust. Most of the hard requirements on an AI system — who's allowed to do this, which version ran, what exactly happened, can we prove it later — are not UI features. Implement them in the chat layer and they evaporate the moment a different client calls in. So we pushed all of it down to the tool boundary: authentication at the edge, versioning on every artifact, and a per-call record we call the Glass Receipt that fires whether the caller is a person in a chat window or a headless agent at three in the morning.

Governance you can only see in the dashboard isn't governance; it's decoration. Putting it underneath the interface is what lets us promise the same audit trail to every caller. It's the same instinct behind why we engineered around vendor lock-in: keep the things that have to last outside of any one model or client.

What we gave up

Headless-first is not free, and it would be dishonest to pretend otherwise. The cost is the cold open. A chat-first product hands you a "wow" in thirty seconds: type a sentence, watch something happen. Ours asks you to think first in tools and contracts, which is a slower and less magical first five minutes. Some people want the chat box on day one, and we don't have a flashy one to give them.

We made that trade on purpose. The demo is worse and the second year is much better. The teams who feel the difference are the ones who, eighteen months in, have swapped models twice, changed clients, and passed a security review — and never once had to rebuild their integration, because the integration was never tied to any of those things.

The shape that falls out of it

Build on this premise and the architecture mostly writes itself. The app is data, so the platform is queryable like data — tools, routes, pages, and policies are all records you can read, search, and version. The Glass Receipt is a default, not a setting, because an agent you can't inspect is an agent you can't responsibly run in production. And because none of it depends on a particular front end, the same backend serves a public web app, an internal tool, a Slack bot, and a fully autonomous agent without forking. We didn't design that on a whiteboard; it's what you get when you refuse to let the UI be the source of truth.

The interface is optional; the ownership isn't

There's a line we keep coming back to: describe it, ship it, own it. Headless-first is how we make the "own it" part true. If the valuable thing were the chat surface, you'd own a skin and rent the substance. By making the tool and its receipt the center of gravity, what you own is the part that lasts — the governed capability and the proof of what it did — no matter which model is in fashion or which client your team opens tomorrow. The chat box, if you want one, is a thin layer on top. It was never the point.

That's the case for headless-first, and it's why OBTO looks a little different from the rest of the category. If you'd rather see the substance than a chat demo, the platform overview is the honest version, getting started puts a real tool and a real receipt in front of you in a few minutes, and pricing starts at zero. It's also the foundation under how we think about an AI workforce — agents you can trust with real work, because the work is governed where it lives.

See the substance, not a chat demo

Governed MCP tools, versioned at runtime, with a per-call Glass Receipt by default.

Get started

More from the OBTO blog