# A team runs an open-source CompanyOS in one repo, one approver > One person's prompts do not survive a second colleague. A team needs one repo, per-person permissions and a named approver before the first month ends. 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. URL: https://companyosguide.com/companyos-for-teams ## The first month, in three moves One job written down, access named by person, and a month of changes a person read. ### Week one: One recurring job, its context, its owner The job the team already repeats weekly, written down as a prompt, a method and the vocabulary it reads. What the month leaves: `agents/support-triage.md` | File | Holds | | --- | --- | | agents/support-triage.md | The job and when it runs | | skills/support-triage/SKILL.md | How this team triages a queue | | memory/glossary.md | What a priority account means | Three files before the first session ### Week two: Access named per person and per resource A group gets the queue and the support memory, and the same group gets nothing near payroll. What the month leaves: `access-review.md` - Support reads queue: yes; Support reads payroll = no; Release agent merges = no Three answers a reviewer can check ### Week four: The changes the month produced A month of work leaves a list of change requests. Three commands list them, show the diff, and land the one a person approved. What the month leaves: `kortix cr` | Command | Does | | --- | --- | | kortix cr ls | open change requests | | kortix cr diff 1 | the unified diff | | kortix cr merge 1 | merge into the base branch | The change-request commands on kortix.com/docs/developers ## The first month decides whether it compounds A CompanyOS set up by one person works until a second colleague joins. Then two folders of prompts appear, the agents follow whichever instructions were pasted last, and nobody can say which version produced Friday's draft. The repair is unglamorous: one repo, permissions that name the person, and a reviewer who reads what reaches `main`. Plan the first month around three moves, done in that order. ### Move one: one recurring job, written down Pick the job the team already repeats every week, the one with a schedule and an owner. A support queue, a pipeline review, a renewal note. Choose it because everyone can tell within a fortnight whether the agent version beats the hand-made one. A bad week costs little. Then write down what the job is, how this team does it, and the facts it needs. Three files cover it in a starter project: the agent's prompt, the skill that holds the method, and the memory entry that defines the vocabulary. A new colleague reads all three in ten minutes and can correct them. That is week one, with no schedules and no automations. ### The scoped agent, line by line One `kortix.yaml` agent block is where access becomes a file a reviewer can read. The job is one sentence, the permission is one action, and the reach is a list. ```yaml 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) ``` Read it as a hiring decision. The `prompt` line says what the agent is for, in the words a colleague would use to ask for it. `kortix_permissions` says what it may do once it is running, and here that is a read. `apps` says what it may reach, and it defaults to none until somebody names an App. [Kortix](https://kortix.com) reads the same block from `kortix.yaml`, so the answer to "what can this thing touch?" is a file in the repo rather than a screen in a console. ### Move two: permissions by person and by resource Support reads the queue, the support memory file and the customer notes. Nobody in support reads payroll, whatever else their account belongs to. Release engineering pushes branches, and the merge stays with the named approver. Those three sentences, agreed before the first session, are most of the configuration work. Permissions attach to the resource, and they cover people and agents alike. A group is the unit that keeps this manageable at ten. Define it once, add it to the queue, the memory folder and the reports its work needs, and a new colleague becomes one change instead of nine. An audit trail records who did what, which is the part a security review asks for first. Two failures show up in month two. One is a group created for a finished project last year that still carries admin. The other is an agent whose grant was widened on a Friday to get one job over the line. Both are visible in a manifest review and a member-list review, which is why the review earns a slot in the calendar. ### Move three: the approval habit Nothing an agent writes lands in the repo on its own. Work leaves the session as a change request, and a person decides whether it merges; by default an agent cannot merge its own. The gates are the other half, and teams skip them. A new project starts permissive, with the approval gates switched off until somebody sets them. Decide in week one where a mistake costs money or a customer. Leave the read-only Apps alone, because a gate that fires on every lookup teaches people to click through without reading. The approver's work is small and does not grow with the headcount. Read the diff, check the skill still describes the method the team agreed on, merge it or send it back. Four changes a week from one person is a healthy rate in month one. Forty means the reading stopped. ### Where people start work A CompanyOS nobody opens is a spreadsheet with better vocabulary. Meet the team in the window they already have open. Slack and Microsoft Teams work today. Email is experimental and switched on per project. The request, the context and the decision then sit in one thread, and the person who asked never learns a new interface. Expect the first fortnight to run almost entirely in chat, and a shift to the web app around week three, once somebody wants to read a diff or look up a grant. ### What to count after a month Two numbers say whether the habit formed: how many changes one person approved, and how many skills the team wrote or edited. Both are countable in the repo, and neither rewards volume on its own. Six approvals and four edited skills is a working CompanyOS. Zero approvals is a chat tool with a config file. Ninety is worse than zero, because it looks like governance while nobody reads. A third check costs nothing. Ask a recent joiner to find a decision the company already made. If they open the repo and have it in a minute, the memory is doing its job. ### The second month The setup that survives is the dull one. One repo, a handful of groups, an approver with a standing slot on Tuesday, and skills that get edited when the method changes. [Read the docs](https://kortix.com/docs) for the manifest fields and the change-request commands. [The checklist page](/what-a-company-os-must-contain) names the parts a candidate has to ship, and [the self-hosted page](/self-hosted-company-os) covers the case where the machine sits on your own network. ## The four questions a team lead asks first Short answers, with the longer version on the page that covers it. ### How many people does a CompanyOS need? Two is enough to start: one person who owns the job and one who approves what reaches `main`. Anything fewer leaves no second reader, so the permissions and the review never get exercised, and the next joiner inherits a folder of prompts. ### Can we limit what an agent may touch? Yes. Permissions attach to the resource and cover people and agents, through roles, groups and an audit trail. Each agent's grant sits beside its prompt in the manifest, so a reviewer reads which Apps it may reach before the first session runs. ### Do agents change things without approval? Only where nobody has set a gate. A new project starts with its approval gates off, so a team that wants a review before writes turns them on. Work still arrives as a change request that a person merges. ### Where does the team start a session? In the web app, or in Slack and Microsoft Teams, both supported today. Email is experimental and switched on per project. Most teams begin in a chat thread and move to the app once they want to read a diff. ## Name the approver before the first session. One repo, three groups and a person with a Tuesday slot who reads the diff. [Try Kortix](https://kortix.com) ยท [Self-host it later](https://companyosguide.com/self-hosted-company-os)