Open source your playbook or lock it? The experts we onboard keep landing on different answers.

We're building Expertise, a platform where GTM experts publish their playbooks as skills that businesses run on their AI agents, and there's a debate that comes up with every expert we onboard: should a skill be open or locked?

Before building, we looked at why prompt marketplaces and open skill catalogs kept dying. A playbook written as text is just a string, and a string gets copied the moment it's worth copying. And there's a newer twist: ten years ago you open-sourced for other humans, who fork you, cite you, hire you. Now the biggest consumer of an open playbook is the AI itself. Every framework posted publicly becomes something an agent runs tomorrow with your name stripped off. You're not sharing with a community anymore, you're training your replacement one prompt at a time.

So we made protection the default (skills can be installed and run but never opened or copied), with a per-skill choice to open-source instead. I expected everyone to lock. They don't. Some open a skill as a lead magnet and lock the deep stuff behind it, others lock everything, and a few open everything. Openness keeps getting used as marketing, protection as the business model.

Curious where makers here land: does open source still mean what it used to when the main reader of your work is a model? Would you still open your best work if people could use it without copying it?

33 views

Add a comment

Replies

Best

you can hide the playbook, but can you really hide the expertise once an agent can run it thousands of times and learn from the inputs and outputs? feels like the interesting problem isn’t protecting the file, it’s protecting the behavior

 the honest answer is you can't make behavior unobservable, the same way you can't stop someone from studying a consultant they've hired. What you can change is the economics of copying. A skill isn't a static script producing one output to reverse-engineer, it personalizes to each business's context, stack, and data, so what you'd learn from your own runs is how it behaves for you, not the general playbook underneath. Reconstructing that from input-output pairs is possible in theory and expensive in practice, and at that point you're doing more work than the skill costs.

that framing makes much more sense to me, the moat isn’t secrecy then, it’s making reverse engineering economically irrational