An AI-first company keeps its operating model in an open-source repo

Most companies that call themselves AI-first are holding a licence bill and a slogan. The licence buys an assistant that answers in a chat window; the operating model is the part nobody bought. 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.

Tool sprawl is not an operating model

Ask the question a board member will eventually ask: where does that agent's instruction live, and who may change it? In most companies the honest answer is a settings page inside a product the company rents. The account is not theirs, and the prompt sits where only its author can find it.

That setup still produces work. It produces work whose rules are invisible to the people accountable for them.

Seats also price the wrong quantity. A licence bill grows with headcount, while the work an agent can take on grows with the grants you are willing to write and the review you are willing to staff. Two companies on the same licence bill can sit a year apart on what their agents may do, and the invoice will look identical.

An AI-first company is one whose agents, skills, memory and connectors are files the company owns. That means four questions answered in one place, and the place has to be readable by someone who did not build it.

Four things an AI-first company holds

• What its agents are, and what they may touch. Every agent has a job description, a model and a list of tools, skills, connectors and secrets. That list is the boundary.
• What they remember. Company memory is state. State that lives only in a chat window leaves when the window closes.
• What they connect to. Each connector is an account the company already owns, reached with a credential, under a rule about whether the call runs unattended.
• Who reviews what they change. A change to the operating rules changes how the company behaves next quarter. Session work lands through a change request and a merge; an edit to a grant lands as a direct commit.

Hold those four in one place and you have something you can audit, fork and hand over. Hold them across four vendors and you have a subscription portfolio with a shared password problem.

Where the four answers live

Kortix keeps them in the repository rather than in a settings page. kortix.yaml holds the agents and their grants, with company memory and skills in files beside it, and the whole starter manifest is short enough to read in one sitting. Its header says where things live: "triggers and sandboxes live here, committed beside your files." Connector routing stays out of the file, because a connected account is live project state rather than configuration.

Of those grants, two decide what reaches the default branch, and they are not the same grant. Session work reaches main through a change request that only the holder of project.gitops.merge merges. A grant edit made in the dashboard or from the CLI commits straight to the default branch under project.agent.write, with no change request and no merge (git and change requests).

Merge is default-deny for agents. The starter worker is granted kortix_permissions: all, merge included, which is why the first review of a new project is the one that replaces all with names. Approval gates you set. Off until you set them. A project left alone runs on whatever its first commit granted.

The gate is a grant, and the record shows it

On 1 November 2026 at 09:02 UTC, fix(build): restore pinned Bun daemon install (KRTX-3831) merged into dev, opened and merged by agent-kortix. Two files changed: the sandbox daemon's bun.lock, six lines in and sixteen out, and a new lockfile.test.mjs of 38 lines (the diff).

The description is what a reader would need to take the change. It names the failure ("Pinned Bun 1.3.11 frozen install fails before this change and passes afterward"), says what the regression test covers, sizes the risk as low because no package resolution moved, and gives the way out: "Revert this commit to roll back." It also records why there is no demo video: "No demo video: code-only change."

The review record is worth reading next to the merge. Strix, the automated security review, was requested at 08:07 UTC when the change opened. It covered the first commit, the lockfile change, and reported "No open security findings". The second commit added the test file, and Strix never reviewed it; the page's own note reads "Strix has not reviewed these changes." The code owner, markokraemer, was asked for a review and submitted none, and the request still shows as awaiting.

So the change landed on the merge capability, and no person signed it off. The merging account held project.gitops.merge, which is the gate this product actually has: a change request that nothing merges without the grant, and an agent that can hold the grant like any other member. The strength of the gate is therefore the grant list, and the grant list is a file the company owns.

What a month of commits shows

Between Oct 2, 2026 and Nov 1, 2026, 2,116 commits landed on the default branch of the Kortix repository, counted on first-parent history. The busiest author in that window was Kortix Agent, ahead of every person on the team, and its work arrived the way the Bun fix did: a branch and a change request.

The record is about authorship and says nothing about quality. What it measures is who edits the files that define how this company works, and for a month the largest single share of that work came from one agent. That is the part a reader can weigh: a repository where one agent is the busiest author, and the grants decide which of its changes can land.

What the operating model costs

Two swaps test whether you own the thing. Change the model and the rest stands, because the model is a line in the agent's configuration while the grants, the memory and the review path sit elsewhere in the same repository. Change the host and the same repository runs there instead: "Run it on Kortix Cloud, in your VPC, or on your own on-prem network" (self-hosted).

The cost is real, and it rarely shows on the invoice. Somebody has to own the upgrade, the backup and the identity provider. Grants start permissive and stay that way until a person narrows them, and narrowing them is a job with a calendar attached.

The honest starting size is one job. Pick the task that already has an owner and a definition of done. Write down what it may reach, and name who holds project.agent.write for the manifest and who holds project.gitops.merge for session work. Leave the rest of the company outside the sandbox until that works. A company becomes AI-first one granted change at a time, and the grant list is the part that compounds.

Next: open source is what makes a CompanyOS yours, and the permission file an agentic operating system is judged by.

Start with one job, its grant list and one reviewer. Kortix is free to start and free to self-host: Try Kortix.