Glossary

These words are used precisely throughout this documentation. Several of them name things that are easy to confuse, so each entry says what the thing is and where its code lives.

The central plane

Everything we run: the Supabase project, the app, the control plane and the connection gateway. The word answers "whose side is it on". When a sentence needs to say which of the four did something, use the four names below.

The record

The Postgres database holding company data, defined by supabase/migrations. Row level security is its access boundary, so every read and write happens as some member.

Say "the record" rather than "the database": the host has a database too, and it holds something else entirely.

The control plane

The server routes under web/src/routes/api/agent/ holding the key that bypasses row level security. It authenticates a company's agent key and hands back sessions: a member session for the person the agent is acting for, a host session for the company's computer.

The app

The SvelteKit build at web/, served by Cloudflare Pages. Its pages are what a person signs into: they hold no secret, read the record as whoever is signed in, and reach the host through the connection gateway for what they cannot read directly, which is the chat screen, mail, and the agent's runs, memory and files. Its server routes are the control plane and the public API, and those do hold keys.

The public API

The routes under web/src/routes/api/v1/, which answer api.<zone>/v1 and any company host's own /api/v1. A caller carries either a signed-in session or a token issued to a person, and every call runs as that person. The app answers the tokens and the tool catalog itself, runs the tools the record can answer, and carries the rest to the company's computer. /api/v1/mcp serves the same catalog over MCP.

The tool catalog

Every tool the agent or a token can call, defined once in web/src/lib/server/public-api/catalog/ and generated into pkg/capabilityprotocol/generated/. Each tool names who answers it in answeredBy: a record tool runs in the app against the record, a company tool is carried to the host, and a local tool runs only beside the agent. The catalog lists them.

The connection gateway

The Cloudflare Worker at workers/connection-gateway/ that passes calls to the host. One Durable Object per company holds the browser sockets and the host's one standing connection, and routes calls one way and answers the other. The public API's invocations go the same way, as one authorized call. Neither end ever connects to the other directly.

The chat screen

The part of the app that shows the company's messenger. It is a view onto that messenger, so what appears in it appears in the messenger's own apps too.

A messenger app

A Buzz client: the ordinary software a person opens to read the chat. The second way to reach internkim, from anywhere the messenger server itself is reachable.

Distinct from that server, which is the company's own and may sit in a vendor's cloud, on the company network, or on the host computer.

The host

The company's always-on computer, and everything running on it. One company, one host, which may be several boxes of which one serves at a time (Kim Mini). One package installs it, and systemd or launchd keeps it running.

The relay

The process that answers the app and feeds the agent: internkim-relay, built from host/relay/. It holds the standing connection to the gateway and serves each call as the member the gateway named. It keeps each message the connector hands it in a queue on disk, turns it into an ACP turn for the agent, serves the agent its tools, and reports messenger arrivals as notifications. One company, one relay process.

The Buzz relay is a separate messenger server the company runs, which the package runs as buzz-relay and host/buzz/ describes. When both appear in one sentence, say "the relay" for ours and "the Buzz relay" for the messenger.

The connector

chatd, at .dependency/blueclaw/chatd/. It attaches to the company's messenger through a platform adapter, signs in as the bot, normalizes each arriving message and posts it to the relay. It carries the agent's replies and the chat screen's messenger operations back out.

The agent

blueclaw, the agent host, vendored at .dependency/blueclaw/. It is the ACP agent the relay opens sessions with, runs the bluecollar loop in-process, keeps memory in bluememo, and owns approval and the task ledger. It listens on /run/internkim/acp/blueclaw-acp.sock, with its admin API on 127.0.0.1:8080.

Memory

bluememo, a library blueclaw embeds, at .dependency/blueclaw/.dependency/bluememo/. It keeps the facts a model extracts from finished work in one SQLite file per person, per circle and for the whole workspace, each in that subject's protected directory. A recall runs as the reader, so file permissions decide what they may see.

The skills

The instructions and scripts the agent loads for a kind of work, from the internkim-plugin repository at .dependency/internkim-plugin/. The host package installs them in /opt/internkim/skills on Linux.

ACP and MCP

Two protocols, one for each direction. The relay speaks ACP to blueclaw: it opens a session per conversation, sends each message as a prompt, and carries the agent's approval questions to the person. The agent speaks MCP to call its tools, at an address the relay serves and forwards to /api/v1/mcp as the requester.

capabilityd

internkim-capabilityd, the typed capability boundary. It holds provider credentials and exposes only a capability API on /run/internkim/capability.sock, so the agent never sees a provider token, a browser binary or a model path. Model calls go through it too: the agent asks for a tier, and the tiers are named in internal/modelladder. Code in internal/capabilityd/.

The agent's store

The Postgres database on the host, defined by .dependency/blueclaw/migrations/. Conversations, task runs and policy. Never company records.

Two words that mean two things

When either word could be ambiguous, this documentation says "a task in the record" or "an agent run".