You can build an AI employee in six ways today: with a course that teaches you two or three platforms; with a workflow tool like n8n or Make; with a platform for organizations like Langdock; as an employee on subscription from a platform like Lindy or Relevance AI; with a developer framework like LangGraph or CrewAI; or as a folder of text files that runs on Claude. Each of these ways works, for the job it was built for. The difference doesn't show on day one but afterwards: what you run, how you're billed, what happens when you switch the model, and whether your work lives in a tool's interface or in files you can read yourself. For a solo business or a small team, the sixth way is enough in my experience. Once you have several users, compliance obligations, or fixed processes with volume, the others are the better choice.
I have run two of these ways myself: n8n lived in my own Kubernetes cluster for a long time, and I tried Langdock. Today my fourteen AI employees run as folders on Claude, each with a personnel file, a rulebook, skills, and an inbox, the way they appear on my team page. I collect the basics on the AI employees page, and I wrote up the thinking behind it in Building AI Agents Without Code: My Way. This post is about the choice before that: which way for which business, checked with the same five questions.
Five tests, six ways at a glance
I ask every way the same five questions, in the same order: What do you run afterwards? How are you billed, per user, per execution, per action, or one subscription for everything? What happens when you switch the model? Where does your work live, in the tool's interface or in files you can open and read? And when is this way the right choice?
Plus one task I rebuild in my head for each way: Frieda's inbox. Frieda is my office assistant. She reads sender, subject, and preview, puts every mail on a pile, drafts a reply for the urgent ones, and sends nothing herself. The rules are in Sorting Your Inbox: The Pile System. I haven't built Frieda six times. But for each way I can say which parts she would consist of there, because I know the building blocks from the vendors' documentation and have run two of the ways myself.
Way 1: a course plus two or three platforms
A typical course on building AI agents teaches you a tool stack: usually a platform for chat and agents, plus a workflow tool for automations, sometimes a third tool for special cases. You learn how to set up agents there, upload knowledge, and connect processes. If you start with no prior knowledge, you get an overview quickly that way.
Afterwards you run every tool from the course, each with its own account, its own billing, its own updates. The course ends, the subscriptions continue. Whether and how you switch the model isn't decided by the course but by the tool. And your work lives where you built it: in two or three interfaces that know nothing about each other. Frieda in this way would be an agent in the chat platform with uploaded rules, plus a workflow in the automation tool that fetches new mail and hands it over. Two accounts, two places where the rules live.
A course is the right choice if you want guidance and the tools it teaches already fit your business, say because your team is already on one of those platforms. What keeps running every month after the course, and how I solved that for myself, is in After the AI Course: What Runs Every Month.
Way 2: a workflow tool like n8n or Make
This is the way I walked myself the longest. n8n ran in my own Kubernetes cluster for a long time, I built processes in it, and for a while I used Claude Code as the trigger: Claude Code kicked off an n8n process, n8n executed it. I like n8n. I don't know it from the docs, I know it from operating it.
An AI agent there is a node in the workflow. According to the n8n documentation, you connect a chat model and one or more tools in the Agent node, and "the agent decides which tools to call to complete a task". In Make, an agent consists, according to the help page, of "a brain (llm), instructions (system prompt), memory (context), tools" and a thinking process. In both cases you build a diagram: trigger, agent, model, memory, tools, credentials. With n8n you optionally add your own server, which according to the docs "Requires setup (npm, Docker, or server)", or take the cloud variant. You switch the model by swapping the chat model node; n8n offers nodes for many providers according to the docs, including local models via Ollama. Frieda in n8n: a trigger on the mailbox, an Agent node with the sorting rules as system prompt, a chat model node, a memory node, a tool node for filing, credentials, plus a server or cloud account.
Why I work differently today: the work lived in the workflow. My rules sat in a field of a node, not in a file I could read, hand to another model, or carry into another tool. That is not a weakness of n8n but its design, and for fixed processes exactly this design is right. A workflow tool is the right choice when your process is an assembly line: same steps, high volume, triggers around the clock with no human in between, or when you need local models in the process. What I learned while building is in n8n AI Agent: What I Learned Building One; the comparison of the two tools with each other in n8n, Make, or Claude: What For?.
Way 3: a platform for organizations like Langdock
Langdock describes itself as the platform an organization uses to adopt AI: chat for everyone, agents for recurring tasks, workflows for automations, all in the browser. According to the documentation, an agent there is a specialized chat with saved context, "documents and instructions". You pick the model with a click in the input bar and, according to the docs, can switch it mid-conversation across several providers. The application is hosted in the EU according to the vendor. Billing is per user and month. Frieda in Langdock would be an agent with the sorting rules as instructions, the pile description as an uploaded document, an integration to the mailbox, and a user account everything hangs on.
I tried Langdock. For my business I stayed with the folder, for a reason that has nothing to do with the platform's quality: my work should live in files that belong to me and that I can open with any tool. A platform for organizations puts it where the organization can manage it. That is right for an organization and unnecessary for me alone.
Such a platform is the right choice when several people should use the same agents, when someone has to centrally manage who may do what, when you need models from different vendors in the same process, or when you need evidence for an auditor. The full comparison is in Langdock vs Claude: What I Use and Why.
Way 4: an employee on subscription
Platforms like Lindy or Relevance AI sell the AI employee as a finished product, as an "AI teammate" or an "AI Workforce". You sign up, pick or assemble an agent from building blocks, connect your tools, and let it run. Lindy advertises "40+ skills" out of the box on its pricing page and bills in credits per user and month; Relevance AI counts actions according to its documentation, "counted when an Agent runs a Tool", plus credits for model usage.
What you run afterwards: little, and that's the point. Account, agents, credits. The vendor runs the platform; you pick the model per task or, with some vendors according to their docs, bring your own key. Your work lives in the platform. Frieda on subscription would be an agent from an email assistant template, adapted with your rules, connected to the mailbox, paid in credits per action.
A subscription is the right choice when someone else should take over operations and you want to pay for not having to look after anything. What exactly you rent there, and why my employees belong to me because they are files, is in AI Employee Platforms: What You Really Rent.
Way 5: a developer framework
LangGraph, CrewAI, the OpenAI Agents SDK, the Claude Agent SDK: these are libraries for people who program. LangGraph describes itself as "a low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents", CrewAI requires Python according to its installation guide, the Claude Agent SDK is available according to the docs "for Python and TypeScript only". What you build with them is software that contains an agent: your code, your hosting, your API keys, your updates. You switch the model in code, often in one line. Frieda as a framework would be a Python program: agent object, model client, functions for mailbox and filing, a database for state, a server.
A framework is the right choice when the agent becomes part of a product you ship to others, or when you have a developer team to maintain it. I am a developer and still decided against it, because I wanted to lead employees, not maintain software.
Way 6: a folder plus Claude
This is how I work today. Each of my fourteen AI employees is a folder: a personnel file, a rulebook in a file called CLAUDE.md, skills as text files for recurring tasks, an inbox for handoffs to colleagues. All Markdown, all local, in my case in an Obsidian vault. Claude Code reads the files at startup and works with them. How such a folder comes into being is in Creating an AI Employee: How to Start, what belongs in the rulebook file in CLAUDE.md: Claude Code's Memory.
Afterwards you run a folder and a subscription. Claude Code is included in all paid plans according to Anthropic. You switch the model with the /model command, within the Claude family. And now the part that tips it for me: your work lives in files you can read. If Claude goes down tomorrow, I open the same folder with Codex or with OpenCode and local models. The tools read the same files because the format is open: Codex reads a file called AGENTS.md according to its own docs, OpenCode reads AGENTS.md and CLAUDE.md, and Claude Code, according to Anthropic's docs, reads AGENTS.md as well since version 2.1.277 when no CLAUDE.md sits next to it. The runtime is Claude in my case; the description of the work belongs to me.
Frieda as a folder: a CLAUDE.md with task, rules, and limits, the pile rules as a file, a skill for the sorting run, and the sentence that carries everything: she never sends herself, she leaves drafts. The same principle carries the sharpest roles I have. Falk, my red teamer, only tests systems for which written authorization exists. That limit is in his personnel file, not in a node.
To be honest: this way has limits. It has no user management, it runs in the terminal or in the Claude app, and an employee needs a start from me, a schedule, or a call. It is not an assembly line. It is the right choice when you work alone or in a small team, your tasks need context and judgment instead of fixed branches, and you want the result of your onboarding work to belong to you. Why the file is what survives a tool switch is in CLAUDE.md vs AGENTS.md: What Survives.
How to build an AI employee: decision guide by business size
The rows don't exclude each other: at my place, n8n and Claude Code ran side by side for a while, Claude Code as trigger, n8n as execution.
Frequently asked questions
Can I build an AI agent myself without programming?
Yes, on five of the six ways. Course plus platform, workflow tool, platform for organizations, and employee on subscription run in the browser without code. The folder way needs no code either, you write rules in plain English; Claude Code runs in the terminal, though, and for many people that is the real hurdle. Only the framework requires programming.
Is an AI agent in n8n an AI employee?
Technically it is a node in a workflow that connects a model and tools. Whether you call it an employee is a matter of taste. For me the difference is whether its role, its rules, and its limits live in one place I can read and change like a personnel file. In n8n they sit in the prompt field of the Agent node.
Do I need a course to build an AI agent?
No. All six ways have public documentation, and the folder way needs less prior knowledge than most people assume: one task, one description of the role, one first conversation. A course helps if you want guidance and structure.
What is the difference between an AI agent and an AI employee?
An agent is a system that completes a task with a model and tools. An employee, in my setup, is an agent with a personnel file, fixed limits, and an approval rule, in other words with leadership. The whole ladder of terms from chat to assistant to employee is in Agentic AI Explained: What It Is and Isn't.
Can I switch ways later?
Between platforms you usually rebuild, because each keeps its agents in its own format. From the folder, switching the tool is easier, because the files are plain text and several tools read the same format.
Where to go from here
Take one task that needs context in your business and walk through the five questions for the way you currently have in mind. If the answer to question four is "in the interface", consider whether that will still make you happy in two years. And if you get stuck on question one: you are not alone with that. In the calls of my community we rebuild your Frieda in your tool, whether n8n, Langdock, or folder, and you see the difference yourself: Claude Practitioners.
