One Backend, Many Products: How a 'Skill' Lets Us Ship a New AI Agent Without a New Backend

A curriculum-grounded tutor for secondary school students and a marketing brainstorming tool that grounds ideas in saved reference videos sound like they'd need two completely different systems. On our harness, they run on the exact same reasoning loop, the exact same approval logic, the exact same memory system, and differ in exactly one place: a small object called a Skill. That single abstraction is what lets us ship a genuinely different AI product without touching, forking, or rebuilding the backend underneath it.

The alternative we didn't want: a new backend per product

The obvious way to build a tutor and a marketing tool is as two separate projects, each with its own way of calling a model, its own history handling, its own approach to what the AI is and isn't allowed to do unsupervised. That's exactly the pattern we moved away from when we built the harness in the first place, because it means every new AI idea starts by re-solving problems that were already solved, correctly, the last time, and any bug fix or reliability improvement benefits exactly one product instead of all of them. A tutor and a marketing tool don't actually need different infrastructure. They need different instructions and a different set of capabilities.

A useful comparison: think of it like an operating system and its apps

The relationship between the harness and a Skill maps reasonably closely onto the relationship between an operating system and the apps running on it. The operating system handles memory management, device access, process scheduling, the unglamorous infrastructure every app needs and none of them want to rebuild themselves. An app declares what it does and which system resources it needs, and trusts the operating system to actually provide them reliably. Nobody expects a calculator app and a video editor to share a single codebase just because they run on the same machine, and nobody would want either of them re-implementing memory management from scratch to prove independence. A Skill is the app. The harness is the operating system underneath it, and the boundary between the two is exactly as deliberate as it is in that more familiar analogy.

What a Skill actually is

Structurally, it's about as simple as it sounds: a name, a system prompt, and a list of tools that Skill is allowed to use. That's the entire seam where products diverge. Everything else, the loop that calls the model and handles tool calls, the approval gating, the memory system, the self-monitoring pass, is shared, unaware of and indifferent to which Skill happens to be active for a given conversation. The reasoning loop doesn't know or care whether it's teaching physics or brainstorming a video hook. It just knows which system prompt to load and which tools it's allowed to hand the model this turn.

Three real Skills, one backend

It's easier to see the value of this by looking at how differently scoped three actual Skills running on our harness are. One is a minimal example Skill with a single tool for fetching a YouTube video's transcript, useful for demonstrating the pattern end to end without much else going on. Another is a tutoring Skill with three tools, a curriculum lookup, a worked-solution lookup, and a quiz-attempt recorder, and a system prompt that reads nothing like a general assistant's, explicit instructions never to invent a formula, to walk through reasoning steps rather than just stating an answer, to record every graded attempt against a named student. The third is a marketing Skill with exactly one tool, a reference lookup, and a system prompt oriented entirely around grounding brainstormed ideas in saved inspiration rather than generic advice.

Three products, three genuinely different jobs, three completely different personalities and capability sets, and not one line of the underlying reasoning loop, approval system, or memory system had to change to support any of them. Adding a fourth Skill tomorrow, for a different client with a different job entirely, follows the same pattern: write a system prompt, decide which tools it needs, done. That's the entire cost of a new product idea at the architecture level, not a rhetorical simplification.

How the harness knows what a Skill can do

Each tool a Skill lists gets resolved into a name, a description, and a validated input shape that the model actually sees when deciding what it can do this turn. A registry looks tools up by name when the model asks to call one, and it deliberately doesn't know anything about what a tool does internally, only how to find it and hand it the model's input. That indirection is what keeps the loop itself completely unaware of the specifics of any one product: it asks the registry for "the tool named X in this Skill's list" and gets back something it can call, the same mechanism whether X is a curriculum lookup or a video reference lookup.

What stays constant, and what's actually allowed to vary

• Constant across every Skill: the reasoning loop, approval gating logic, cross-session memory, the agent's own private database, and the self-monitoring pass that watches for warning signs
• Constant across every Skill: the streaming protocol, session persistence, and the reliability guarantees around retrying and idempotent execution
• Variable per Skill: the system prompt, meaning the actual job description and personality
• Variable per Skill: the specific tools available, meaning exactly what actions that product's agent is capable of taking at all

That split is deliberate and it's the entire design principle: reliability infrastructure is expensive to get right and shouldn't be re-litigated per product, while the actual job a given AI agent does is genuinely specific to the business it's serving and should be free to vary completely.

What actually differs between the tutor and the marketing tool

It's worth being concrete about how far the divergence actually goes, since "they run on the same backend" could sound like it understates how different these products feel to use. The tutoring Skill's system prompt reads like a job description for a patient, encouraging teacher, with explicit instructions never to invent a formula and to walk through reasoning step by step. It's given tools to look up real curriculum content, fetch real worked solutions, and record graded attempts against a named student. The marketing Skill's system prompt reads entirely differently, an assistant helping brainstorm content ideas, with a single tool for pulling up saved reference videos. Neither Skill's instructions mention the other's existence, neither would make sense running the other's job. What they share isn't a personality or a purpose, it's the machinery underneath both: the same reasoning loop, the same approval discipline, the same memory system, applied to two genuinely unrelated problems.

Why this matters for how fast we can actually ship

The practical payoff shows up the moment a new client project starts. Instead of scoping a new AI backend, a new database schema, a new approach to handling a failed step, the actual engineering work is defining a Skill: what should this agent's system prompt say, and which tools does its job actually require. The infrastructure question, is this reliable, is it safe, does it remember what it should, was already answered the first time, and every product since has inherited that answer rather than re-earning it from scratch. That's a meaningfully different starting point for a new AI product than most agencies or in-house teams work from, and it's a big part of why we can take on a genuinely new AI use case for a client without every engagement turning into a from-scratch infrastructure project.

The discipline this actually requires

None of this works if the core loop quietly accumulates Skill-specific logic over time, an if-statement here for the tutor, a special case there for marketing, until the "shared" backend is really just several products awkwardly sharing a file. Keeping the loop genuinely agnostic to which Skill is running is an ongoing discipline, not a one-time architectural decision, and it's the thing we actively guard against every time a new Skill's requirements tempt a shortcut. The moment the core loop needs to know which product it's serving to behave correctly, the abstraction has already started to leak, and the whole point of building it this way starts quietly eroding.

The test we actually apply is simple to state even if it takes discipline to hold to: could a brand new Skill, with a system prompt and tool list nobody's thought of yet, be added tomorrow without a single line of the reasoning loop changing? As long as the answer stays yes, the architecture is doing its job. The day it stops being true is the day "one backend, many products" quietly turns into "one backend, many special cases," which is a meaningfully worse place to be than just building four separate backends honestly in the first place, because at least then the coupling would be visible instead of hidden inside a system that still looks unified from the outside.