# Open source AI employee: three things that have to stay yours

> Open source matters for an AI employee only if the parts that make it an employee come with it. Kortix is the open-source AI Operating System, and a role, its memory and its permission rules are files in a git repo you own.

URL: https://opensourceaiemployee.com/open-source-ai-employee

## A role template is not an employee

Most open-source AI employee projects ship a folder of prompts. You clone it, point your agent at it, and the routines do real work. What you did not get is the machinery that makes the role behave like an employee: the session that runs it, the tool calls it may make, the store its memory lands in, and the rule that decides which call needs a person. Those came with the agent runtime, not with the folder.

That gap is the first thing to check. For an AI employee, open source has to cover the harness, the permission layer and the memory store, because those three decide whether the role behaves the same way on Tuesday as it did on Monday. A prompt pack on a rented runtime is open at the top and vendor-owned underneath.

Kortix starts from the other end. The role is a markdown file, the manifest points at it, and the agent runtime, the connector scope, the memory files and the trigger schedule sit in the same git repo the company owns. Open source. Read it, fork it, audit it. [The repository](https://github.com/kortix-ai/suna) is the product boundary, and you can open it before the first session.

## The three things that have to leave with you

The job definition comes first. In Kortix a role is `agents/support-triage.md` plus an `agents.support-triage` block in `kortix.yaml`, so the scope of work is a file a reviewer reads without a login. When the job changes, the change is a diff, and a bad instruction is a revert.

Memory comes second. A role that forgets is a chatbot with a job title, and a role that remembers inside someone else's database is a rental. Company memory is files in the repo, which is why changing the model does not move it.

The audit trail comes third. Session work arrives as a change request a person reviews, so what an agent changed and who approved it sit in the same history as the role it changed. A vendor that keeps any of those three on its side of the wall is renting you the employee.

## What self-hosting changes in a security review

A security review asks four things: which machine runs the work, where the credentials go, what stops a bad call, and what record is left. A hosted employee answers from a trust page. A self-hosted one answers from an architecture your reviewer can open.

Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. The role file does not change between the three, because nothing in it refers to our hosting. A reviewer reads the connector scope before the first session and sees what the role may reach.

The permission layer is where reviewers linger. Set each tool to Allow, Ask or Block, down to the arguments of each call. An Ask holds the call until a person approves it, then the agent resumes.

Approval gates you set. Off until you set them. A gate you never configured will not stop a call, so set them before the role touches a customer record.

## Where open-source routine packs stop

[markfulton/ai-employees](https://github.com/markfulton/ai-employees) is the clearest example of the other shape, and it is worth reading closely. It publishes eight roles and 60 scheduled routines as folders of plain text, with an installer and a schedule for each routine. The kits are open source, the prompts are real, and every role leaves a morning brief.

It also asks you to bring your own agent and runs the routines in that agent's session, on your own machine. The kits do carry a guardrail: each send, post and spend is drafted and held for your click. What the folder does not carry is the runtime underneath: how a tool call is permitted, what context survives between runs, and where that context lives. Those belong to the agent you installed the folder into. Change that agent and the arrangement changes with it, while the role templates stay put.

None of this makes the packs a poor choice. If the agent you already pay for is one you trust, a pack of routines gets you a working employee in an afternoon. The open-source part simply ends at the folder.

## Kortix against that shape

Both are open source. The difference is where the employee stops. In a routine pack the employee is the folder, and the machine that runs it is somebody else's product. In Kortix the folder and the machine are one repo, so the role, the connector scope, the memory and the triggers are versioned and reviewed together.

The gap shows up on the day you change model vendors. A routine pack can follow you to a new agent as long as the new agent reads the same files, and then the memory and the permission behavior are whatever the new agent provides. In Kortix the permission rules and the memory files stay in the repo, so the role keeps its rules after the swap. Any model provider with your own keys.

If you deleted the vendor tomorrow, the repo is what you would still have. That is the test to run on any open-source AI employee before you trust it with a job.

## Where the role and its reach are written down

The manifest points at the role file and names its reach; the README says where the role and the memory live.

### kortix.yaml

`kortix.yaml`

```yaml
# kortix.yaml
agents:
  support-triage:
    file: agents/support-triage.md
    connectors: all
```

Source: https://github.com/kortix-ai/suna/blob/main/README.md

### Where the role lives

`README.md`

```
One repo is the company: agents, skills, memory, connectors and triggers are files, versioned and reviewed like code.
A living company brain — plain files today, a system that compounds what it learns over time.
```

Source: https://github.com/kortix-ai/suna/blob/main/README.md

## What buyers ask before they pick one

### Is there an open-source AI employee?

Yes. Kortix is the open-source AI Operating System, and an AI employee is an agent with a role, tools, memory and approval rules stored as files in a git repo you own.

### Can an open-source AI employee run on my own infrastructure?

Yes. Kortix self-hosts for free and runs on Kortix Cloud, in your VPC or on your own on-prem network, with any model provider and your own keys.

### How is an open-source AI employee different from a free AI chatbot?

A chatbot answers one request at a time. An AI employee holds a role across sessions, calls your tools, stops at the approval gates you set, and keeps its rules in files you can edit.

### What happens to the agent's memory if I change models?

Nothing. The memory is files in the repo, so a new model reads the same record the old one built.

## Read the manifest before the first session

The repo is the review: the role and its reach are declared before anything runs.

[Try Kortix](https://kortix.com) · [Read the docs](https://kortix.com/docs)

Self-host free · Any model provider, your own keys · Slack and Microsoft Teams are live