Developer overview

Kay is a small stable core plus a set of extensions. That isn’t a description of a future plugin ecosystem — it’s how Kay is built today. Gmail, GitHub, Notion, Slack, and the rest are plugins loaded through the same contract your own code would use. There are two ways to extend Kay, and they differ in one thing that matters more than any other: whether you are shipping instructions or shipping code.

	Skill	Plugin
What it is	A Markdown file of instructions	A package that runs inside Kay
What it adds	Judgment — how to do a task well	New tools, integrations, pages, and connected services
Does it run code?	No	Yes, with Kay’s own authority
Who can write one	Anyone, in a text editor	Requires the plugin SDK (private beta)
How it’s shared	A git repository	A git repository

Skills

A skill is reusable instruction — the knowledge of how to do something properly, written down once so Kay applies it every time instead of you re-explaining it. Skills don’t grant Kay any new capability; they shape how it uses the capabilities it already has. A skill is a directory with a SKILL.md in it:

---
name: weekly-report
description: Compile the weekly status report from the team's GitHub issues and
  last week's standup notes. Use when asked for the weekly report or a status
  summary for the leadership sync.
---

# Weekly report

Pull every issue closed since last Monday, group them by project, and write one
sentence per project in past tense. Lead with anything that slipped...

In Kay, ask the assistant to read skill://skills/authoring before creating or improving a skill. That guide owns descriptions, structure, references, specializations, and verification. The example above is a source file for a repository; when Kay creates a personal skill through skill://, its tools serialize the file from structured fields.

Where skills come from

Your own machine

Drop the skill directory in ~/.kay/agent/skills/<name>/SKILL.md and it’s available to Kay.

A project you're working in

A .kay/skills/ directory inside a project applies whenever Kay is working in that project — this is how a team ships its conventions alongside its code. Kay also reads .claude/skills/, so an existing Claude Code skill library works as-is.

A shared repository

Ask Kay to add a skill source and point it at a git repository. Kay stages it and asks the user to approve the source before syncing anything from it. Approved sources can later be refreshed, revoked, or removed from the Skills sidebar.

Plugins

A plugin is a package that Kay loads at startup and that can contribute:

Tools the agent can call
Integrations — a connected service with its own sign-in, so the agent can reach an external API on the user’s behalf
Addressable resources under its own scheme://, which the agent browses and reads the same way it reads anything else
Skills bundled with the plugin, carrying the judgment its tools need
Pages — full React apps hosted inside Kay’s workspace

First-party plugins use exactly these contribution points, which is the intent: the contract is dogfooded rather than designed in the abstract.

How a user installs one

Plugins are distributed as git repositories, and installing one is a conversation rather than a package manager.

Point Kay at the repository

The user asks Kay to add a plugin source. Kay stages it — no code is fetched yet.

The user approves the source

A review card appears in the conversation. Approving it is what grants trust, and it’s a decision only a human can make in Kay’s own UI — the agent can stage a source and read its status, but can never approve one.

The user enables the plugin

Approved plugins appear in Settings → Plugins, each starting disabled. Enabling one is a second, separate approval.

Trusting a plugin source is a heavier decision than trusting a skill source, and Kay says so on the card. A plugin from a trusted source runs inside Kay with Kay’s own authority, and it runs at startup for every plugin that source provides — including ones left switched off. The enable toggle controls what a plugin contributes to the user, not whether its code loads.

The approval model

One principle runs through all of the above, and it’s worth understanding before you design anything: the agent can propose, but only a human can grant. Kay’s agent can stage a skill source, stage a plugin source, request a permission, or ask to connect an integration. It cannot approve any of them, and it cannot route around them — installing a plugin by writing files into the plugins directory doesn’t work, because that path is consent-gated and fails closed rather than loading whatever it finds. Build with that grain rather than against it. An extension that needs a capability should ask for it explicitly and describe honestly what it does with it, because that description is what the user reads when deciding.

What isn’t public yet

Kay is in private beta, and so is the developer surface:

The plugin SDK is published, but not publicly. @yaklabs-ai/plugin-sdk and @yaklabs-ai/plugin-protocol ship to GitHub Packages at matched versions, and both are private — installing them needs membership of the yaklabs-ai GitHub organization. So plugin authoring is limited to Yak Labs and design partners for now. Installing an already-built plugin from a repository works for anyone.
MCP servers are not available on the released build. Support for connecting external Model Context Protocol servers exists and is in internal testing, but it doesn’t ship in the current public release.

If you’re building something on Kay and need the SDK, get in touch — the beta is small enough that we work with people directly.

Quickstart

Install Kay and run your first task.

Kay home

What Kay is and who we build it for.

​Skills

​Where skills come from

​Plugins

​How a user installs one

​The approval model

​What isn’t public yet

Quickstart

Kay home

Skills

Where skills come from

Plugins

How a user installs one

The approval model

What isn’t public yet