How to hire an open-source AI employee you can audit

A vendor's role library gives you a menu: support, sales, recruiting. It says which job you picked. It does not say which records the job may read, which systems it may write to, or which single action stops for a person. Those three answers are the role, and they fit into a file short enough to read before a demo.

Write the file first. Start with the job in one line a colleague would recognize: answer billing questions from the support queue, or prepare the Monday pipeline report. Then the reads, meaning the systems and objects the role must see, down to a queue, a folder or a table. Then the writes: the records it may change, the messages it may send, the payments it may start. Most roles carry a long read list and a short write list, and that asymmetry is the useful part.

The last line is the one buyers skip. For every write, name what needs a person: a refund above a threshold, a customer email, a contract change. A role file without that line is a job description. Job descriptions have never stopped anyone from doing the wrong thing.

Then note how the role remembers. Does it start each session blank, or does it keep the decisions from last week? A support employee that forgets yesterday will ask the same question twice, and a role with memory needs a place to keep it. That place needs an owner.

A role library answers none of this. It gives the function a name and leaves the scope to a settings screen. Two vendors can both sell a "support employee", and one may read a ticket queue while the other reads the queue, the invoice history and the mailbox. The names match. The jobs do not.

The file is also what you edit when the work changes. A new product line adds a read. A pricing change narrows a write. With the role in a file, each of those edits is a diff someone reviews, and the previous version stays one command away. That is the practical argument for writing the role down, before any comparison of plans.

Every hire is three layers stacked. The bottom layer is the runtime: a machine, a model, and a loop that calls tools and keeps session state. The middle layer is the role: instructions, examples, and the skills that encode how your company does one job. The top layer is the permission and audit layer: who may call what, which calls wait for a person, and where the record of each call lands.

A hosted vendor sells all three as one plan. Putting the runtime on their cloud is a fair trade for a team with no engineer. The role definition usually sits in their console under a name like role setup or brand context. The permission layer is a settings screen. You can read the screen. You cannot read the code behind it, and the role file does not travel when the contract ends.

Kortix is the open-source AI Operating System, and it puts the same three layers in a git repo your company owns. One markdown file holds the agent's behavior. A block in kortix.yaml names the connectors, secrets and skills the agent may reach. Connector policy then decides, per tool, whether a call runs, waits or is refused, and the rules reach down to the arguments of each call. The manifest excerpt on this page shows the split: governance in the YAML, behavior in the markdown.

That split matters at review time. A change to what the employee may do arrives as a commit, so the old rule and the new one sit side by side. The history names the person who changed it and the date. A revert puts the old rule back without a support ticket. None of that requires a vendor call, which is why the repository is the part to examine before the demo.

Five steps, in this order.

1. Write the role brief. One page: the job, the reads, the writes, the memory it needs, and the person who answers for it. A one-page template is a reasonable place to start. If two people disagree about the write list, stop here, because that disagreement is the project.
2. List the writes as individual actions. "Update the CRM" is too broad to gate. "Set a deal amount", "send a follow-up email" and "issue a refund" are three rules, and each one can carry a different answer.
3. Set the approval rule before the first session. Approval gates you set. Off until you set them. On Kortix, each tool is Allow, Ask or Block, and an Ask holds the call until a person approves it before the agent resumes from the same point. The page on approval-first rules works through the arguments.
4. Run one week under review. Read every action the employee took. Look for the calls you did not anticipate: a read that touched more records than the job needed, a write nobody had discussed, a retry after a failure. Narrow the rules and run the week again.
5. Price it. Only now do the credits and the machine hours mean anything, because you know the volume the role produces. A quote taken before this point measures the vendor's packaging, not your work.

The sequence costs a week of attention and saves a quarter of cleanup. It also produces the document a security reviewer will ask for, and the document a new colleague reads when the role changes hands.

Two costs make up the bill: the model calls and the machine that runs the session. A seat price hides both. It buys access to a vendor's role library, and the calls are metered somewhere else or bundled at a rate the vendor sets.

Kortix runs on credits. Free is $0 with 500 credits per month, managed models, every feature and 1 project. The paid plan is credits: 25 tiers from $50 a month (5,000 credits) to $50,000 a month (5,000,000 credits), at 100 credits per dollar. Members are free, and the account shares one credit pool. Check the pricing page for the current figures, since tiers change.

Hosting decides the second cost. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. On a self-hosted install the subscription disappears, and the costs that remain are the machine and the model calls. Both appear on bills you already receive, which means you can forecast them and check them.

The first month carries a cost no vendor quote lists. Someone writes the role file, connects the tools, reads the week of logs and narrows the rules. Put those hours in the same spreadsheet as the credits. The pricing analysis on this site goes through the seat, the usage and the exit for three vendors, and the arithmetic applies to an open-source install too.

Ask one question of any hosted product: when the employee wants to send an email to a customer or move money, what happens next, and who can read the record afterward? The answer decides whether you supervise a colleague or trust a settings screen.

Kortix's connector policy covers this: every action is allowed, gated, or blocked, and every call is logged. The public product index states the result in one line: an "AI employee" whose tool calls a person approves first, with Allow, Ask or Block per tool. The role file and the rules sit in the repo, so a reviewer reads the rule and the output in the same place. Session work reaches main through a change request. Merge is default-deny for agents. A hosted console gives the reviewer a screenshot. The repository gives a diff, a date and a revert.

The irreversible action is the other half of the question. A refund, a payment, a contract signature and a customer email share one property: after they leave, no draft can take them back. A chat window that asks "are you sure" is not enough, because the message shows little about the call and the answer is not attached to the record. The gate has to name the tool, the arguments and the person who may approve, and the record has to keep all three.

That record is where a hosted plan usually ends. The console can show a timeline while the contract runs. When it ends, the role, the rules and the history stay behind, and the next team rebuilds the job from memory. An open-source install keeps the role, the rules and the memory in a repository the company controls, so the next team starts from the actual job. For a role that holds context for months, that difference is the hire.