Building in the Age of Frontier Models: Why Frugality is My Go-To Architecture

Frontier models are innovating on a daily basis. In just the last few weeks, we've seen OpenAI release GPT-5.6 Sol, and Anthropic extend access to Fable. The capability trend is aggressively upward.

With this trajectory, our dependency on these systems is only going one way: up. But we are shifting toward truly agentic processes. The opportunity here is massive — huge time savings and instant expertise. The agent doesn't just execute; it helps you plan and dives deep into the technical weeds for you.

When talking to non-tech people about this, I often use a term that feels a bit pretentious, but it's accurate: non-deterministic. It's not "random" — that gives the wrong impression — but run the same prompt twice, the way these systems are actually deployed, and you shouldn't expect the same output twice.

Because these frontier models are non-deterministic and computationally heavy, my natural instinct is to optimise. Perhaps it's from my family's mining, working-class roots in the East Midlands, but being frugal is practically in my DNA — you extract something valuable once, refine it, and it keeps paying out long after the effort's spent. That's why the idea of a distilled capability approach is so compelling to me — call it capability mining, if the metaphor wasn't already doing enough work. Let's pick and choose when to deploy the massive frontier models, but when we do, let's ensure the outputs can be reused as much as possible. Build once, reuse everywhere.

Here's the part that took me months of actually building before I had a name for it: artifact distillation. Knowledge distillation compresses a model into a smaller model; artifact distillation compresses a model run into something deterministic. It's also how I deal with non-determinism in practice — you spend the expensive, unpredictable frontier model once, and make it produce something that replays identically, for free, forever: a schema, a catalog, a generator, a runbook. The model is the forge; the artifact is the tool. Everything that follows in this post is that one idea, applied repeatedly to problems nobody asked me to solve.

One honest caveat before any of this: none of it is my day job. It got built in the gaps — late nights, weekends, the hours that would otherwise have gone to Netflix (and, in the interest of full disclosure, this post is being written on a week off — make of that what you will). That's not incidental to the frugality argument, it's the actual constraint behind it: when the time is borrowed, you don't get to waste tokens any more than you get to waste evenings.

Problem 1: Tackling the Google Meet Time Vacuum

I'd actually started poking at Google Meet back in February 2026 — a voice-to-diagram add-on that hit a WebSocket wall and got shelved. When I picked it back up around April and May, the unlock that restarted it also introduced me to the Agent-to-User Interface (A2UI) protocol, which Google has been pushing hard to build from the ground up — part of a broader generative-UI moment, with the ecosystem (CopilotKit's AG-UI protocol, the MCP Apps paradigm) converging on the same questions from different angles. I decided to use it as an opportunity to "learn through building" by finding problems no one actually asked me to solve.

The Mission, take two: Make the A2UI protocol work inside Google Meet — a true corporate time vacuum.

I had to dive deep into Google's iframes and Content Security Policies (CSPs). My key takeaway? Google Meet is an absolute powerhouse of a platform. Using APIs like Gemini Live to handle real-time audio-to-text transcriptions, coupled with solutions like D2Lang to produce real-time architectural diagramming, was mind-blowing. Especially for someone like me, who started their IT career on an entry-level helpdesk back in 2004.

(A quick shoutout to Pierrick Voulet from Google, who gave me the final piece of the puzzle for the Gemini Live pattern inside Google Meet and got me curious about A2UI in the first place — I told the fuller, rawer version of that unblock, WebSocket handshake and all, on techmusings.)

The outcome of playing in this sandbox was that I ended up with a local environment where I could reproduce the Google Meet iframe environment, or even programmatically control a real Google Meet session via the Google Meet SDK and Cloud Run. I didn't even know about the Model Context Protocol (MCP) Apps paradigm at this point, but I was effectively living in it.

It felt incredibly cool, even if it's a difficult concept to communicate in an already noisy AI landscape. Ultimately, this environment upped my content management game and gave me a peek behind the curtain of WebRTC and iframes. I completely get why solutions like Riverside exist now. It's a brilliant space to operate in — even if it started as a time vacuum nobody asked me to pick up.

Problem 2: Getting Lonely in Google Meet (The Apps Script Pivot)

While experimenting with the future of meetings was incredible, I ran into a practical bottleneck: I was usually the only person in the meeting room, and it was getting a bit lonely.

It was time to move out of the Meet sandbox, pivot to Google Apps Script, and seriously beef up the catalog.

The idea was to explore how A2UI could be used on a platform utilised by millions. Apps Script was recently upgraded to a Google Workspace Core Service; it's highly accessible, comes with its own storage, handles OAuth seamlessly, and operates within iframes. In short, it presented plenty of new challenges no one asked me to solve.

Very soon, I had a catalog of over 450 atoms. I had started tracking A2UI back at protocol v0.8, and it was deeply rewarding to see that my initial interpretation of the paradigm aligned perfectly when Google dropped v0.9. Like a good student, I used that release as an opportunity to clean up my architecture and adapt to the evolving spec.

Through some marathon AI CLI sessions, I accidentally stumbled upon an elegant hack: turning a schema into an active Apps Script app.

[Natural Language Input] ➡️ [AI Agent via Catalog Schema] ➡️ [Instant UI Web App]

By deploying just one master app, others could test out my entire ecosystem simply by generating a base64 URL containing the schema they wanted to execute.

This became an architectural lifesaver for my personal budget. Cloud bills grow like weeds when you're experimenting, so tokenomics matter — and you get a massive amount of development bang for your buck with Claude on a personal budget.

The core takeaway here was massive. I had built an asset that elegantly proved a concept: Give an AI a catalog and some natural language, and it gives you a functional, tailored app on the fly, within an interface format you approve, without ever executing a traditional deployment. For a security-first enterprise, having a pre-approved, sandboxed environment like Apps Script controlling outbound actions via UrlFetchApp is incredibly compelling. It feels harmless, yet performs impressively.

Problem 3: Building a Surface-Aware Supply Chain

Problem 3 is a bit of a blur, because in parallel to building out the Apps Script system, I was working overtime to maximise the cross-compatibility of the atoms. I needed these components to render natively whether they were sitting inside an Apps Script iframe or a standard web page.

From the ground up, I designed a surface-aware approach — a discipline I'd first felt the shape of building a Google Meet Studio add-on on the same catalog (the kitchen-not-a-remote-control realisation, told in Substrate, Not Slides). I wanted a highly granular view of the components, which required mapping out a rigorous supply chain acknowledgment for any atoms sourced from open-source repositories like OpenUI.

Through these compounding experiments, my perspective on the declarative nature of Generative UI solidified. A2UI has to be fundamentally useful for humans, yet strictly declarative for agents. But it still felt a bit abstract because my method of sharing and wiring up these capabilities was still highly manual.

Don't take that on faith — the ATC Ops Deck is one payload rendering live ADS-B and METAR feeds as a slide deck, a fullscreen radar view, and a real-time traffic ticker, all from the same declarative source. That's the claim, live.

Problem 4: Falling Down the MCP Server Rabbit Hole

Which brings us to the next problem nobody asked me to address. I decided to stand up a dedicated Model Context Protocol (MCP) server. I wanted to see what this whole "MCP malarkey" was about, and get a concrete, production-grade view of how an AI agent actually consumes an A2UI catalog via a structured protocol compared to a raw system prompt in Claude.

I acquired the domain a2uicatalog.ai via Cloudflare and quickly came to appreciate just how much modern hosting has evolved. I migrated my code to a centralised repository, dove into Cloudflare Workers, and established a slick CI/CD pipeline. Now, the moment the repo updates, the live MCP server and the A2UI catalog update automatically alongside it.

Thanks to Claude and a furious development sprint using Anthropic's Fable, I suddenly had a fully functional, live, MCP-enabled pipeline.

And right on cue, the ecosystem shifted again: Google dropped the A2UI v1.0 candidate protocol specification.

My catalog was completely aligned with v0.9 and featured a few custom architectural choices that fit the paradigm but used a slightly different vocabulary. Aligning everything to the official v1.0 candidate spec was an absolute mountain of work. I ran three Claude workspaces in parallel — one on the schema migration, one on the renderers, one on regression — because at this scale the bottleneck isn't the model's capability, it's how many disciplined workstreams you can keep honest at once.

Generally, the models did a staggering job pulling the infrastructure forward.

Problem 5: The Distribution Channel I Didn't Want

This one I mostly did to myself. Google had published a mid-June piece walking through exactly how A2UI and MCP Apps fit together, and I still couldn't get my head around it. Partly proximity — I'd been living inside A2UI for months and had barely touched MCP — and partly some reflexive skepticism absorbed from the industry noise around it. Underneath the buzz it just read as "another API server," nothing I hadn't seen before.

So I pushed back on the A2UI GitHub discussion thread, and after enough rounds of me asking dumb questions and Claude patiently answering them, it clicked. My actual objection, once I said it out loud, was: A2UI over MCP makes no sense. A2UI is the good part — why would you push a declarative catalog down a dumb pipe?

That's not a coincidence I'd never seen before — it's the exact pattern from A2UI inside an Apps Script web app, and closer still to the Google Meet build in Problem 1: iframe, websocket, the same shape, except instead of the Meet SDK wiring the connection, it's MCP doing it.

I had Claude stand up a local environment to test the theory, and it held: best of both worlds, not a downgrade of either. I'd been treating MCP Apps as inferior to A2UI because it ships pre-composed content — opaque, not declarative. That's backwards. MCP is shaping up as a genuinely dominant distribution channel, with real developer-experience and agent-experience advantages, and from A2UI's side that means mix-and-match rather than either/or. Commercially, it means a catalog owner isn't obligated to show their work: you can render your catalog inside an MCP App iframe without disclosing that you're doing it or open-sourcing anything behind it. There may be good reasons some builders won't want that — but the pull toward reuse and community crowd-sourcing is, to me, one of A2UI's strongest instincts. That view might age; I'll take the risk of saying it now.

Where this lands (for now)

That translation story — what an AI-driven spec migration gets right, what it quietly gets wrong, and how you catch the difference — deserves its own post. So does what happened when I pointed the catalog at the MCP Apps surface and it turned out I'd accidentally built a spec-conformant View. That's Part 2.

But here's the scoreboard today, and the reason this post exists now: a2uicatalog.ai is live — 468 typed atoms, a working MCP endpoint, a freshly redesigned catalog where every card renders a live miniature of its own atom. One schema compiles into the renderers, the site, the agent prompts, and the protocol surface. The expensive models built it; the deterministic artifacts run it. My mining-town instincts are satisfied: nothing gets spent twice.

And here's the part I didn't anticipate when I started: the artifact isn't just cheaper than the model — it's more portable than the model. This same catalog has now been consumed three different ways: pasted into a system prompt, served as MCP tools, and delivered as an MCP Apps view. Three consumption protocols in as many months, and the artifact never changed. "Build once, reuse everywhere" undersells it — the artifact outlives the interface fashions too.

The frontier models will keep getting better, on somebody else's schedule.

I should be honest about how proven that actually is. It reads clean in a blog post; it's messier in practice. The first real test is coming through the MCP server itself: a frontier model composes from the catalog fluently, but early observations with Haiku suggest it isn't so simple down the model-capability curve — it can call the tools, but the moment a task needs judgment rather than lookup (which atom fits, when a payload's getting too large to inline) it stumbles in ways the bigger models don't. If the artifact only pays off when a frontier-tier model is doing the composing, the frugality math looks different than I've been claiming here. I don't have the answer yet. Consider this thesis open, not settled — finding the actual boundary gets its own volume, with before/after numbers rather than anecdotes.

Try the catalog

Part 2 next: the pipe changed twice in three months — v0.9 to v1.0 to MCP Apps — and the payload never did. The alignment deep-dive: three structural concepts that didn't survive the translation cleanly, the code review that found them, and how I accidentally built a spec-conformant MCP Apps View along the way. Follow the repo for the ping.