Partners — an agent for each of your customers

ghosty partner is for when your product wants to give an assistant to each of its customers. You have a partner space; each business using your product is a tenant (identified by your own externalId) and each person writing to that business is an end user (groupId).

• There is one shared agent, in solo-MCP mode: no machine, no disk; its only tools are those of your HTTPS MCP servers.
• Every turn carries a short-lived token that Ghosty passes to your MCP. It never goes into the prompt, memory or logs.
• Memory is per tenant and end user: one business never sees another's.

Your partner space

The space owner runs these, signed in (ghosty login).

ghosty partner ls                                  # your partner spacesghosty partner enable <workspace>                  # turn one of your spaces into a partner spaceghosty partner credentials ls                      # server credentials (no secrets)ghosty partner credentials create --label production   # issue one: the secret is shown ONCEghosty partner credentials rotate gpk_… --grace 60     # new secret, same keyIdghosty partner credentials revoke gpk_…            # revoke it (idempotent)ghosty partner audit                               # who did what, when

• create prints GHOSTY_PARTNER_KEY=gpk_… and GHOSTY_PARTNER_SECRET=gps_…. Store them on your server right away: the secret is not shown again.
• rotate --grace MIN keeps the old secret valid for that many minutes (default 60) so you can switch your server without downtime.
• creds is an alias of credentials; revoke can also be spelled rm.
• If you own more than one partner space, pick one with --workspace <slug> on any command.

The shared agent

ghosty partner agent get                           # the template and its versionghosty partner agent apply --file agent.json       # create or update it (idempotent)

agent.json carries only what you want to change:

{  "name": "Nik",  "engine": "deepseek",  "prompt": "You are the assistant of {business}…",  "mcp": [    { "name": "agenda", "url": "https://api.your-product.com/mcp", "headers": { "Authorization": "Bearer ${turn.token}" } }  ]}

HTTPS MCP servers only. Headers take no fixed keys: only the ${turn.token} and ${tenant.externalId} placeholders. If nothing changed, no new version is created.

Tenants

ghosty partner tenants lsghosty partner tenants get org_123ghosty partner tenants set org_123 --config '{"name":"Spa Luna","timezone":"America/Mexico_City"}'ghosty partner tenants rm org_123                  # deletes its config AND its memory

A tenant is config only (name, tone, timezone, locale, notes): it has no machine of its own. The first turn for a new externalId also registers it.

Try a turn

ghosty partner try org_123 "what appointments do I have today?"ghosty partner try org_123 "and tomorrow?" --group customer-42 --turn-token <short-lived-token>

• --group is the end user (default cli); each one gets its own conversation.
• --turn-token is the token Ghosty will pass to your MCP as ${turn.token}. Here --token works too and means the same (it is not your session).
• With --json it prints one line per turn event (chunk, tool, error…).

Test as your server

With the credential in the environment, the CLI signs every request the way your backend will (HMAC of ${ts}.${keyId}.${body}):

export GHOSTY_PARTNER_KEY=gpk_…export GHOSTY_PARTNER_SECRET=gps_…ghosty partner agent getghosty partner try org_123 "hi"

That works for agent, tenants and try. ls, enable, credentials and audit always use your session: a credential cannot mint other credentials.