How it fits together

internkim is a coworker your company runs itself. It does what an assistant does: records attendance, keeps the calendar, drafts and files things, runs what needs running. Every piece of that work happens under the identity of the person who asked for it, so what it leaves behind carries a name.

It is split across two machines, and which one holds a thing is decided by a single question: if that computer burned down tonight, what has to stay true tomorrow?

Two ways to reach it

The web app is the default. It includes attendance, leave, the calendar, work, the org chart, settings, and a messenger screen where people talk to internkim and each other.

The messenger app works too wherever that messenger is reachable. The chat is your company's own messenger, a Buzz relay, so its ordinary apps sign in and work as usual. A messenger kept inside the office is reachable inside the office; the web app's chat screen is how the same conversation follows someone onto a train. See where the messenger server runs.

Both reach one conversation. The web app's messenger screen is a view onto the company's messenger rather than a separate inbox, so a message written in either place arrives in the other, and the agent hears it the same way regardless of which one sent it.

The records

A Supabase project. Postgres holds the company's records, row level security decides who may read a row, and Supabase Auth signs people in with a password, a passkey or a Google account. The schema is the directory of migrations at supabase/migrations, and What the tables mean explains them.

Alongside it, three more things we run:

• a web app (web/): the pages people sign into, and the HTTP API those same pages are backed by, which anything holding a token can call
• a handful of server routes holding the one key that can bypass row level security (web/src/routes/api/agent/) — they issue what a member cannot issue alone: a session for an agent, a session for a host
• a small Cloudflare Worker (workers/connection-gateway/) that passes calls to the company's computer, from a browser or from the API, since neither end can connect to the other directly

This documentation names those separately, because they behave differently even though they deploy together. See the glossary.

The Supabase project can be a hosted one or your own. The schema is a directory of migrations, the app is one build, and which project the app talks to is configuration read at runtime. Hosting the app is also how a company hosts the API. Self-hosted Supabase ships the same Postgres, the same row level security, and the vault extension the schema uses.

Plain Postgres without the rest of Supabase is a different promise. The app reads and writes the record directly because Supabase supplies accounts and sessions (GoTrue), a data API (PostgREST), row level security keyed on auth.uid(), and the signing keys the plane mints member and host tokens with. Each of those would have to be written again.

The host

One computer that stays on. A Linux server, a Mac that does not sleep, a box in a cupboard. It runs the agent, the connector to your messenger, the daemons around them, a Postgres of its own holding conversations and what the agent did, and a memory file for each person and circle. Architecture lists the processes and what each does.

Once it belongs to a company, nothing on it listens beyond the machine itself. Every connection it makes goes outward, so there is no tunnel to keep alive, no port to forward, and no hostname pointing at a machine in your office.

The software

The agent itself is three repositories. blueclaw is the agent host: it owns approval and the task ledger, and it is the agent the relay hands each message to. bluecollar is the agent loop and model client running inside it, and bluememo is its long-term memory. The skills it loads come from internkim-plugin. This repository, internkim, is the layer that puts those on a machine and operates them: the relay, the surrounding daemons, the operator CLI (cmd/internkim/), the web app and its tool catalog (web/) and the schema (supabase/migrations). blueclaw is vendored at .dependency/blueclaw/, the other two inside it. Architecture shows how they fit. Every repository named here is public, and CONTRIBUTING.md says how to build, check and send a change.

What stays yours

Messenger: internkim attaches to the messenger you already run. No conversation reaches the records, because the schema has no table for one.

Model: the agent calls models with the provider key the host holds, through tiers named in one place, internal/modelladder.

Computer: replace it at any time. Company records keep everything the company needs after a hardware replacement.

Where to go next