#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.