What is an AI employee? The open-source definition you can check

Most definitions of an AI employee come from companies that sell one. That alone proves nothing, but it tells you to test the definition against something you can inspect. A loose definition is how a hosted chatbot gets counted as headcount.

CellCog draws the line more sharply than most vendors. Its page says an autonomous agent "runs the task you hand it, then forgets you", while an AI employee "holds a standing role with long-term memory: shift 50 remembers the decisions from shift 1" (CellCog). Those are two properties you can check: the role persists, and the memory survives the session.

Two more properties finish the test, and they are the ones a buyer forgets to ask about.

• A standing role, with a name and a scope of work that outlives one request.
• Memory that carries a decision from one shift into the next.
• Tools reached only through permissions written where a reviewer can read them.
• A human approval gate on calls that spend money, send a message or change a record.

A product that fails any of the four is something else. A new label does not change that.

Chatbot, agent and AI employee get used as synonyms in sales copy. They describe three layers. A chatbot replies. An agent plans, calls tools and checks its own result. An AI employee gives that agent a job: a name, a scope, a memory and a review rule. The agent does the work, and the employee is the arrangement around it.

The arrangement is what costs money when it goes wrong. An agent that misreads one prompt wastes one turn. An employee holding a standing role accumulates context for months, and that context is what makes a wrong permission expensive. A support role that can read every ticket and issue refunds carries a different risk from a support role that drafts replies and stops at the refund.

This is also where a job title stops being useful. Two vendors can both sell you a "support employee" and hand over completely different reach: one reads a queue, the other reads the queue, the billing records and the mailbox. The definition only becomes useful when it names what the role may touch.

A security team reviewing an AI employee asks four questions before the role may touch a customer record. Which tools can it call? With which arguments? Who approves a call that writes? What record is left afterward? A vendor that cannot answer those in writing is asking for trust instead of a review.

Kortix answers them in configuration. 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.

Set the gates before the first shift and the role is safe to leave running. Skip them and the only control left is the prompt.

The kortix.yaml excerpt on this page shows what a reviewer reads first: which file holds the role, and which connectors the role may reach. The call-level rules sit on the same project, so reach is declared once and narrowed call by call.

In a hosted product, the role and its rules live in a database you log into. You can read the settings screen, not the code underneath it.

Kortix keeps the role, its skills and its memory in files in a git repo the company owns. A permission change is a diff. A bad instruction is a revert. Session work reaches main through a change request. Merge is default-deny for agents.

Open source. Read it, fork it, audit it. That is the part that turns a definition into a review: your security team can open the role, the tools and the memory before the first session, and keep reading them after.

Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.