Let agents act on your platform.
On your terms, exactly once.

How it works

1. 1
   Your code declares actions.

   defineDoorActions binds each action’s schema and its handler in one object — the shape lives next to the implementation, never in a dashboard form. On deploy, sync pushes the shapes to Bubblio. Shapes only: a sync can never open anything.
2. 2
   You decide, per action, in the dashboard.

   Synced actions arrive hidden. The dashboard shows your code’s policySuggestion next to each one and waits for your decision: keep it hidden, open it to agents carrying a key, or open it to any agent. A deploy can never open an action; closing one never needs a deploy.
3. 3
   Agents quote, confirm, and your handler runs.

   A visiting agent pins the exact call with quote, then executes it with confirm — exactly once, receipted, HMAC-signed to your callback route. For keyed actions the user’s identity arrives as the same signed ?ctx your widget tools already use, so your existing route resolves `user` with zero new code.

Step 1 — Declare actions next to their handlers

One file, e.g. lib/bubblio/door.ts. Each action is a schema and a handler in one object; policySuggestion is a hint the dashboard displays — it is never applied. Handlers get (args, user, meta), the same signature as every widget tool.

Step 2 — Merge the handlers, sync on cold start

The door reuses the callback route you (may) already have for widget tools — spread door.handlers in, and fire door.sync at module scope. Sync is idempotent: unchanged shapes write nothing, actions you stop declaring are flagged “no longer in code” (never deleted), and new actions always land hidden, awaiting your decision in the dashboard.

After a deploy that ships new actions, the SDK prints one line with how many are awaiting your decision, and Bubblio emails you a summary — so a new capability never slips by unnoticed. Destructive-looking names sync anyway (a deploy should never wedge on a heuristic) with the suggestion dropped and a warning logged.

Step 3 — Decide in the dashboard

Open the door on the Agent door page (one toggle — questions only until you say otherwise). Every synced action then waits for a decision:

Accepting the code's suggestion is one click; declining (“keep hidden”) sticks — a declined action stays declined across every future deploy. Nothing runs until you decide, and closing an action takes effect immediately, no deploy involved.

Step 4 — Let users connect their agents (managed keys)

Keyed actions need identity. A user clicks “Connect your AI agent” on your site, gets a bak_… key once, and pastes it into their agent. The whole backend is one route — you supply only your session lookup:

GET lists the signed-in user's keys, POST mints one (the raw key appears once, there — show it, don't store it), DELETE revokes, scoped to the user's own keys. Everything getUser returns except hint is signed into the identity and becomes your handlers' user argument on every keyed confirm.

Test your door

Your door speaks standard MCP (Streamable HTTP, JSON responses) — any client works. The exact URLs, plus copy buttons, live on your Agent door page; every test visit shows up there as a real conversation.

Who holds what — the custody and authority doctrine