A four-week open-source plan for a company run by agents

Week one: three agents in one repository

A month is a realistic window for getting a company on agents into working order, and almost none of it goes to the model. The first week is a repository with three roles in it, written so a stranger can read who does what.

kortix init writes a project from the starter: a manifest, one agent called worker, eleven skills in their own folders, and a memory file. That is a working project, not yet a company. Week one replaces the single worker with three roles you can name.

Name the roles before you write a single prompt. The seven-agent company written up here is the caution: the chart is published, and two of its agents still ran on the blank IDENTITY.md template.

The fix is small and boring. Write the chart into the repository, one block per role, with a description a person outside the project would understand. 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.

Three roles are enough for a first week, and narrow ones are easier to check. An agent that triages the shared inbox. An agent that drafts replies a person still sends. An agent that turns a week of messages into a status note. Each gets one prompt file, a short description, and the smallest tool list that works.

You have finished week one when kortix validate passes and a colleague who has never opened the project can say, for each agent, what it does, who starts it, and what it can reach. The artifact is the repository itself: three agent blocks, three prompt files, one README line per role.

Week two: the file that says what an agent may not do

Permissions are the part most teams skip, and the part that decides whether the month ends with a company or with a demo. One file carries it, kortix.yaml, in two places.

The first place is each agent block. There, permission sets allow, ask or deny per tool, so an agent that reads mail does not need a shell. A drafting agent keeps edit on its own files and loses the connectors it never uses. Every line you grant is a line someone can read against the job later.

The second place is the connector section. A policies entry matches a pattern of calls and decides whether one runs or waits for a person, which is how a rule reads on the call that publishes a post or moves money. That rule is worth more than a paragraph of intent in a prompt, since it holds even when the model has a bad day.

Then write the memory. memory/MEMORY.md is the project memory index, what the project is and how it works, and a system skill tells each agent to read it at the start of a task. That makes the file's author matter: in the write-up linked in week one, the owner's audit found half the agents' files unupdated, and the only writer had been the agent that owned them. One index whose first author is a person, holding what the company sells, how it sounds and which customers matter, is steadier.

Week two is finished when three things are true. Every agent whose job is reading has edit: deny. Every call that speaks in public or spends money waits for a person. The memory file's first commit has a human name on it. The artifact is the policy: one deny rule, one ask rule, and a memory file that says what the company is.

Week three: the first change request a person merges

Now the loop gets tested. Start a session and the agent works on its own branch, named after the session. Ask for something small and project-shaped rather than a feature: a skill for the draft reply, a tightened prompt, a sentence in memory.

The change has to arrive as a proposal. When an agent changes the project itself, for example a skill or its memory, it opens a change request. A person reviews it on the Review page and merges it. Read the diff before you merge. A dropped step in a skill is visible there in a way it never is in a chat transcript, and the diff is the only place the change sits at a size a person can hold.

This week separates two kinds of first month. A team that spent week one comparing models has nothing to put in front of a reviewer: no role, no prompt file, no rule to read against the diff. Its month restarts here, with the model already chosen and no evidence about whether it fits the job. A team that wrote the roles first gets a merge in week three and a real question with it: was the prompt clear enough for the job? How approval works on a change is a per-project decision, and week three is when it gets made for the first time.

You have finished week three when kortix cr merge has landed one change, git pull brings it into your clone, and you can explain the diff in one sentence to the person who owns the outcome. The artifact is the merged change request, with a reviewer's name on it.

Week four: the schedule, and where it runs

A company needs work that starts without anyone typing. Triggers live in the manifest, in a triggers: block, and a schedule is an on.cron entry with a six-field expression, seconds first, so 0 0 9 * * 1 is nine in the morning every Monday. Point it at the agent that writes the status note.

Keep the schedule in the repository for the same reason as everything else. The owner's published write-up records a cron job every five minutes so each agent's gateway checked the other, and it worked: one crashed process was restarted without the owner noticing. It was also invisible from the org chart, a line in a crontab on one VPS. In a manifest, the same intent is a reviewed file, and a reader can see what fires at nine on Monday before it fires.

Then decide where the company runs and write the answer beside the schedule. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. The choice changes the address and the backups, not the files, because the repository holds the agents and the schedule either way. Company as code is the longer argument for keeping all of it in one place.

Week four is finished when a trigger is merged through a change request and a named person agreed to read the output of its first run. The artifact is the schedule: one trigger block, one agent named in it, one reviewer.

That is the month: a repository with three named roles, a policy section with a deny rule and an ask rule, one merged change request, one schedule. Week five starts with the model question, and by then you can answer it from a diff, a prompt that failed and a rule that caught something.