An AI employee, as the subscription platforms sell it, is an agent that lives in the vendor’s workspace: it connects to your tools, follows playbooks the platform calls skills, runs on a pool of credits or a count of actions, and waits for a named person before anything goes out. What you rent is the runtime, the integrations, the skills library, and the approval screen. What stays in the platform is the thing that makes the employee yours: the description of how it works, written in the vendor’s interface, billed per user per month. My AI employees are the opposite construction: each one is a folder of plain text files on my computer, readable without a login, and the subscription behind it is the one Claude plan I have anyway.
I run fourteen AI employees this way, thirteen of them with a page of their own on the team page, each with a personnel file, a rulebook, skills, and a mailbox folder. Who does what is in My AI Workforce; everything on the topic sits on the Hiring an AI employee page.
What an AI employee is on a subscription platform
Two platforms use the term most visibly. Everything below is from their documentation, retrieved on 21 September 2026, and describes their products as they present them, not my experience with them.
Lindy puts it in one sentence: “Lindy is an AI employee. It lives in your Slack, connects to your tools, and comes back with the work done.” The building blocks are skills, credits, and approvals. A skill is “a playbook you teach Lindy: a named set of instructions for a procedure you repeat, like how I write my weekly report, how I triage my inbox, or how I prep for a customer call.” The employee “always sees the list of available skills, just their names and descriptions” and “loads a skill’s full instructions only when the skill is actually relevant to what you asked.” Credits “measure the work Lindy does”; they “belong to the workspace, not to each person, and every seat adds its tier’s allotment to the pool.” On models: “Pick your model of choice for each task. Most major models are available.” And on safety: “Anything with outside impact waits for a named approver: sending an email, updating a ticket, posting to another channel, publishing a doc.”
Relevance AI calls itself “the home of the AI Workforce” and defines the unit like this: “Agents are powered by LLMs that plan and complete tasks on autopilot. They are given tools, and decide how to use tools to achieve goals prompted by you.” You build one by writing a prompt that tells the agent “who it is, what it does, and how it should behave”, adding tools, optionally knowledge, and triggers that run it “on a schedule, from a webhook, or from an integration”. Billing counts actions: an action “is counted when an Agent runs a Tool”, whether that is “a simple task like sending one email or a complex workflow with many steps.” Model use is covered by vendor credits, or you “bring your own API keys to bypass them entirely”. In approval mode, “the agent will draft its intended action and wait for human approval before proceeding.”
Read those two descriptions next to each other and the shape of the product is clear: a runtime that holds instructions, tools, and approvals, metered by work done, with the model as a setting.
Skills, credits, actions: the vocabulary, and what it is in my folder
What strikes me reading the docs is how close the vocabulary is to my own setup. The concepts are the same. What differs is where each one lives.
The parallel shows what you are paying for on a platform: not for a concept you cannot get elsewhere, but for the place where it lives and for someone else running that place.
What renting an AI employee means in the German market
The English term maps onto a German one, “KI-Mitarbeiter mieten”, and several German-speaking providers use it for a subscription rather than a project. The shape, from their pages as retrieved on 20 September 2026 and without naming anyone: a fixed role with concrete tasks in your tools, set up by the provider, billed monthly, sometimes with a setup fee up front and sometimes cancellable month by month. One of them puts the logic well: AI is not a project with an end date.
That is a fair offer for a business that wants the employee built and run by someone else. The trade is the same as with the platforms: runtime and operation for a monthly fee, and the description of the work stays with the provider.
Frieda on a platform and Frieda as a folder
The employee I use to compare every way of building is Frieda, who sorts my inbox. Her method is public: five piles, three questions, rules with a feature and a reason, written up in Sorting Your Inbox: The Pile System. What she does and what she never touches is on Frieda, my office assistant.
On a subscription platform, as a thought experiment rather than a report: I would write her sorting rules as a skill, attach my sender list as knowledge, connect the mailbox as an integration, set myself as the approver for anything that goes out, and pick a model per task. Every sorted email would count against the credit pool or as an action. That would work.
In my setup Frieda is a folder. Her sorting rules are in her file, the mailbox is connected through an official connector, and she reads, sorts into four piles plus one for my judgment, drafts replies for the “today” pile, and never sends. If a rule changes, I change one line in a text file, and I can read the whole rulebook without opening anything but a text editor.
The five checkpoints, without prices
For every way of building an AI employee I ask the same five questions. Here they are for the subscription platforms and for the folder.
One row deserves honesty in my own favour and against it. On model choice, the platforms are more flexible than I am inside Claude Code: they switch across providers with a setting, while I switch within the Claude family. What I have instead is the file: it is plain Markdown. Claude Code reads it, OpenCode reads it too according to its docs, Codex reads the same format as AGENTS.md, and Claude Code in turn also reads AGENTS.md, the format other coding agents use. So the thing that survives a model or tool change, in my setup, is the employee itself.
What you actually rent, and what stays yours
Put simply: on a platform you rent the runtime, the integrations, the skills library, and the approval screen. Those are real work, and someone has to run them. What stays in the platform is the description of your employee: its instructions, its skills, its knowledge, its limits. You can read them there, but only there.
In my setup that description is the employee. Frieda’s rules, her limits, and every correction I have ever given her are text in a folder that I own and that any tool reading Markdown can use. The runtime is replaceable; the file is not. What belongs to you after you cancel a subscription is, for me, the question that decides which construction fits.
When a subscription AI employee is the right choice
I do not think platforms are the wrong tool. They are the right tool for a different business than mine.
- Someone else should run it. If you want an employee set up, operated, and updated without touching a file, a subscription is exactly that. The German rental offers are built for this.
- A team lives in Slack. Lindy’s docs describe an employee that works in threads and mentions, drawing on a shared credit pool. If ten people need to address the same employee, a folder on one laptop is not the answer.
- Triggers without a human. Relevance AI runs agents “on a schedule, from a webhook, or from an integration”. My employees need a start, which I want, because I keep the approval. For a process that must run at three in the morning, that is a limit.
- Model mix across providers in one process. If you need GPT for one step and Claude for the next, the platforms have that as a setting.
- Compliance evidence. Some platforms publish certifications on their security pages. A folder on a laptop does not.
If two or more of these apply, rent. If none does, the rest of this post is for you.
Build your AI employee team without a platform
The path to a first employee runs in the Claude app, without code: choose a task, write the personnel file, hold the onboarding conversation, and let it do a first piece of real work. The steps are in Creating an AI Employee: How to Start. What Frieda’s file looks like word for word, with role, rules, limits, files, and approvals, is in CLAUDE.md: Claude Code’s Memory, and how a skill is a Markdown file you write once and reuse is in Claude Skills: How to Create and Use Them.
Writing the first file is the hardest part, and you do not have to do it alone. In my community the employees sit as ready-made packages, Frieda among them, and in the calls we read through your file together.
Frequently asked questions
What is an AI employee?
On the platforms, an agent in the vendor’s workspace with skills, integrations, a credit or action budget, and a named approver. In my business, a folder of text files: a personnel file with the job, a rulebook with limits and approvals, skills, and a mailbox, run on Claude. Both are agents led by rules; the difference is where the rules live.
What is the best AI employee platform or AI employee software?
The one whose billing shape and runtime fit your business, which is not a ranking anyone can give you from outside. In the products, “employee” software and “agent” platforms hardly differ; both offer instructions, tools, triggers, and approvals. Ask three things: what you operate after signing up, how work is metered, and in what form your employee exists if you leave.
How much does an AI employee cost per month?
On a platform: a seat per user per month plus credits or actions for the work done, per the vendor’s current pricing page. In my setup: the Claude plan I use anyway, and community membership if you want the ready-made packages. What the Claude plans currently cost, with a date, is in Claude Pricing and Plans Explained.
Can I build my own AI employee without a platform?
Yes, and without code. A task, a personnel file, and an onboarding conversation in the Claude app are enough for a first real result; the steps are in Creating an AI Employee: How to Start. Claude Code comes later, when the employee should work directly on your files and systems, and even then you lead in plain language.
What is a digital employee, and is it the same thing?
“Digital employee” is the older term for the same idea, used mostly by agencies and rental providers: a software role with a fixed job in your tools. Technically it is an agent with instructions and integrations. Whether it is rented, built for you, or a folder you own is the question that matters more than the label.
Where to go from here
If you are choosing between a course that teaches you a platform stack and a method you can carry between tools, read After the AI Course: What Runs Every Month next; it is the same question from the other side. The full comparison of all six ways to build, with the five checkpoints for each, is in Building an AI Employee: Six Ways Compared.
And if you want to see the difference rather than read about it: in my community’s calls we rebuild your Frieda on the platform you are considering, and then as a folder. Then you decide which one you want to own: Claude Practitioners.
