Open Your Vault to Agents

Here is the trap most vibe-coded apps are in, ours included until a few days ago. The website is the vault. The code behind the “Register” button does two jobs in one breath: it looks at the login cookie your browser sends, and then it registers you.

At the counter that works perfectly. But an agent calling from Claude has no browser and no cookie. So the exact same code turns it away – not because the agent isn’t allowed, but because the teller can’t see a face. When we checked, 43 files of these server functions checked the login themselves.

The fix is to move the vault behind the counter. Each valuable action becomes one function that is told who is asking, instead of peeking at a cookie. The teller who insists on seeing your face becomes a vault that opens for anyone the front desk has already checked in – whether they came through the door, the phone line or the app.

Every item in that red box is one function, and each comes with a card a machine can read: its name, what goes in, what comes back, and whether it changes something. If you have built a chat with the Vercel AI SDK, you already know that card – it’s a tool. The trick is to write it once and let every door use the same card.

You don’t need a rewrite for this. Next.js even has a name for the idea, a data access layer, and recommends keeping it in a lib folder. Start with one action. Registration was the first one we moved: the button on the site still calls it, it just passes in who you are now. The same function also runs when a brand-new account is created through an event sign-up. Two ways in, one piece of code.

To keep the vault a vault, three house rules apply to every file inside it. We didn’t leave them to good intentions: the build fails when a file breaks one.

If “a function the server runs” is still fuzzy, the Builder Codex chapter on real functions is the gentle version of this section.

Once the vault exists, a door is thin. It does three small things: checks who is knocking, translates their request, and hands it to the vault. That’s why we could open several. Which door someone uses depends on how technical they are and what their agent needs to do.

The MCP door is the one everyone talks about, and it’s lovely when it works: you add a connector in Claude or ChatGPT, a sign-in window pops up, and your agent can act as you. So why didn’t I stop there?

I personally am annoyed that these types of connections rarely hold.

If I move my process to the cloud, for example to an OpenClaw or a Hermes agent, there is always too much human interaction needed to keep it smooth. A handshake that needs a person to click “allow” is a bad fit for an agent that runs at three in the morning with nobody watching. So the rule became: every door must also work with a stable API key that you create yourself and can take back any time – the way GitHub, Vercel or Resend do it. OAuth is the convenience. The key is the guarantee.

The CLI is the same key in a different hand. Coding agents like Claude Code are at their best in a terminal, where a short command costs far less of their attention than a long list of tool descriptions. So anyone with a key can do this:

Every door, every tool and every command is written up on one page for humans and their agents: pirateskills.com/developers. The CLI isn’t on the npm registry yet – install it straight from pirateskills.com:

npm install -g --allow-remote=all https://pirateskills.com/cli/pirateskills.tgz

And the Captain, the door that lives on our own page? It’s crew that is already aboard. It uses the exact same tools, so when you ask it to register you, it shows an Approve button instead of doing it silently. If you want to build one yourself, we covered the chat side – the AI SDK, AI Elements for the chat window and the AI Gateway for switching models – in How We Built an AI Startup in 48 Hours.

A door and a vault are not enough. A crew member who arrives at a harbour they have never seen needs a map: which door is theirs, what is behind it, and the house rules. For agents, that map is a skill.

You provide the tool plus a skill, or a set of skills, that teaches the agents how to use these tools in the appropriate way.

The tool says what can be done. The skill says when and how. Ours is a single text file anyone can read at pirateskills.com/skills/pirateskills/SKILL.md, and an agent installs it with one command. Next to it sits an llms.txt, the signpost at the harbour entrance that points visiting agents to the doors. Four lines from our map do most of the work:

There is a small lesson behind that third rule. When I first tested the MCP door from Claude.ai on 13 September, it asked me for permission before every single call – even just to list events. We had never told it which tools only read. Now every tool carries that label: reading runs without interrupting you, and anything that changes something still asks. The map and the labels say the same thing.

And because a vault with many doors is a vault with many ways to be attacked, we had the doors attacked on purpose before writing this. From outside, the live site passed 58 of 59 checks. The one miss was fixed the same night, and the map was tightened to insist on an explicit yes before every change. If you’re building your own door, the Builder Codex chapter on an MCP server and the one on login and signup are the place to start.

The part people get nervous about is money, and rightly so. Here is where we landed: the agent can completely prepare a Stripe checkout for you. All you do is add your details and approve it. Invitations, follow-up emails, everything that normally happens after a purchase, the system still handles.

In vault terms: the crew fills in the withdrawal slip, and you sign it. No tool can charge a card. Not an agent, not a model, not the Captain.

That last step is quietly important for a business. Every checkout an agent prepares carries which agent it came from – Claude, ChatGPT, the Captain, an API key. So a few weeks from now I won’t be guessing whether agent access is worth it. I’ll see the revenue per door.

The same thinking applies to the quietest treasure in the vault: the knowledge. The point isn’t that an agent can read our chapters. It is that your users can get value from you more efficiently, more deeply and more correctly with the help of their own agents. That’s why the knowledge tool always returns a link to the source, and the map tells the agent to cite it instead of making up advice in our name. If you’re wiring payments for the first time, the Builder Codex chapter on choosing a payment provider comes before any of this.

You don’t need five doors. You need one vault and one door, and the order matters more than the technology.

Hand this to your coding agent. It won’t change anything until you’ve talked it through together:

Building agent-ready products like this is what we do together in the Pirate Forge; the next Build cohort starts on 30 September. And if “server function” and “API key” still sound like another language, start with the AI Compass on 23 September instead. Or skip all of it and try the other side: connect pirateskills.com to your own agent and ask it what’s coming up.