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.

Disclosure: Ultra Lab, MindThread and Ultra Advisor are products of the same group, Ultra Creation (傲創實業).

#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" but "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: as of 2026-06-12, 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 (as of 2026-06-12, 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. a real-estate platform we built) 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: A real-estate platform 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. (As of 2026-06-12, Pin is in private dogfooding and 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, but "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 but 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.