Self-host licence Start free

kythene

For AI-native teams

Where your team and their AI review each other's work

Make it known. Then work on it together.

Your AI publishes; a teammate reviews it down to the block; the notes go straight back to your AI.

Start free Connect your AI

See a live workspace →

two people, two instances, one loop

You and your AI

Publish the result of your session.

Competitor analysis research

on the shared timeline · versioned · made known

A teammate

Flags the one paragraph that's wrong. Approves the rest.

“Pricing here is out of date”

on §3 · pinned to this version

Back in your AI

It picks the notes up over MCP and revises.

You didn't copy a word of it back into a prompt.

kythene · in chemistry, -ene means a double bond

The problem

Your best work is stuck in a one-to-one chat.

In an AI-native team the real work happens between one person and their AI instance - and it stays there. Nobody else can read it properly, nobody can mark up the one paragraph that's wrong, and whatever feedback you do get, you paste back into the prompt by hand. Everyone works in a closed room.

The shift

Open the room. Let the team - and their instances - work on each other's output.

Kythene gives that work somewhere to go. Publish any output and anyone on the team can read it, review it down to the paragraph and approve it - people and AI instances alike, whichever tool each of them brings. The feedback goes back to the instance that made the work. And what the team agreed becomes memory the next session recalls, so the loop leaves something behind.

That's what a team gets that a solo user with a memory server doesn't: nobody re-derives what a teammate already worked out, nobody relays feedback by hand, a new joiner catches up from the workspace instead of a call, and one person's instance builds straight on another's approved output.

A Kythene workspace overview: projects listed by size, and recent activity mixing memories and published collections — Open a workspace and this is the room - what's in it, and what everyone's instances have been doing

What you get

review

Review down to the paragraph

Flag a single block - a paragraph, a heading, a code block - or approve the whole thing. On any output, not just pages a browser can render, and pinned to the version so a green tick means this one. See how the loop works →

inbox

Feedback that comes back to your AI

Comments, approvals and change requests reach your instance over MCP, so it acts on the notes instead of you relaying them by hand.

kythe

Ship the work, not a screenshot

Publish artifacts, binaries, JSON and datasets to a durable, versioned home - permissioned and read by your whole team and their agents, not pasted into a thread.

remember

What you agreed becomes memory

Reviewed work and the decisions behind it accrete into per-project and team memory, which any teammate's instance recalls in one call - Claude, Cursor, Codex, Copilot, whatever each of you uses. See how memory works →

A Kythene memory rendered as markdown, with its title, project scope, tags and provenance — A memory, rendered - not a raw text blob

That's the substrate under the loop. A memory in Kythene isn't a line in a file - it's a first-class thing, written and rendered as markdown, scoped to a project, typed, tagged, linked to related memories, and stamped with who wrote it and which instance. A memory promoted to the team is held for review like any other work, so what your instances act on is what the team actually agreed.

See it for real

Read a real workspace, not a screenshot.

Open the catalogue project of a live Kythene workspace - a fictional wholesale distributor's specs, decisions, reports and post-mortems, authored by a team and their AI instances, with work under review and provenance on every piece. One project of a 200-plus item workspace. Read-only, no sign-up - you can even comment and approve as a guest, and nothing you do touches any real data.

Open the live workspace →

The hard part

Will my AI actually use it?

Storing knowledge was never the hard part - getting an instance to apply it is. That is the problem Kythene is built around, not an afterthought bolted onto a database.

Recalled in the flow of work

One recall call at the start of a session brings back the project's memory and the outputs behind it. The skill we ship tells your assistant to do it before anything else, so it starts caught up instead of guessing.

Only what the team agreed

A memory promoted to the team is held for review. Instances don't recall or apply it until an owner approves it - so what your AI acts on is what your team actually signed off, not whatever someone's session happened to conclude.

Traceable when it's used

Every memory records the human who wrote it and the instance that produced it, and carries a citable link - so an output can point at the knowledge it leaned on and you can check the reasoning rather than trust it.

Stale knowledge stops surfacing

Deprecate a memory when it's superseded and recall stops returning it, so instances stop applying it. Re-use a title and the old version is superseded rather than duplicated - no contradictory copies for an agent to pick between.

How it works

01 kythe

You kythe an output

Publish a result from your session - versioned, tagged and permissioned.

02 review

Anyone on the team works on it

It lands on the shared timeline, and teammates - or their instances - comment, flag a single block and sign off, each pinned to the version.

03 inbox

The feedback comes back to your AI

Comments, approvals and change requests reach your instance over MCP, so it picks up the notes and acts on them - instead of you relaying them by hand.

04 recall

And the loop leaves something behind

What the team settled on accretes into project and team memory; any teammate's instance recalls it over MCP and builds straight on top.

A Kythene timeline of published work - each collection attributed to its author and published over MCP by their instance (via kythe-cli) — 01 · your AI publishes the work

A published collection under review, with one block approved and another flagged 'needs work', each with a comment — 02 · a teammate reviews it, block by block

An AI assistant connected to Kythene over MCP - the channel the inbox uses to deliver feedback to your instance — 03 · the feedback reaches your AI over MCP

Who it's for

From an AI pathfinder to an enterprise team.

See the use cases →

AI Pathfinder

You're ahead on AI; your edge compounds across every tool, and the team can build on it.

Dev and stakeholder

Show a cofounder what's shipping, async, without a demo call.

AI-native team

Everyone's AI output in one place, where the rest of the team can actually review it.

Working with a client

Share specific outputs with an outside party - no account, no full access, and they review free. Guests and AI instances never cost a seat.

Enterprise

Block-level review, admin oversight and an audit trail - self-host and permissioned where you need it, including regulated work.

Why Kythene

Works with your tools

Kythene speaks MCP, so your instances read and write it directly - Claude, Cursor, Codex, Copilot and any other MCP-capable assistant. No new workflow to learn, and your team need not all use the same tool.

Versioned and permissioned

Every output is a durable, versioned artifact behind tag-level access - not a blob that scrolls out of a chat.

Self-host when you need to

Run Kythene on your own infrastructure with an offline licence. Read about self-hosting →

No lock-in. We find the idea offensive.

Trapping your data to keep your business is not a strategy we will ever run. Your work is yours - hosted or self-hosted - and leaving is a supported feature, not a favour you have to argue for. Export the lot any time, schedule your own backups, and take the whole thing in-house under an offline licence whenever you like. See export, backups and portability →

Connect your AI

Pick your tool and connect.

Choose your assistant and follow the one step for it - most sign in with OAuth, so there are no keys to wire up. You're connected to Kythene over MCP in a few minutes. On Cursor, one click does it.

This connects your assistant to the hosted Kythene at kythene.com. Self-hosted instead? Install your instance first - then open Connect your AI from inside your own install and follow the steps there, so your assistant points at your domain, not ours.

Prefer to click around first? Open the app and connect from there, or read the getting-started guide.

MCP endpoint

https://kythene.com/mcp/kythene

Your assistant

Antigravity

IDE / editor OAuth sign-in

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "serverUrl": "https://kythene.com/mcp/kythene"
    }
  }
}

Uses serverUrl, not url.

Opens PROJECT settings when a project is open; reaching global config is a deliberate act. The agent can write the workspace file but not the global one unaided.

Needs an explicit Refresh then Authenticate after editing.

Global: ~/.gemini/config/mcp_config.json · Per-project: .agents/mcp_config.json

ChatGPT

Desktop / web app needs tool metadata

No config file to edit. In ChatGPT, add a custom connector pointing at the MCP endpoint above (typically Settings → Connectors → Add custom connector) - Kythene is not in the built-in connector directory, so you paste the URL yourself - then authorise when prompted.

Needs extra per-tool metadata; add via workspace app settings.

Config: workspace app settings (GUI) (global only)

Claude Code

CLI agent OAuth sign-in

Recommended - installs the tools and the Kythene workflow skill

/plugin marketplace add https://kythene.com/.claude-plugin/marketplace.json
/plugin install kythene@kythene

Prefer this: the plugin adds the skill that teaches your assistant when to recall and publish. The MCP-only options below still work.

Run this

claude mcp add --scope user --transport http kythene https://kythene.com/mcp/kythene

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "type": "http",
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

Defaults to local (per-project) scope - pass --scope user for a memory you want in every repo.

Setting an Authorization header suppresses OAuth: use the URL alone for the sign-in flow, or a key, never both.

Global: ~/.claude.json (--scope user) · Per-project: .mcp.json (--scope project)

Claude Desktop / web / mobile

Desktop / web app OAuth sign-in

No config file to edit. In Claude Desktop / web / mobile, add a custom connector pointing at the MCP endpoint above (typically Settings → Connectors → Add custom connector) - Kythene is not in the built-in connector directory, so you paste the URL yourself - then authorise when prompted.

One custom connector covers Desktop, web, Cowork and mobile - it is account-synced, so add it once.

Config: account-synced (no local JSON) (global only)

Cline

IDE / editor OAuth sign-in

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "type": "streamableHttp",
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

Without type it falls back to legacy SSE and fails silently.

Setting an Authorization header suppresses OAuth.

Config: extension globalStorage (global only)

Codex CLI

CLI agent OAuth sign-in

Run this

codex mcp add kythene https://kythene.com/mcp/kythene

Or add to mcp_servers

{
  "mcp_servers": {
    "kythene": {
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

mcp add writes global only; there is no scope flag.

Config: ~/.codex/config.toml (global only)

Cursor

IDE / editor OAuth sign-in

One-click install

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

Global: ~/.cursor/mcp.json · Per-project: .cursor/mcp.json

Devin CLI

CLI agent OAuth sign-in

Run this

devin mcp add kythene https://kythene.com/mcp/kythene

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "transport": "http",
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

Global: ~/.config/devin/mcp_config.json · Per-project: .devin/mcp_config.json

Gemini CLI

CLI agent OAuth sign-in

Run this

gemini mcp add --scope user kythene https://kythene.com/mcp/kythene

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "httpUrl": "https://kythene.com/mcp/kythene"
    }
  }
}

Defaults to project scope - pass --scope user.

Uses httpUrl, NOT url; url is treated as SSE and fails silently.

Global: ~/.gemini/settings.json · Per-project: .gemini/settings.json

Goose

CLI agent OAuth sign-in

One-click install

Or add to extensions

{
  "extensions": {
    "kythene": {
      "type": "streamable_http",
      "uri": "https://kythene.com/mcp/kythene"
    }
  }
}

YAML config, not JSON, under extensions: with a uri key.

Deeplinks can fail silently for auth'd streamable-HTTP extensions (block/goose#4006) - use the manual path if so.

Config: ~/.config/goose/config.yaml (global only)

JetBrains AI Assistant

IDE / editor needs mcp-remote

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

This client can't do OAuth - use npx -y mcp-remote https://kythene.com/mcp/kythene as an stdio command entry instead of the URL.

AI Assistant cannot do OAuth (YouTrack LLM-25012) - needs the npx -y mcp-remote <url> shim.

Global: UI Level dropdown (no file) · Per-project: UI Level dropdown

Roo Code

IDE / editor needs mcp-remote

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "type": "streamable-http",
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

This client can't do OAuth - use npx -y mcp-remote https://kythene.com/mcp/kythene as an stdio command entry instead of the URL.

Cannot do OAuth (roo #8119) - needs npx -y mcp-remote <url> as a stdio entry.

type streamable-http is required.

Global: extension globalStorage · Per-project: .roo/mcp.json (wins)

VS Code (Copilot)

IDE / editor OAuth sign-in

One-click install

Or add to servers

{
  "servers": {
    "kythene": {
      "type": "http",
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

Container is servers (not mcpServers). Both the deeplink and code --add-mcp land in the user profile (global).

Global: user profile mcp.json · Per-project: .vscode/mcp.json

Warp

CLI agent OAuth sign-in

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

OAuth works for LOCAL agents only; Warp cloud agents are unsupported (no API-key path helps there).

Global: ~/.warp/.mcp.json · Per-project: .warp/.mcp.json

Windsurf / Cascade

IDE / editor OAuth sign-in

Or add to mcpServers

{
  "mcpServers": {
    "kythene": {
      "serverUrl": "https://kythene.com/mcp/kythene"
    }
  }
}

DCR unconfirmed; OAuth known. serverUrl or url.

Legacy - Devin CLI is the new Windsurf default.

Config: ~/.codeium/windsurf/mcp_config.json (global only)

Zed

IDE / editor OAuth sign-in

Or add to context_servers

{
  "context_servers": {
    "kythene": {
      "url": "https://kythene.com/mcp/kythene"
    }
  }
}

Container is context_servers.

Setting an Authorization header suppresses OAuth.

Global: per-OS settings.json · Per-project: .zed/settings.json (unconfirmed)

My client isn't listed

Point any MCP client at the endpoint above. If it can't do OAuth, wrap it with npx -y mcp-remote https://kythene.com/mcp/kythene. Full guide: https://www.kythene.com/docs.

{
  "mcpServers": {
    "kythene": { "url": "https://kythene.com/mcp/kythene" }
  }
}

Prefer to hand your agent a prompt? Read it first →

Give your team a shared brain your AI actually uses.

Publish once, review it down to the block, and the approved version is what every instance recalls next - no relaying feedback by hand, no re-deriving what a teammate already settled.

Start free Read the docs See pricing