Why we built SeldonFrame on MCP

The default architecture is wrong

If you've shipped an AI product in the last two years, you know the default playbook. Pick a frontier model. Wrap it in a React app. Add tool calls for the few actions your product needs. Sell access by the seat. The user types into your input box; your backend orchestrates the model; your UI renders the result.

This was the right choice in 2023 because models were thin and fragile. You had to handhold the LLM through every interaction. The chrome was the product because the chrome was the entire surface area where intelligence couldn't be trusted to operate alone.

That's not where models are now.

What changed: agents have IDEs

Claude Code, Cursor, Windsurf, Devin — agents now live inside the developer's IDE. They read files, run shells, call APIs, write code. They don't need a custom chrome because they already have one. The chrome is the IDE.

And critically: those agents speak MCP — Model Context Protocol — Anthropic's standard for letting an LLM call into external systems. If you ship an MCP server, every MCP-aware agent can drive your product.

The bet: expose everything as tools

SeldonFrame's product is a Business OS — CRM, public site, agents, automations. The competitor playbook would be to ship a beautiful React admin and call it a day. We did that, but we also did something else: we exposed the entire product as 140+ MCP tools.

Read your contacts. Create a deal. Build a chatbot. Configure its Soul. Run an eval suite. Publish the agent. Read its conversations. All as tool calls. Every clickable surface in the dashboard maps to one or more MCP tools an agent can drive.

This means: an HVAC business owner can build their entire customer-operation stack by talking to Claude Code. They don't have to learn the dashboard. The dashboard is for inspection and overrides — not for the build.

Why this works

Three reasons.

One — the agent is faster than the human at click-through. Building a chatbot through the dashboard is 8-10 clicks, field entries, eval-suite setup, publish gate. Through Claude Code it's "build me a chatbot for my HVAC business that books diagnostic visits" — the agent calls 3-4 MCP tools, runs evals, publishes. Two minutes, zero clicks.

Two — the agent improves automatically. When Claude Sonnet 4.5 ships, every SeldonFrame customer's build experience gets better — without us shipping anything. The same is true for the runtime: agents in production that use better LLMs make better decisions, with no SF-side changes. The architecture is antifragile to model improvements.

Three — the dashboard stays simple. We don't have to design a "build wizard" with progressive disclosure for every config option. The dashboard is foroperating what's been built, not for the build itself. Operators see a simple "your agents" list and a "your customers" CRM. Builders use Claude Code.

What we gave up

Marketing-page conversions. A first-time visitor who doesn't already use Claude Code can't immediately experience the magic. They have to install the MCP server, paste a token, and learn a new flow.

That's a real cost. We mitigate it two ways: (1) the dashboard is fully self-serve, so non-Claude-Code users can still build everything by clicking; (2) the launch video shows the Claude Code flow end-to-end, so visitors see the magic before they have to install anything.

But if you take nothing else from this post: the architecture choice between "build a chatbot UI" and "expose as MCP tools" isn't aesthetic. It's a bet on whether agents-in-IDEs become the dominant chrome for non-trivial software. We bet yes.

What's next

More posts in this series will cover the eval gate (how an 8-scenario suite gates publish + a runtime validator catches hallucinations on the fly), the BYOK economics (why we don't markup tokens), and the durable-workflow architecture (Vercel Workflows powering post-booking reminders that survive deploys).

Follow @seldonframe on 𝕏 for new posts, or join the Discord if you want to talk to the team about the architecture.