Why Pin Uses Buttons, Not Chat — Architecture Trade-offs of a Consumer AI Runtime
For the last two years almost every AI product looks the same: a chat box that says "what can I help with?" Building Pin, we deliberately went the other way — buttons and templates are the main dish, the LLM is only a fallback.
That sounds unfashionable, but it comes from a very practical architectural trade-off. Here's why.
1. A counterintuitive decision
Pin is a "consumer-grade AI Skill runtime": drop a product's capabilities in, and it grows an interface on LINE / Telegram that an ordinary person can use with a few taps.
Most people would instinctively make it conversational: user types → LLM interprets → executes. We didn't. Pin's primary interface is buttons, Flex cards, menus; free-form typing is the fallback.
Why? Because our audience isn't engineers — it's ordinary consumers.
2. The consumer truth: they can't and don't want to write prompts
Engineers easily forget one thing: people who can write a good prompt are a tiny minority.
Faced with a blank chat box, an ordinary person's first reaction isn't "so much freedom, great" — it's "what do I even type?" They don't want an all-powerful assistant that makes them figure out how to ask. They want: open it, see a few options, tap one, done.
That surfaces the core trade-off: determinism vs cleverness.
- Free-form chat is "clever," but every line needs the LLM to interpret intent in real time — slow, expensive, and occasionally wrong (misread, mis-executed).
- A button flow is "dumb," but it's deterministic: tap "my listings" and you get listings, no misinterpretation, zero latency, zero cost.
For a consumer product people use daily, the reliability of determinism matters far more than the occasional brilliance of cleverness. So Pin demotes the LLM from "head chef" to "spare tire" — it only steps in for the long tail that buttons don't cover.
(This is also the fundamental difference between Pin and our other system, OpenClaw: OpenClaw is an LLM-first agent fleet for advanced, autonomous scenarios; Pin is a determinism-first entry point for ordinary people. Two ends of a spectrum, serving different people.)
3. Architecture: one SKILL.md, many surfaces
So where do those buttons come from? We didn't want to hand-build a UI for every product we connect.
The core is one SKILL.md — a product's "single source of truth": it declares the product's entities, its actions, its copy, and its multi-step wizard flows.
Pin reads that one SKILL.md and grows:
- a LINE / TG button interface (Flex cards, inline keyboards);
- an MCP server, so agents like Claude / Cursor can drive the same product (today mainly for agent tools to self-host, not a public service);
- a webhook receiver — the product pushes an event (e.g. "new lead"), and Pin renders it into an actionable notification delivered to the user's LINE / TG.
In other words: declare a product as one SKILL.md, and the consumer interface, the agent interface, and the notifications all grow together.
4. The seam: the product ships endpoints, Pin renders the interface
There's a design principle we care about here: keep the seam clean.
The product side (e.g. UD House) does one thing: expose clean APIs + declare a SKILL.md. The Pin side does the other: render that spec into a human-friendly button interface.
The two meet at the SKILL.md seam. The product adds an action without touching Pin's code; Pin changes a rendering without touching the product. One spec, many surfaces, neither locked to the other.
This already runs in practice: UD House and MindThread each declare their own SKILL.md, and the same Pin runtime grows their respective LINE/TG interfaces — we don't rewrite a frontend per product. (Pin is currently in private dogfooding — not yet open for external sign-up; we'll announce the public launch.)
Closing: the hard part of consumer AI isn't a stronger model
The biggest lesson from building Pin: for AI facing ordinary people, the hard part was never how clever the model is — it's "how do you get someone who doesn't understand it up and running in three seconds."
And the answer to three-second onboarding usually isn't better conversation — it's fewer choices, more deterministic buttons, a clearer next step.
Save the cleverness for the long tail that needs it; give determinism to the majority who use it every day. That's Pin's architectural choice.
Originally published on Ultra Lab — we build AI products that run autonomously.
Try UltraProbe free — our AI security scanner checks your website for vulnerabilities in 30 seconds: ultralab.tw/probe
