On Keeping a Secret at the TableA noncommercial project’s moat · And a few things I decided not to build

There is an old custom in tabletop RPGs. When a player wants to do something in secret, without the others at the table knowing, they pass a little note to the game master. The game master carries the truth of the whole world in their head: who the murderer is, what lies behind which door, who is being betrayed by someone else without yet knowing it. They have to tell the same story to four or five people at once, while letting each person know only the part they are supposed to know.

The hardest thing for a good game master is knowing how to hold their tongue.

When I was building OurRPG, this was the first question I worked through: if an AI is the game master, can it hold its tongue?

There is something else I should say first: OurRPG is not a commercial project. I have no plans to make money from it, and no one is holding me to a growth target. This needs saying because, in a proper business, probably every one of the things I have decided not to do below would be a mistake. Each means fewer users and one less growth story to tell investors. But this is not a business, so that calculation does not apply here.

What happens when everything goes into one pot

Most AI tabletop RPGs and text adventures available now have much the same structure: take one large model, put the world setting, every clue, and everyone's conversation history into one pot, and ask it to keep writing. With one player, that works fine. It can be quite enjoyable. Put two or more people together, and things go wrong immediately.

A player casually bluffs, and the model spills a truth before its time. On your own screen, you can see what a teammate just did behind your back. After a couple of rounds of probing, every secret an NPC holds comes out. Put plainly, the Keeper has had too much to drink and cannot keep their mouth shut. Whatever you ask, they answer, including things they should never say.

The problem is structural. In May 2026, I went through eight open-source AI tabletop RPG projects on GitHub, one by one (aidm, dzmm, NarrativeEngine-P, TRPG-Agent, and others). Not one of the eight truly kept information separate. Even those with multiple agents, such as aidm, had one main agent writing the story with the entire context, while the other agents handled odd jobs like classification, validation, and summarization. The “one model, everything in one pot” structure itself leaks. Patches on top will not seal it.

So how do we actually do it?

I can talk about the architecture. I will not go into the implementation details; those belong to the project.

We use several layers of AI, each doing its own job. The layer furthest behind the scenes knows the whole truth, but never says a word directly to players. It only sends instructions down. The layers in front turn those instructions into what players actually see: one layer handles the public narrative that everyone can read, and a separate layer handles the private clues each person receives.

The key is that the software gives each layer access only to its own share. When a prompt is assembled for a layer, data it should not see is simply left out. Writing “please do not spoil anything” in a prompt does not work. However politely you ask, it will still leak what it was going to leak. I gave up on that very early. Now we keep it in check with three things together: multiple agent layers that divide responsibilities, orchestration in code, and prompt engineering. That makes holding its tongue a matter of structure, without having to gamble each session on whether it will behave this time.

I have a bias here, perhaps one that many people do not share: how well this kind of system performs depends mostly on the layer around the model. Are the prompts well written? Are the constraints on the model well designed, and do they work smoothly in practice? There are only so many models, and everyone has access to much the same ones. So I put my effort into that layer, instead of waiting for the next, stronger model.

What I can say is that this approach means it can only run on cloud servers. The reason is in § 05.

What OurRPG is, and what it is not

It is a Chinese-language tabletop RPG platform combining Chinese folklore with mild horror, using simplified rules for CoC 7th edition and DND 5th edition, for two to four people to play together online. Open it and play. No client to install, no API key to obtain yourself, no need to understand plugins or scripts.

It is not a general-purpose text-game sandbox into which you can put anything. It is not solo role-playing with a chatbot. Nor is it a tool for technical enthusiasts to tinker with settings.

I have a very specific group in mind: Chinese-speaking players who want to play tabletop RPGs but cannot get enough people together, cannot find a friend willing to be the Keeper, and do not want to install SillyTavern, set up a model, and tune a pile of parameters themselves. Just that group.

“Open it and play” is deliberate

“No keys to configure, nothing to install” was a deliberate decision, made after thinking it through.

People who can install SillyTavern themselves, buy model credits, import character cards, and adjust temperature already have their own setup. It works well for them. They do not need me. I am trying to reach a different group: people who have heard of tabletop RPGs and really want to try, but get stuck at the very first step, “find a Keeper.” They fall back on trying to play with AI by themselves, then see a tutorial telling them to install this and configure that, and give up. For these people, being able to open a browser and play is not a reduction in features. It is the only way in.

So I have mostly declined suggestions such as “why not let users connect their own models?” or “why not offer more settings?” Every extra thing to configure turns away another group of the people I actually want to reach.

Why I will not build a local client

People have urged me to do this many times, and I have wavered myself. The suggestion sounds sensible: build a local client, keep the data on players' own computers, and they will not lose their saves or worry about leaked chat histories. Users will feel more at ease. Some also say a client makes it easier to keep users coming back. That is true.

But I have firmly decided against it.

Holding its tongue depends on the layered structure described above, and that has to run on a server. Once it becomes a local client, model calls happen on the player's own machine. The truth of the entire world and everyone's private information are immediately in that player's hands. The Keeper has laid every hidden card on the table. Making it local would mean dismantling this structure myself, leaving just another of the countless model wrappers already out there.

I address those two concerns in other ways. For lost saves, we have three layers of backups (scheduled daily, manual before deployment, automatic before migration), and so far we have never lost one. For leaked chats, the protection should come from a privacy policy and a promise never to use them for training. Moving the whole project onto local machines for those two concerns would cost too much and would not address the right problem.

A few other things I will not do

I will not support SillyTavern character cards. I know this is the most tempting option: most commercial AI chat products are now rushing to add SillyTavern compatibility because it lets them draw users directly from there. But those cards were designed for “one person, one model.” They do not fit our layered structure for keeping information separate. Force them in, and that separation breaks. There is also a lot of borderline sexual content in the SillyTavern ecosystem. I want to make something I can openly stand behind and keep working on for a long time; I cannot take on that compliance risk. The users drawn over would not be coming for what I am building anyway. They would not stay, so there is no need to compete for them.

I will not add plugin-based flourishes, such as letting users write JS to dress up the interface or attach panels that display variables. We have our own structured state system that does the same job. It simply does not look like SillyTavern.

I do intend to offer incentives for scenario writers later. It is just too early to discuss them now, and I do not want to use them to lure people in under false pretenses. I will not promise a revenue-sharing scheme upfront just to attract a few more writers. First, get the whole sequence working: people willing to write scenarios, a way to review them, a way to publish them, and people actually playing them. Once people are really enjoying themselves there, the writers deserve to be treated well anyway. That will be the time to think seriously about how to give something back.

Keep it going for now

I have a day job; I do not depend on this project for a living. It has no exposure yet, and I have no experience, so I cannot assess it as a business. It is mostly an interest. If one day I refine it enough to make a business of it, I will think about business then. Anyone who wants to play is welcome to come, test it, and point out its faults. Scenarios will be added one at a time. I break complex mechanics into separate modules, rank them by importance, build them one by one, and test them repeatedly once they are done. Finding a pile of small problems is normal. For now, I just want to get a few things right: freedom, stories that do not get stuck, relationships, prose style, and memory.

Can I bring myself to say no?

Having come this far, I think the hard part of deciding what this project should be is deciding what not to do. Every addition that does not belong weakens the structure that lets it hold its tongue a little more. Weaken it enough, and there is no difference between it and all those model wrappers.

The reasons for those refusals are all structural. Having no revenue pressure lets me say no more firmly. If this were a business that had to make money, the boss would long since have banged on the table and put both a local client and SillyTavern compatibility on the schedule. The numbers are right there: refusing means giving up users and money for nothing. This project has no table for anyone to bang on. The cost is that it may never grow big. The benefit is that I can continue to stay away from things like a local client and SillyTavern compatibility, which could bring in users but would weaken the separation of information.

Back to that little note at the table. A game master is valuable because they know so much and can still keep themselves from saying it all. With OurRPG, I want to get that one thing working reliably first.

Translation log: translated from the Chinese original by Codex on 2026-11-03, 17:40–17:43 (US Eastern). Main thread GPT-6 Astra (gpt-6-astra), reasoning effort ultra; it spawned 1 sub-thread: 1 on GPT-6 Astra (effort ultra). Together they read 493,965 tokens (461,568 of them from cache) and wrote 7,821 (1,410 of them reasoning).