--- title: Branding the Agentic Web description: "A position paper and a midway-step review — ThinkingCap, September 2026" created: 2026-09-20 updated: 2026-09-21 authors: ThinkingCap R&D topics: [CapGPT] status: published canonical: https://console.thinkingcap.com/rd/CapGPT/Branding-the-Agentic-Web date: 2026-09-20 --- # Branding the Agentic Web *A position paper and a midway-step review — ThinkingCap, September 2026* ## The claim Websites are dead. Not the web — the *website*: the idea that a client visits your domain and reads your pages inside your chrome. What is replacing it is the **agentic web**: surfaces delivered *inside an agent host* — a Claude, a ChatGPT, an assistant embedded in someone else's product — where the host owns the chrome, the conversation, and increasingly the layout, and the provider owns capability and content. We have already stopped pretending otherwise in our own product. The Learner View is not a website; it is an app. That is why, when we built branding for it this week, we refused the website answer (themes, skins, custom CSS) and built something smaller and stranger: **seven declared values**. This document is about why that constraint is the whole point, what the MCP Apps specification says about where surfaces are going, and what we do next. ## Where we are: the midway step The branding system we just shipped for the Learner View is, deliberately, not a theming engine. A deployment gets exactly seven knobs: 1. **Brand colour** — one hex; buttons, active states, links, focus rings 2. **Accent** — optional second hex; badges and highlights 3. **Logo** — one image URL (or inline data URI), with a fallback chain to the client name as text; the favicon is derived 4. **Heading font** — from a curated list of ten 5. **Body font** — same list, defaulting to the heading choice 6. **Corner style** — sharp / rounded / pill 7. **Night-mode policy** — off / learner toggle / dark default Everything else — hover states, contrast-safe text-on-brand, tints, the entire dark palette, the type scale — is **derived by the shell**. There is no custom CSS, and there never will be. The values are validated data in a settings store (`brand.*` keys, branch-scoped with inheritance, audited, propagated in minutes), not stylesheets injected into a page. The reason this matters is not aesthetic restraint (though a client cannot make their app ugly with it, which is its own virtue). The reason is that **a brand expressed as seven data values is portable**. Anything that can read seven values can render the brand — our shell today, any other renderer tomorrow, including renderers we do not own and have never heard of. A brand expressed as CSS is trapped inside the one browser that loads it. That portability is the entire bet of this document. Hold it. ## Review: the MCP Apps specification The Model Context Protocol's Apps extension (`modelcontextprotocol/ext-apps`, the standardization track growing out of the community MCP-UI project and OpenAI's Apps SDK for ChatGPT) is the first serious spec for what a "website" becomes in an agentic world. Its anatomy, as of late 2026: **UI as a resource.** A server exposes an interactive interface — an HTML/JS bundle — as an MCP *resource* under the `ui://` scheme, MIME type `text/html;profile=mcp-app`. The host pre-fetches and caches it. A *tool* links itself to that interface through metadata: `_meta.ui.resourceUri`. When the tool is called, the host renders the linked UI inline in the conversation (or fullscreen, or picture-in-picture) instead of a wall of text. **The sandbox.** The UI runs in a sandboxed iframe. It has no ambient authority: no cookies of the host page, no DOM outside its frame, no network beyond its declared Content-Security-Policy (`resourceDomains`, `connectDomains`, declared up front in the resource's metadata). **The bridge.** Iframe and host talk over `postMessage` carrying JSON-RPC: the host pushes context down (tool results, theme, locale, display mode, viewport changes), the UI sends requests up — most importantly `call-tool`, letting the interface invoke the server's tools through the host proxy. The interface is never a page; it is a *live tool peer with pixels*. **Theming, host to app.** The host injects theme context — CSS variables for background, text, primary, radius, fonts — and the app is expected to style itself with them. The host owns the chrome and the mood; the app adapts. **Lineage.** OpenAI's Apps SDK (`text/html+skybridge`, the `window.openai` bridge) shipped the pattern first; MCP-UI proved it in the community; the ext-apps draft is the convergence. Multiple hosts — Claude, ChatGPT, others — will implement roughly this shape with roughly-compatible divergences for a while. ### What the spec gets right - **The host owns the chrome.** This is the death of the website stated as an architecture rule. Your identity does not arrive as your page's chrome; it arrives as content and behaviour *inside* the host's chrome. - **UI as a declared, cacheable, versioned resource** — not a URL you browse to but an artifact the host fetches, trusts as far as its CSP says, and renders where it chooses. - **Capability through tools, not endpoints.** The interface's actions are tool calls with schemas. The agent can drive the same surface the human does. That is the actual point of the agentic web, and the spec does not lose sight of it. - **The sandbox posture.** Declared CSP, no ambient authority. If we are honest, it is stricter than most websites we ship. ### What is missing, for us specifically - **Theming is one-way, and the wrong way for brands.** The host injects *its* theme downward; there is no standard channel for the *app to declare its brand upward* — "my primary is `#13a0e3`, my logo is here, my headings are Tahoma" — and have the host render *that*. Host-controlled theming answers "make my app look like your app." It does not answer "make my app look like *me* inside your app." That is the gap our seven knobs are aimed at. - **Fonts and licenses.** Brand typography as webfonts has licensing and loading implications the spec waves at. (Our answer — a curated list, which is also why Tahoma-as-system-stack joined the list this week.) - **Discovery.** A website is found by links and search. An agent surface is found by… what, exactly? Tool manifests, server registries, model familiarity. Unsolved, and it will be solved by whoever writes the best declarative metadata — again: data, not pages. - **Divergence.** The bridge dialects (Claude's, OpenAI's, the community's) will disagree in detail for another year. Betting on the *shape* (resources + sandboxed UI + tool bridge) is safe; betting on any one dialect today is not. ## What branding means in the agentic web If the host owns the chrome, then branding stops being decoration and becomes **declaration**. The unit of brand is no longer the stylesheet; it is the **manifest**: a small, machine-readable document that says *who this provider is* — colour, accent, logo, typography, shape, motion policy, voice — in values a host can honor *within its own chrome*. Notice what that is. It is exactly the seven knobs. The work this week was not "add some theming to the Learner View." It was writing our clients' identities as **structured data with a resolver, an audit trail, and inheritance** — the three properties a manifest needs once multiple renderers consume it. The shell derives everything else today; an agent host derives everything else tomorrow. The brand leads top-left in *our* assistant's bar this week; it leads wherever the host puts identity in *theirs* next year, without a renegotiation. Even the website's role survives, transposed: the guest home — the public `≈ thinkingcap.com` mini-site we just made configurable — stops being "the website" and becomes **the canonical public declaration of the brand** that the manifests are compiled from. The site is the source of record; the agents are the distribution. ## The direction Concrete, in order, each building on the last: 1. **Publish the brand manifest.** One endpoint per client serving the seven values + logo assets as a clean JSON resource. Trivial — the data already exists, validated, in `lv_settings`. This is the artifact the agentic web consumes. 2. **Deliver Learner View surfaces as MCP-app resources.** Our surfaces — transcript, credentials, badges, mailbox — are already component-isolated, already theme-driven, already behind a session bridge. They fit the `ui://` model almost suspiciously well. First candidate: read-only transcript as an app resource with a `call-tool` action to open the full surface. 3. **Bidirectional theme mapping.** When *we* are the host (our assistant already is one), accept host-style theme variables and map them onto the knobs. When *they* are the host, emit them. Spec-shaped either way. 4. **Guest and R&D homes as the agent-readable storefront.** They are markdown corpora rendered as structure — already the most agent-legible thing we publish. Keep them canonical; manifests compile from here. 5. **Refuse, as a matter of record:** custom CSS, per-client code, iframe-soup integrations, and any branding that cannot be serialized to JSON without loss. ## Why the midway step matters The temptation, when a client says "let me make it mine," is to hand them the browser: themes, skins, a CSS upload, a theming engine with four hundred options. That road ends with the brand trapped in our chrome, on our domain, useful nowhere else — a website, right on schedule, in the year websites die. We took the other road. The brand is already data. The web we are heading to runs on exactly that. --- *Written September 2026, the week the Learner View branding system shipped: seven knobs, one dialog, no custom CSS. Reviewed against the MCP Apps extension draft (`modelcontextprotocol/ext-apps`) and the OpenAI Apps SDK it converges with. The spec will move; the direction won't.*