Lab Notes · mycuppa.io

From @mycuppa/* to Cuppa Harness: what survived

2 May 2026

Building in the open means showing the discards. mycuppa.io is the sandbox: experiments, prototypes, and the things that never quite earned a featured spot. This is a retrospective on six R&D pieces we shipped under the @mycuppa/* line in V1 — what graduated to Cuppa Harness, what turned out to be premature, and what quietly became something else entirely.

The V1 lineup

Six pieces, all sitting on the framework-ai shelf circa 2024:

Three graduated. Two were cut. One became a different product.

What graduated

MCP Client → ReplyService. The V1 client tried to be everything at once: provider abstraction, streaming, retries, rate-limit, context windowing, error fallback. Six concerns in one surface. What survived into Cuppa Harness is only the provider abstraction, collapsed to the smallest possible protocol:

public protocol ReplyService {
    func reply(to request: ReplyRequest) async throws -> ReplyResponse
}

The other five concerns didn’t disappear — they got separated. Streaming is a ReplyChunk extension that providers opt into. Retry-with-correction is a wrapper (ResilientAgent). Output repair is its own ladder. Rate limit lives at the call site. Each concern stands alone, composes by choice. The V1 monolithic client was the wrong shape; the harness is the right one.

Context Manager → memory patterns. The V1 doc promised “smart context truncation to stay within token limits, multi-turn conversation tracking, privacy controls.” What we actually built into the iOS app — and have now extracted into Harness — is more honest: a small set of patterns (conversation buffer, retrieval scaffolding, summarisation rolloff) rather than one opinionated manager. The good idea was that context engineering is its own discipline. The bad idea was wrapping it in a single class.

Chatbot UI → the Cuppa app. The SwiftUI components never shipped as a package. The thinking — message threading, rich media, typing indicators — fed into the iOS app’s Reply card and Council moderator views. Different product, same components, proven in production.

What was premature

Custom Skills + Skill Registry — both cut. The bet was that people would publish reusable MCP-protocol task modules to a central registry, like npm for AI skills. In 2024 this looked right. By late 2025, two things made it obviously premature:

1. MCP itself was unstable. The protocol shape moved several times in V1’s lifetime; building a registry on top was building on sand.
2. Models got better. A “skill” that wraps summarise this document is just gpt-4o-mini with a system prompt. Models absorbed the long tail of skill-shaped problems faster than a registry could ever publish them.

Lesson: don’t build a platform for an ecosystem that hasn’t formed yet. Build the patterns first; let an ecosystem form around them if it wants to.

What became something else

Prompt Templates → cuppa.studio. The V1 promise was “100+ pre-built prompt templates, variable substitution, chain-of-thought, few-shot examples, version control.” That’s a respectable JSON catalogue. What we shipped instead is a tool where the prompt disappears — you describe what you want in plain English, the AI produces a 12-slide animated deck, you refine with follow-ups. The template idea wasn’t wrong; it was just the wrong surface. People don’t want to manage templates. They want the templates to be implicit in the tool that does the thing.

That insight — bury the prompt, surface the artefact — is what became cuppa.studio.

The lesson

V1 was spec-first: pick a buzzword (MCP), ship a vendor (@mycuppa/*), hope the ecosystem caught up. V2 is extraction-first: build a real product (the Cuppa app, cuppa.studio), notice the patterns that keep working, lift them into a reusable layer (Cuppa Harness).

The patterns you extract from production code that already worked are durable. The ones you specify in advance are mostly wishful thinking.

If you’d asked us in 2024 which of the six V1 pieces would survive, we’d have said all six. The half that survived only did so by shrinking back to the protocol shape and leaving the rest as composable wrappers.

What mycuppa.io is now

Less of a “platform of @mycuppa/* packages”, more of a working notebook. New experiments land there first; the ones that earn their keep graduate to a featured spot on this site or into the Harness library. If something doesn’t graduate, we leave the source up anyway — building in the open means showing the discards.

Open the lab → · Read about Cuppa Harness →