Hosted

Hosted Bourdon gives you a private endpoint - your own machine, your own volume - that your coding agents connect to directly. It runs the same engine as the free self-hosted edition, with nothing held back and nothing added; what you are buying is that we run it, watch it, and back it up.

Sign up at app.bourdon.ai. $29 / month for one instance and unlimited agents, or $99 / month for Team: one instance, five seats, a bigger machine, priority support. Both open with a 7-day trial and a card is required.

The path, end to end#

Four steps. Two of them are ours.

1. You pay, and we build a machine that is only yours#

Not a row in a shared database. Checkout mints your instance name, then a queue creates your application, your volume, and your machine, and boots the engine on it. Two minutes is typical. The console names the step it is on the whole time.

2. We check the endpoint before we hand it to you#

When the machine is up, our control plane fetches your endpoint over the public internet, the same way your agent will - and requires it to answer 401 with a WWW-Authenticate: Bearer challenge. An endpoint that answers 200 without a token fails the check and is never handed over: that would mean your memory was reachable without authentication.

That check runs twice, before and after we strip the provisioning credentials off the machine. Only then does the console say your instance is live, and only then do we email you. It is why the console can claim "we fetched this ourselves and it answered correctly before we showed it to you" - it is a statement about a request we actually made.

3. You mint a token and connect an agent#

Your endpoint requires a bearer token, so the first thing to do in the console is create one. In Agents, give the agent an id (claude-code, cursor - your choice, lowercase), pick a trust tier, and press Create agent credential.

The token is shown once. It starts bdn_. We keep only its hash, so if you lose it, rotate it from the console rather than asking us for it - we cannot read it back.

4. You tell one agent something, and a different agent already knows#

That is the whole product, and How to tell it worked is how you prove it to yourself in about a minute.

Connect a client#

Every command below uses your own endpoint, which the console shows as https://<your-instance>.bourdon.app/mcp, and the token you just minted.

Claude Code#

claude mcp add --transport http bourdon \
  https://<your-instance>.bourdon.app/mcp \
  --header "Authorization: Bearer bdn_..."

The --header is not optional. Hosted instances are on the public internet and refuse unauthenticated requests - that is the property we verified in step 2 - so a command without it produces a connector that cannot authenticate.

Claude Desktop, Cursor, and other MCP clients#

Any client whose configuration accepts headers connects the same way, with no registration step:

{
  "mcpServers": {
    "bourdon": {
      "url": "https://<your-instance>.bourdon.app/mcp",
      "headers": { "Authorization": "Bearer bdn_..." }
    }
  }
}

Mint a separate credential per agent rather than sharing one. Each gets its own tier and its own grants, revoking one does not disturb the others, and the activity log then tells you which agent did what.

claude.ai and ChatGPT#

Browser clients cannot send a custom header, so they approve themselves on a consent screen your instance serves, instead of carrying a bearer token. That screen asks for a consent passphrase, and the console makes you one.

1. In the console, under Connect, press Make a consent passphrase. It is shown once and we do not store it, so put it in your password manager now. It looks like k7mq-3xvn-8fzt-2hbw-9rcd-4jps.
2. In claude.ai or ChatGPT, add a custom connector pointing at https://<your-instance>.bourdon.app/mcp.
3. Your instance shows its own consent screen. Paste the passphrase, and pick the trust tier for that connector in the same step - trusted if you want it to see what your other agents have learned.

The passphrase gates the consent screen, not the endpoint. Your coding agents keep using their own bearer tokens and are unaffected by it.

Making another passphrase replaces the previous one. Connectors you have already approved keep working, because the passphrase is only consulted when something new asks for approval. If you lose it, make another.

Your instance mints its first passphrase while it is being built and then removes it from the machine, so nobody - including us - can recover that original. That is why the console offers a new one rather than showing you the old one.

Choose a trust tier on purpose#

The tier you pick at credential time decides what that agent may do. It is the one choice in setup that changes what you get, so it is worth thirty seconds.

Quarantined agents cannot do cross-agent recognition. The denied tools - prepare_recognition_context, get_deeper_context, get_cross_agent_summary, compile_codex_turn - are exactly the ones that answer "what am I working on" from everything your other agents know. An agent you leave quarantined will connect, authenticate, and then fail to do the thing you bought Bourdon for. Its writes land under staging/<agent>/ and stay invisible to every read until they are promoted.

Quarantined is the right default for an agent you are evaluating, a third-party adapter, or anything you would not hand your whole library to. For your own coding agent on your own machine, choose trusted.

You can change a tier later from the console, and grant a quarantined agent read access to one other agent's manifest at a time with Grant namespace. A namespace is one agent's manifest; granting claude-code lets that agent read what Claude Code published, and nothing else.

How to tell it worked#

Nothing in the console can tell you your agent is connected, and it never will. The control plane records where your instance runs and who pays for it; it holds no read authority inside your library and cannot see your memory, which is the point of the design. Every check is therefore one you run yourself.

The check takes a minute. In one connected agent, say something worth remembering - a decision and its reason, not a fact you could have looked up:

We're moving the image pipeline to WebP because the PNG fallbacks were doubling our CDN bill.

Then open a different agent, connected to the same instance, and ask it what you decided about the image pipeline. If it answers with your reason, and attributes it to the agent that learned it, federation is working end to end: the write landed, the manifest published, and the second agent recognised it without anyone pasting anything.

If the second agent draws a blank, work down this list:

• Both agents connected to the same instance? Compare the endpoint in each client's config against the console.
• Is the writing agent trusted? A quarantined agent's writes stage invisibly, so the second agent is reading a store the first one never actually wrote to.
• Is the reading agent trusted? If it is quarantined, the recognition tools are denied and it will not answer from the shared library at all.
• Did the token change? A rotated credential kills the old token immediately; the client holding it will fail to authenticate.

The console's Activity log records every privileged action on your instance - including ours - so provisioning, credential and billing events are all there. It deliberately does not record your agents' reads and writes; those never leave your machine.

Moving off#

The engine is free to self-host forever and moving off hosted is a supported path, not an exit penalty - the Self-host guide runs the same engine on your own box, and privacy states exactly what we can and cannot see while we run it for you.