Skip to content

The open source private AI stack has no owner for its rules

An open source private AI stack is five parts and ten projects, and the rules that make it safe sit outside all of them. Kortix is the open-source AI Operating System: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers.

The rules, the approvals and the agents in one file

From the kortix.yaml reference: a project policy mode, one blocked call, an approval lifetime and an agent, all in the manifest at the repo root.

kortix.yaml
policy:
  default_mode: risk
policies:
  - match: "helpdesk.delete_*"
    action: block
approvals:
  ttl: 4h
# Agents: each one enables registered things by name.
agents:
  support:
    description: Answers help desk tickets.
    mode: primary

Source: kortix.com/docs/project/manifest

The stack a company assembles

A team that decides to keep its AI private ends up assembling the same parts, whatever the vendor deck said. A chat window in front of a model. A runner holding the weights. Something that reads the shared drive. A canvas for workflows, and an agent that reaches into more than one system. Each part has two or three open source projects that do it well, and a search for the parts returns those projects.

They fit together because they speak the same protocols. Open WebUI talks to Ollama. AnythingLLM indexes a folder and answers from it. Dify and n8n call a model through whichever key you hand them. Nothing fights, and one person with an afternoon can wire most of it together.

What that produces is a private chat app with retrieval. Three things turn it into a business system, and no project in the picture owns them. They are the instructions an agent gets, the limits on what it may touch, and the record of what it did. What private AI means for a business covers why those three decide the contract. Naming the parts precisely matters, because the gap between them is where the review lands.

Which project does which job

Each job maps to the projects people get recommended for it, the licence each project publishes, and what the job leaves to you.

Component jobChat front endProjectOpen WebUI, LibreChatLicence as publishedOpen WebUI licence: BSD-3 style, with a branding condition; LibreChat MITWhat the job does not coverReading and prompting, with no rules file behind it
Component jobSearch and retrievalProjectOnyx, AnythingLLMLicence as publishedMIT, except ee directories under the Onyx Enterprise licence; AnythingLLM MITWhat the job does not coverAnswers from documents, with nothing gating an action
Component jobModel runnerProjectOllamaLicence as publishedMITWhat the job does not coverTokens only, with no tools, memory or record
Component jobWorkflow engineProjectDifyLicence as publishedModified Apache 2.0 with additional conditions; commercial licence required for multi-tenant useWhat the job does not coverA canvas someone draws, not the agent's rules
Component jobAutomationProjectn8nLicence as publishedSustainable Use License (fair-code); .ee files under the n8n enterprise licenceWhat the job does not coverSteps run without a person seeing each one
Component jobExecution agentProjectOpenHands, OpenClaw, Hermes AgentLicence as publishedMITWhat the job does not coverOne machine, one operator, with no branch or review
Component jobCompany memoryProjectNot one project hereLicence as publishedNot applicableWhat the job does not coverNobody holds it as a file you can diff

Every licence in that column is the one the project publishes in its own repository: Open WebUI, LibreChat, Onyx, AnythingLLM and Ollama in the first three rows. The same goes for Dify, n8n, OpenHands, OpenClaw and Hermes Agent. The last column is a boundary each project draws itself, rather than a missing feature waiting on a pull request. A chat interface does not claim to police an agent. A model runner does not claim to remember anything.

Two of the execution agents go further than a chat window. Hermes Agent ships six terminal backends, local, Docker, SSH, Modal, Daytona and Vercel Sandbox. Its learning loop writes new skills out of what it did (Hermes Agent). OpenClaw runs on your machine and works from WhatsApp, Telegram or any chat app, stewarded by an independent 501(c)(3) (OpenClaw). Both are built around one operator, which is the right shape for one person and the wrong shape for a team of forty.

What the stack leaves to the team

Three things, and each one is a document the stack has no place to keep.

The rules, as files someone can diff. In most of these products an agent's instructions are typed into a form and stored in a database. That works until a reviewer asks what the prompt said in March, or why it changed on a Tuesday. The honest answer is a backup, and a backup is not a diff. A company running agents across a support desk and a finance system needs the rules reviewable as text. Same review as the code that calls them.

An approval between a plan and an action. Workflow engines already have a human step, and people point at it as though the problem were solved. It covers the flow, not the moment an agent decides to send an invoice reminder to four hundred accounts. That decision happens inside a tool call, after the plan and before the effect, and the gate has to sit there. A canvas cannot hold it, because the canvas ends where the agent begins.

A record of what ran where. Every project in that table logs. Each log is scoped to its own product, and none of them knows what the others did. A security review asks a narrower question: which agent, holding which instructions, on whose machine, approved by whom, at what time. Rebuilding that answer from a stack of log stores is a project in itself, and it is usually started a week before the audit.

Where Kortix fits, and what it does not do

The table names ten projects. Kortix is the layer underneath them, and the layer is a repository. The instructions a project keeps are files in it, so last month's prompt is one git show away. A colleague who wants to change it opens a change request, and the diff shows what changed.

The rules that the stack leaves to you have a home in it. "Approval gates you set. Off until you set them." Each gate is a line in the project manifest, reviewed like any other change. "Every action is recorded. Reading, exporting and streaming the audit log depend on the plan." "One isolated sandbox per session. Each session has its own isolated machine and branch." "Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free."

The limits belong on the same page as the offer. It is not air-gapped, and we will not pretend otherwise: agent sandboxes run on the compute provider you configure, and your instance has to be reachable so they can call back. The machine the agent works on is rented even when the operating system is not. Kortix also ships a chat window, and that window is not the reason to pick it. Keep Open WebUI in front of the team if they like it, because the repository is where the work lives.

The smallest honest test

Take one workflow the business already runs, and run it in whichever interface the team prefers. Then ask two things of the setup: the instructions the agent was given, and the record of what it did with them.

Both answers should arrive as a file you can open on a laptop that is not connected to the vendor. If the instructions come back as a screenshot of a settings page, the stack is a rental with a private address. If the record comes back as a support ticket, it will still be a support ticket at the next audit. The test takes an afternoon, and it decides more than the feature list does.

The parts and the layer are both real options. The comparison of private AI platforms puts the vendor products beside each other on the same questions. Running AI agents privately covers the server and the model keys, and the self-hosting guide walks through the first run on a host you own.

What people ask before assembling the stack

Short answers, with the part each one leaves in place.

No, if completely private means with no network at all. Every project here talks to a model and runs the work on a machine, and Kortix is no exception: its sandboxes run on compute you configure and its instance stays reachable. What you can own is the instructions, the memory and the record.

Install the parts you need on a server you control, or install the layer underneath them. Kortix self-hosts as one Docker Compose stack: point DNS at the host, sign up as the admin, add a model key, then set EMAIL_URL or DISABLE_SIGNUP=true and restart.

Whichever one hands you the files. Ask for the agent's instructions and the session record as a download, then try to run the same workflow somewhere else. The project that answers with a document keeps your options open.

Yes. Ollama, Open WebUI, LibreChat, AnythingLLM, Onyx, Dify, n8n, OpenHands, OpenClaw and Hermes Agent all publish their code under the licences in the table. Kortix is open source too, and self-hosts as one stack.

Clone the repository before you wire the parts together

The rules, the approvals and the record are what the next review asks for, and the test takes an afternoon.