My AI Workforce: Fifteen Employees, One Boss
15 AI employees run my business: sales, inbox, leads, websites, content, video, books, SEO, bookkeeping, security, management. Who does what and what I do.
Read the articleSeptember 21, 2026 · 16 min read
Whether you should buy or rent an AI employee comes down to one question: who owns the description of its work afterwards? 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. Buying, in this market, usually means a provider builds the employee for you as a project. Whether the description of its work belongs to you afterwards is settled by the contract, not by the word “buy”.
I run fifteen AI employees this way, fourteen 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.
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.
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.
| Term on the platforms | What it means there, per the docs | What it is in my folder |
|---|---|---|
| skill | a named playbook, loaded only when relevant, stored in a personal, workspace, or built-in scope | a SKILL.md file in the employee’s folder; Claude loads it when relevant or when I call it, per the Claude Code docs |
| instructions or prompt | who the agent is and how it behaves, written in the interface | CLAUDE.md, a text file with role, rules, limits, and approvals |
| knowledge | documents attached to the agent | the files in the folder, which is the business itself |
| credits or actions | the metering unit for work done, per user or per tool run | none; the Claude plan has usage limits, but no counter per task |
| model | a setting per task or per agent | /model within the Claude family, and a different tool if I need to leave the family |
| approver | a named person in the workspace | me, in the rulebook, with the approval written down |
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.
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.
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.
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.
| Checkpoint | Subscription platform, per the docs | Folder plus Claude, my setup |
|---|---|---|
| What you operate afterwards | a workspace, seats, integrations, skills or tools, an approval queue | a folder of text files and a terminal or the Claude app |
| How it is billed | per user per month, plus credits or actions for work done | one subscription, no counter per task |
| What happens when you switch the model | a setting per task or agent, across several providers | a command within the Claude family; across providers I switch the tool, because Codex and OpenCode read the same files |
| Where your work lives | in the platform’s interface | in files I can read, copy, and version |
| When it is the right choice | when someone else should run it, and when a team needs it in Slack | when one person leads a few roles and wants to own their files |
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.
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.
I do not think platforms are the wrong tool. They are the right tool for a different business than mine.
If two or more of these apply, rent. If none does, the rest of this post is for you.
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.
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.
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.
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.
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.
“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.
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: bring the platform you are considering to the weekly live Q&A call in my community, and we work through it on your own case, next to the folder way. Then you decide which one you want to own: AI Employee Framework.
15 AI employees run my business: sales, inbox, leads, websites, content, video, books, SEO, bookkeeping, security, management. Who does what and what I do.
Read the articleHow to build an AI employee: course plus platform, n8n or Make, Langdock, subscription platform, framework, or a folder plus Claude. What you run after.
Read the article
Kevin Welter
Developer, IT architect, author of technical books (Kubernetes, cloud infrastructures) and speaker. Runs his business with an AI workforce of fifteen AI employees and shows solo business owners in his community how to hire their first AI employee.
Your first AI employee up and running within an hour
Join the community$5/month founding price, first 50 members