Kition: an Electron workspace where documents, tables, whiteboards and a tool-using agent share one project
Kition brings Markdown, DataTable, WhiteBoard, a tool-using AI agent, browser research, and visual workflows into one desktop workspace.
At a glance
- What is it?
- Kition is a beta, local-first desktop app from KitionAI that puts Markdown, typed .kitable records, an infinite Whiteboard, a browser-researching agent and trigger-action workflows in one place. The interesting part is the review surface: the agent edits real files and you accept or reject each change.
- Who is it for?
- Kition fits people who already keep notes and structured research in separate apps and want an agent that writes into the same project files, with a diff they can review line by line. It does not fit anyone who needs a stable, versioned tool today: the README calls the project beta and asks users to back up important workspaces.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Kition targets: agent output that lands nowhere
Most AI writing tools end their work in a chat transcript. You get a suggestion, copy it out, and paste it into the document you actually maintain. The context that produced the text, the fields it was based on, and the browser pages it read are gone. Kition's answer is to give the agent the same surfaces a person uses: the active Markdown document, table schemas, typed records, attachments, and workflow steps. The README states the goal directly, saying Kition gives the Agent editable project files, typed records, attachments, and visible processes to work with, so AI operations are easier to inspect, correct, and repeat.
The audience is narrow but specific. It is for people who run recurring research or content work over a structured dataset: a table of records, a set of source documents, and a repeatable output. The README's own examples are a thumbnail generator that produces linked 16:9 and 9:16 variants per record, and a receipt pipeline where vision fields extract vendor, address, category, structured JSON and plain OCR text into the same row. Both are batch jobs over rows, not one-off prompts. If your work looks like a spreadsheet with an AI column, Kition is aimed at you. If it looks like a single essay, the extra machinery is overhead.
How the pieces connect: documents, .kitable files and a visible tool trace
The workspace is an Electron app. The repository shows electron/ alongside src/, with a Vite config under tooling/ and a contracts/ directory, so the desktop shell and the renderer are separated and the shared types live in their own folder. Documents are Markdown with live preview, links, backlinks, callouts, code, math, diagrams, daily notes, search and export. Structured data lives in .kitable files, which the README describes as ordinary files that hold prompts, field relationships, generated assets and review states.
The agent loop is the part worth understanding. According to the README, the agent reads the active Markdown document, makes scoped changes, and writes the result back into the workspace, while the document and the complete task trace stay visible together. When a file changes outside the editor, Kition opens a document review surface that highlights additions, deletions and rewrites. Each change can be accepted or rejected individually, or the whole edit reviewed as one set.
That diff gate is the design decision that separates Kition from a chat sidebar. It also sets the failure mode: the agent is writing to real files in your workspace, and the README's beta warning tells you to back up important workspaces and review agent changes before relying on them in production workflows. There is no claim of an undo history beyond the review surface, and the README does not document rollback.
Installing Kition and running a first table job
For normal use you do not build from source. The README points at the releases page for downloads, and the badge row marks macOS and Windows as supported with Linux experimental. Grab the latest release, which at the time of writing is v0.1.47, and open a workspace.
Building from source is a different path, and the toolchain is pinned tightly. The package.json engines field requires Node >=22.19.0 <23 and pnpm >=10.16.0 <11, with packageManager set to pnpm@10.33.0. Install dependencies and start the Electron dev runtime:
pnpm install
pnpm run devThe dev script runs node electron/scripts/dev-runtime.mjs. There is also pnpm run dev:web, which runs Vite with the web-preview mode against tooling/vite.config.ts, useful if you want to look at the renderer without the desktop shell.
Before trusting a build, run the project's own gate. The check script chains branding, product-language, i18n, lint, security, build and unit test steps:
pnpm run checkExpect the build:check stage to run the runtime lock validator, desktop asset checks, notices, typecheck and the Vite build in sequence. If any of those fail, the failure is in your environment or a patch, not in the app logic.
A first real use is the receipt scenario from the README. Create a .kitable file, add an attachment field for receipt photos, and add vision-powered fields for vendor, address, category, structured JSON and plain OCR text. Drop images into the attachment column. Each row then carries its extracted values next to the original image, and the table doubles as the correction surface when a field is wrong.
Where Kition gets in the way
The beta label is not decoration. The README carries an explicit warning to back up important workspaces and review agent changes before relying on them in production workflows. A tool that lets an agent write into your documents needs a recovery story, and the README does not document rollback. Accepting or rejecting individual changes covers the edit currently under review, not the state of the workspace an hour ago. If you are the kind of user who wants version history you can restore from, verify that before moving real work in.
Platform support is uneven. macOS and Windows are marked supported; Linux is marked experimental. There is no statement in the README about a headless or server mode, so the workspace is a desktop application, not something you run on a shared box.
The build toolchain is also strict in a way that will annoy casual contributors. Node 22 is the only supported major version, and pnpm is pinned to a single minor range. The check script runs Python-based branding, product-language and i18n checks before lint and tests, so a source build wants python3 on the machine as well as Node and pnpm. None of that is unreasonable for a project this size, but it means a stale global Node will fail before you see anything useful.
Finally, the agent is only as good as the schema you give it. The README's scenarios work because the fields are typed and the prompts are attached to the file. A blank table with a vague instruction has the same problem as a blank chat prompt, which is the thing Kition claims to fix.
Kition against Obsidian, Notion and a plain agent CLI
Obsidian is the closest comparison for the document half. It is Markdown-first, plugin-driven, and stores notes as files you own. The difference is where the intelligence lives: Obsidian's agent behaviour comes from community plugins you choose and configure, while Kition ships an agent that reads the active document, edits it, and shows a diff. Kition also carries typed table files as a first-class object, which Obsidian does not have natively.
Notion is the closest comparison for the table half. Its databases, formulas, filters and views are mature, and its AI features are integrated into the same surface. The trade-off runs the other way there: Notion is a hosted service, while the Kition topics list local-first and the README frames the workspace around project files. Kition's tables are .kitable files sitting in the workspace, and the agent's output is reviewed in place rather than in a hosted editor.
A general-purpose agent CLI with file access is the third option, and it is cheaper to adopt. It can edit Markdown and run scripts, but it has no concept of a typed record, no attachment column, no whiteboard, and no per-change accept or reject surface. You supply the review discipline yourself, usually with git. Kition's argument is that the review surface and the schema are the product, not the model.
Licence, maintenance and what upgrading costs you
Kition is licensed AGPL-3.0-only, stated in both the LICENSE file and the package.json license field, and the repository is not archived. The last push was on 2026-09-17, and releases v0.1.45, v0.1.46 and v0.1.47 landed on 2026-09-08, 2026-09-16 and 2026-09-17 respectively. That cadence is fast enough that a pinned fork will drift quickly.
AGPL-3.0 matters if you plan to modify Kition and let other people use it over a network. The copyleft terms reach network use in a way that permissive licences do not, and the source here is a desktop application rather than a hosted service, so the practical trigger is redistribution or running a modified build for others. Read LICENSE and, if you are building a product on top, take your own advice on the obligations. This is not legal advice.
Upgrade cost is low if you stay on released builds, because the app is distributed as a desktop binary. It is higher if you maintain a fork: the pinned Node and pnpm ranges, the Python checks in the check script, and the rapid release cadence all mean rebasing costs real time. The version string in package.json is 0.1.47, matching the latest release tag, so the repository and the release line are in step.
Editorial conclusion
Kition fits people who already keep notes and structured research in separate apps and want an agent that writes into the same project files, with a diff they can review line by line. It does not fit anyone who needs a stable, versioned tool today: the README calls the project beta and asks users to back up important workspaces. Before adopting it, install v0.1.47 from the releases page, confirm the document diff review behaves as described, and read the AGPL-3.0 obligations in LICENSE against how you plan to distribute anything built on the source.
Frequently asked questions
Does Kition run on Linux?
The README marks macOS and Windows as supported and Linux as experimental. There is no separate Linux install path documented beyond the general releases page.
What do I need to build Kition from source?
The package.json engines field requires Node >=22.19.0 <23 and pnpm >=10.16.0 <11, with packageManager set to pnpm@10.33.0. The check script also runs Python-based branding, product-language and i18n checks, so python3 needs to be available.
Can the Kition agent change my documents without asking?
The README states that when a file changes outside the editor, Kition opens a document review surface that highlights additions, deletions and rewrites, and each change can be accepted or rejected individually. The same README warns that Kition is in beta and advises reviewing agent changes before relying on them in production workflows.
Community notes