A CompanyOS needs six parts: agents, skills, connectors and their credentials, memory, triggers and a review gate. Four of those belong in files a company can read and diff. Kortix is the open-source CompanyOS: 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 manifest that scopes an agent to a single App, and the folders the starter creates beside it.
agents: report-writer: prompt: Write the weekly report from the reports App. kortix_permissions: [project.app.read] apps: [reports] # App slugs, all, or none (the default)project repo
my-agent/├── kortix.yaml the manifest (kortix_version: 3): skills, agents, one trigger, secret names├── agents/ the prompt of each agent: kortix.md, harness-reflector.md, session-reviewer.md├── skills/ 11 skills, one folder each, with a SKILL.md├── memory/MEMORY.md the project memory└── .gitignoreA CompanyOS is judged by what it holds, not by what it calls itself. Six parts do the work. Each one fails in a way the others cannot cover for: agents, skills, connectors and their credentials, memory, triggers, and a gate that holds a change until a person reads it.
Four of the six are files. Agents live in agents/, skills in skills/, the company memory in memory/, and the connectors, triggers and grants that configure them in kortix.yaml. When those four live only in a vendor's database, the company rents its operating system, whatever the contract says.
An agent is an assistant with a job description, a model it thinks with, and permissions that decide what it may touch. In Kortix one agent is a block in kortix.yaml that points at a markdown file. A new hire can read what the agent is for before anyone grants it anything.
Remove the agents and the system holds context and produces nothing. Every task waits for someone to sit at the keyboard. That is the arrangement the buyer was trying to leave.
A skill is a written playbook an agent follows for a specific task. How this company closes a month. How it drafts a renewal note, or triages a support queue. Method lives in the skill, and method is what makes two runs of the same job comparable.
Without skills the answer comes back in a different shape each week, because the method was improvised in the prompt that morning. Nothing is left to review. Nothing improves.
A connector gives an agent governed access to an app, an API or a service the team already uses. Two things have to be true before that is safe. The grant belongs in the repo with the rest of the configuration, where a reviewer sees which agent reaches which system. The credential must stay off the agent's machine. Connector credentials are brokered server-side and never enter the machine.
Skip the connectors and the agent hands back a document a person retypes into the CRM. Skip the credential handling and the keys end up wherever the agent runs.
Memory is the part most products underbuild. Definitions, decisions, the reason a policy changed, the list a new joiner reads on day two. A person and an agent should get the same record from it.
Keep that record in files inside the project, and a model change alters who reads it, not where it sits. Keep it in a vendor's tables and the knowledge leaves on the vendor's schedule.
A schedule or a webhook starts a session, with nobody at the keyboard. That is the difference between a tool people remember to use and a system that runs.
Without triggers the agents are only as regular as the person who opens the app. The nightly reconciliation waits until someone thinks of it. Work meant for three in the morning happens at eleven the next day, if at all.
An agent that can rewrite its own instructions or the company memory needs a place where the rewrite stops. It opens a change request, and merging that request is a capability of its own, held by people unless an admin grants it to an agent.
Without the gate, a rewritten skill takes effect the moment it is written. The first reader of that change is whoever notices the output is wrong.
Kortix starts a project from the same template every time. kortix.yaml sits at the root, with agents/, skills/ and memory/MEMORY.md beside it, plus a README and a gitignore. Each skill gets a folder with a SKILL.md inside. A person can open that repo on day one and read every agent, skill and memory file before running anything.
The manifest carries the settings that are configuration rather than prose. kortix.yaml declares the machine image, connectors and triggers, and secret names and grants. Secret values never appear in the repo. So the file can pass around a team without handing anyone a key. The agent in the code panels is the same pattern in five lines: a prompt that says what the job is, a permission naming what it may do, and one App it may read.
Four checks decide whether a CompanyOS belongs to the company that runs it. A product either passes them or explains why it does not need to.
A candidate that answers yes three times and no to the fourth has a repo-shaped interface over its own database. Ask to clone a project into an account you control before you sign. Ask what happens to the memory when you stop paying.
The product at companyos.cc shares facts, procedures and templates with the AI account each person already uses. Its files and connected tools stay read-only to the AI. That covers the memory part of the checklist without a runtime for agents.
The company-os.ai entry is a free template, a .zip you download and fill in, built around one Office where you and your agents keep goals, decisions, services and money. It starts no session of its own.
The Tome, from tomevault, is a fork-friendly set of thirteen markdown skills, a justfile template and the constitutional documents an AI-instructed company keeps, open source, free to fork, with no runtime of its own. Its files pass the first check and stop there.
Buyers arrive at these products with the same request: run the work and keep the knowledge. The six parts make that request checkable.
Kortix answers the four checks with agents, skills, memory and connector settings in a repo the company owns, and a review gate on what reaches main. Read the docs for the setup order. What a CompanyOS is covers the definition behind the list. The self-hosted page names what an operator still runs, and the comparison sets the candidates side by side.
Short answers to the four things buyers ask first.
Six: agents, skills, connectors and their credentials, memory, triggers and a review gate. Four of those belong in files a company can read and diff, in agents/, skills/, memory/ and kortix.yaml. Leave one out and the system forgets the work or cannot hold it for review.
In files the company owns, inside its own project repository. A model change then alters who reads the memory, not where it sits, and a vendor change does not take the record with it. What a CompanyOS is covers the definition the rule comes from.
No. A connector is declared in the manifest beside the agent that may use it, and the credentials stay on the server, so there is no second console to configure. Connector credentials are brokered server-side and never enter the machine.
The change waits for a person. The agent opens a change request, and merging it is a capability of its own, held by people unless an admin grants it to an agent. Nothing runs on the rewritten skill until that merge.
One repo, one review gate, and files you can clone into an account you own.