Cantrip
AI / Platform
Outcomes
cantrip-sdk validates rulesets at authoring time and executes them at play time. No schema drift between editor and runtime.
DM tools defined per-ruleset via Vercel AI SDK structured tools, so the AI stays in-system instead of hallucinating mechanics.
Overview
Cantrip is a multi-tenant TTRPG platform where game publishers ship rulesets and players run sessions with an AI Dungeon Master. The same architectural backbone as Chicknz (multi-tenant, oRPC, Prisma, Better Auth) but applied to a creative-tools domain: the AI is the host, not a chatbot.
Flagship ruleset: Zairoo, an Afrocentric original system that doubles as the platform's reference content while the editor and session experience are stress-tested.
Challenge
Existing virtual-tabletop tools force publishers into a fixed rules engine, and AI DM tools tend to be single-system. Cantrip splits the layer cleanly: an extractable rules engine SDK + a tenant-isolated session runtime + an AI orchestrator that knows the active ruleset's grammar. Publishers get authoring tools; players get a host that doesn't break character.
Tech stack
Architecture
Key features
AI Dungeon Master
Anthropic Claude orchestrates session flow, generates encounters, and arbitrates rules. Bound to the active ruleset's grammar so it stays in-system instead of hallucinating mechanics.
Ruleset Authoring
Publisher dashboard for shipping rulesets: character sheets, moves, tables, narrative tone. Same authoring layer that powers Zairoo also opens to third-party publishers.
Tenant-Isolated Sessions
Each session runs in a tenant-isolated context with its own ruleset, party state, and AI memory. Built on the same multi-tenant primitives as Chicknz, with every query scoped and every AI call sandboxed.
Lessons & tradeoffs
An AI Dungeon Master is only fun if it stays inside the rules. Free-form prompting drifts and starts inventing mechanics that don't exist. I bound the AI to a typed tool surface generated from each ruleset's grammar, so it improvises the story but never breaks the system.
The challenge
An AI DM that free-associates will happily invent spells and stats that aren't in the ruleset, which quietly ruins the game.
What I decided
I bound the AI to a strict, typed tool surface derived from the active ruleset's grammar instead of prompting it in prose.
What I took from it
AI agents stay in character only when their tools are typed. Constrain the surface and creativity becomes safe instead of chaotic.
The challenge
Publishers author rulesets in one place and players run them in another. Any drift between authoring and runtime and a ruleset that 'saved fine' breaks mid-session.
What I decided
I shipped one engine, the cantrip-sdk, that validates rulesets at authoring time and executes them at play time.
What I took from it
An SDK shipped alongside the platform is worth the dual-target tax. A ruleset that validates is one that runs, by construction.
The challenge
I needed tenant isolation again, this time on a creative-tools product that looks nothing like a family chore app.
What I decided
I reused the same tenantId query-scoping pattern from Chicknz rather than reinventing isolation for a new domain.
What I took from it
I didn't reuse a single line of Chicknz's code in Cantrip, I reused its tenant-scoping pattern. The pattern travels between products; the code doesn't.