Company as code in an open-source repo you own

What a file is

Most agent setups keep their instructions somewhere only the tool can open. A record in a hosted console. A row in a database. A chat that scrolls away. Company as code moves that material into plain text. A project is one git repository. Its agents, skills, memory and connector settings are files in it.

Start at kortix.yaml in the root. The file opens with the project name and the environment it needs. Then come connectors, skills, and one block per agent. An agent is one agents.<name> block in kortix.yaml: its behavior (prompt or prompt_file, model, permission) and the registered skills, tools, commands and extensions it enables. agents/<name>.md holds the prompt alone. permission sets allow, ask or deny per tool.

The example manifest on kortix.com declares four agents, and its engineering one is eight lines: a description, a prompt file, four tools, two connectors, one skill, one extension and a workspace line. A project from kortix init starts smaller, with one agent called worker. Above the agent blocks, skills: maps a name to a directory. tools: maps one to a TypeScript file. extensions: pins a package from npm or a file in the repo. Triggers at the bottom say what starts each agent. A signed webhook for a new issue. A cron line for the Tuesday post.

Two people can read that file and disagree about one specific line. A question about what the sales agent may reach has an answer that does not depend on a session being open.

What stays out of the file

Credentials stay out. A manifest that carries an API key is a liability with a git history. Every clone of the repo hands the key to whoever reads the clone.

The Kortix manifest avoids that in a way a reader can check. env: lists the names of the secrets a project expects. connectors: lists each app by slug and the provider that brokers it. The credentials live in Kortix, never in the file. A reviewer opening a change sees GITHUB_WEBHOOK_SECRET as a name. The value sits somewhere else, set by someone with the right to set it.

The file also holds the rules that bound an agent. Under a connector, policies: matches a pattern of calls and can require approval before one runs. In the example manifest, any call matching linkedin.create_* waits for a person. That line does more work than it looks like it does. It separates an agent that can draft a post from one that can publish without asking. And it sits where a non-engineer can read it and an engineer can review it.

What a diff shows

A chat history records what someone typed. A diff records what the company changed. The second one is what makes a tenth agent easier to run than the first.

Session work reaches main through a change request. Merge is default-deny for agents. An agent proposes a new skill, a rewritten prompt, a line in its memory. The proposal arrives as a change someone reads against the version that ran yesterday. Who approves a change is a per-project question. The answer is a person on the Review page.

The small review unit is the point. A diff on a memory file shows the sentence added after a support call. A diff on a skill shows the tool it gained. A diff on the manifest shows a connector that appeared and the policy line that limits it. None of that survives in a transcript. There, the decision and the discussion sit in the same scroll.

Version control settles a second argument too. The version that ran last week is a commit. Comparing it with today's takes one command.

The week the files stopped being true

Files alone are not company as code. A published write-up ends with the owner finding half of the agents' own files unupdated. Each main agent ran as a separate Linux user with its own gateway, and kept markdown memory: IDENTITY.md, SOUL.md, USER.md, TOOLS.md, HEARTBEAT.md, plus a daily memory/YYYY-MM-DD.md.

The format was not the problem. Markdown in a home directory is as readable as markdown in a repo. What was missing was the step that turns a file into the company's version of events. A person opens the change, reads it, merges it. A memory file that only its own agent writes is a draft nobody accepted.

That is the failure company as code exists to prevent. It is also why the review matters more than the file extension. Memory needs a place where a person can correct it. The correction has to be routine.

The first four files to move

Test the idea on the material that changes least often and hurts most when it is wrong:

• the prompt each agent runs, because a stale prompt is expensive in a way a stale note is not;
• the skills an agent may call, because each one names the tools behind it;
• the memory every agent should inherit about customers and tone;
• the policy on the connectors that can spend money or speak in public.

Put those four in the repo and open the first change request by hand. Then read the diff as a stranger would. If it does not say what the company decided, and who decided it, the file is a copy of somebody else's truth. The agents will restart from it next month. A company that runs on agents keeps one habit. The operating rules live in a repository a person can read. Every change arrives for review. And last quarter's version is still there when the argument comes back.