Blog · September 21, 2026 · 14 min read

Langdock vs Claude: What I Use and Why

Graphic title card for the article “Langdock vs Claude: What I Use and Why” with a stylised connected handover points.
Grafik: HumanITy

Langdock vs Claude is, for a solo business, not a question of which tool is better but of where your work lives. Langdock describes itself as a platform for adopting AI as an organization: one chat for everyone, agents for recurring tasks, workflows for automations, model choice by click across several providers, and hosting in the EU. All of it lives inside Langdock's interface, billed per user per month. At my place, an AI employee lives in a folder of text files I can read myself, and Claude runs it. I tried Langdock and stayed with the folder for my business. If you need to manage several users, mix models from different providers, or show an auditor certificates, Langdock is the right place. If you work alone or as a pair and want to keep your employees when you switch tools, the folder serves you better.

I run my AI agents as a workforce of fourteen employees, each one a folder with a personnel file, a rulebook, and skills, and I know the other direction not only from the docs: n8n ran in my own cluster for a long time, and I tried Langdock. This post is one of six approaches from Building an AI Employee: Six Ways Compared. As there, I use the same task: the inbox sorting done by my employee Frieda, once thought through as a Langdock agent, once the way it runs at my place.

What Langdock is, according to the docs

Langdock calls itself “The all-in one platform to adopt AI as an organization” on its homepage and splits into three building blocks: Chat (“Model agnostic, for everyone in the company”), Agents (“Custom AI for recurring tasks”) and Workflows (“Build powerful AI automations”). The documentation describes agents like this: “Agents are specialized chatbots you can configure for specific use cases or documents. They work like regular chat, but with saved context (documents and instructions) so you don't need to set up the same conversation repeatedly.” And when an agent makes sense: “Use an agent when users repeatedly need the same role, instructions, tools, or knowledge.”

Model choice is the point Langdock stresses most. According to the Model Guide, building “a tool which is model-agnostic” is a core value; in chat you pick the model “from the model selector in the chat input bar” and “can switch models mid-conversation”. A mode called Auto picks the model itself: “Auto analyzes your first message to understand the request and estimate its complexity, and then selects a suitable model for that conversation.” The providers named are OpenAI, Anthropic, Google, Mistral, Meta, and DeepSeek, so Claude models are included. On hosting the vendor states: “The application and most models (configurable) are hosted entirely in the EU” and “Customer data is never used to train or improve AI models”, plus ISO 27001 and SOC 2 Type II. These are vendor statements, not something I audited.

Workflows are the third layer, in the docs “your orchestration layer”: chained steps with conditions and loops, triggered “by a form submission, a schedule, or an event in your connected apps”. They have to be activated by an admin and consume AI credits.

Frieda as a Langdock agent, as a thought experiment

At my place Frieda sorts the inbox into four piles, Now, Today, Can wait, Trash, plus a fifth for everything that needs my judgment. For the Today pile she drafts replies and never sends anything herself. The method behind it, three questions and a few rule lines, is in Sorting Your Inbox: The Pile System; the employee is on Frieda, my office employee.

This is what Frieda would look like in Langdock if I built her there, step by step from the agent configuration in the docs:

  1. Instructions. The three questions, the five piles, and the rule lines go into the instructions field, up to 50,000 characters according to the docs: Frieda's rulebook in a text field instead of a file.
  2. Knowledge. I attach the sender list and the vetted routine notifications as files, “up to 50 files” per agent, or as a synced folder.
  3. Integrations. For Frieda to read the inbox and create drafts, the agent gets an integration; the docs name “Create email drafts” as an example action. Exactly that and nothing more.
  4. Model. “Choose which model this agent will use.” Here I would pick a Claude model; you could pick another and switch later without touching the instructions.
  5. Approval. Frieda never sends. In Langdock that means either an agent that may only create drafts, or a workflow with the Human in the Loop step: “Pause workflow execution and require manual approval before proceeding.” Anyone with editor access to the workflow can approve.
  6. Publishing and sharing. Changes are a draft first and reach others only after publishing; sharing happens inside the workspace with people or groups.

That is a clean way to build it, and for a department with twenty inboxes the last point is the most important one: a change to Frieda reaches everyone, versioned. For me alone, the same point is effort without benefit.

Frieda at my place: a folder

At my place Frieda is a folder. Inside is a CLAUDE.md with task, rules, limits, files, and approvals, the same content that would be spread across instructions and an approval step above, only as one readable file; what it looks like word for word is in CLAUDE.md: Claude Code's Memory. Next to it are skills describing recurring procedures, also Markdown, and a mailbox folder for handovers. Sorting runs through the official connectors for Gmail or Microsoft 365, and Frieda can technically only read and draft, not send. The folder is executed by Claude, in my case in Claude Code.

The difference from the Langdock version is not what Frieda can do but where she is. In Langdock she is a published configuration in the vendor's interface. At my place she is a folder on my machine that I can open with any editor, version with Git, and pass on as a zip. That is exactly how she also sits as a package in my community.

Langdock vs Claude: the five checkpoints

I ask the same five questions in every post of this series, without prices, because the way billing is built explains the decision better than an amount that changes.

Checkpoint Langdock (per docs) Folder plus Claude (at my place)
What you operate afterwards a workspace with users, agents, knowledge, integrations, and optionally workflows, all hosted by the vendor a folder of Markdown files on your machine, a Claude subscription, in my case Claude Code in the terminal
How it is billed per user per month; workflows as an add-on per workspace by runs; API usage-based one subscription for everything, Claude Code is included in the paid plans; the amounts are in Claude Pricing and Plans Explained
What happens when you switch models by click in the model selector, even mid-conversation, across six providers; agent, knowledge, and workflows stay in Langdock via /model within the Claude family; across vendors I switch the tool, the files stay
Where your work lives in instructions, knowledge, and workflows inside the interface, as a published version in files you can read without Langdock, without Claude, and without me
When it is the right choice several users, central administration, model mix across vendors, compliance evidence, no terminal wanted one to a few people, tasks that need context and judgment, employees that should belong to you

The third row needs an honest clarification. In Claude Code I switch the model via /model, but only between Claude models and Claude providers. Switching to GPT or Gemini is not provided for there. What I can do instead: switch the tool. Codex or OpenCode read the same Markdown files, and according to its docs Claude Code also reads an AGENTS.md, the format other coding agents use. Langdock has the more convenient model switch, I have the more portable files.

What I saw when I tried it, and why I stayed with the folder

I tried Langdock and stayed with the folder. That has less to do with Langdock than with three decisions I had already made for my business.

First, data sovereignty. Everything my employees know sits as files locally with me, in an Obsidian vault, not in a cloud chat. That is not a statement against EU hosting; it is the decision that my employees' personnel files are a folder I can back up, copy, and hand over without asking a vendor.

Second, the fallback plan. If Claude goes down or I want to switch for another reason, I go to Codex or to OpenCode with local models, and they work on the same files. On a platform, Frieda lives in the platform. The Langdock docs describe an API for retrieving agents and migrating them between workspaces; that is a route for developers, not a folder on your disk. At my place the file is the starting point, not the export target.

Third, who needs user management. I am a business with one human and fourteen AI employees, who introduce themselves in My AI Workforce and under /team. Roles, groups, version notices for users: an organization pays per user for that, and at my place nobody would use it. I think that is the most honest sentence in this comparison: Langdock solves problems I do not have.

What I share with Langdock is approval as a building block. At my place it is called the approval gate: whatever leaves the house or changes state waits for me. Falk, my employee for security testing, does not send a single request to a target system before my written approval is in place; what that looks like is on Falk, my red teamer. Langdock builds the same thing as a Human in the Loop step; at my place it sits in the personnel file instead of the workflow.

When Langdock is the right choice

There are four situations in which I would recommend Langdock over my folder.

  1. Several users, central administration. As soon as five or twenty people should use the same agent, you need roles, groups, versions, and an admin who activates workflows. A folder with a CLAUDE.md has none of that.
  2. Model mix across vendors. If you need an OpenAI model and a Claude model side by side in the same task, Langdock gives you that by click. I do not have that.
  3. Compliance evidence. If you have to show an auditor certificates and EU hosting, Langdock has paperwork for that according to the vendor. A folder on a laptop does not deliver that by itself; there you are responsible for backup, access, and evidence.
  4. No terminal. Langdock runs in the browser. Claude Code runs in the terminal; if you reject that, you need the Claude app or a platform. Getting started with my method also works in the app, but connecting the mailbox and files is the step after that at my place.

Frequently asked questions

Is Langdock GDPR compliant?

The vendor states that the application and most models are hosted entirely in the EU, that customer data is not used for training, and that ISO 27001 and SOC 2 Type II are in place. Whether your processing is GDPR compliant with that also depends on you: data processing agreement, purpose, what data you upload. This is not legal advice, just the note that a hosting location alone does not create compliance.

Langdock vs ChatGPT: what is the difference?

ChatGPT is one vendor's chat. Langdock is a platform in which an organization uses models from several vendors, including OpenAI and Anthropic, with administration, agents, and workflows. If you work alone and want to chat, you do not need a platform; whether a Claude or an OpenAI model is the better base for an agent is in Build an AI Agent: Claude vs ChatGPT.

Langdock vs n8n: which tool is for what?

Langdock is a workplace for people who work with AI: chat, agents, knowledge, permissions. n8n is a workflow tool in which processes run as nodes and connections, also without humans, triggered by a schedule or webhook. Both now also have the other side: Langdock has workflows, n8n has an agent node. What I built in n8n and learned from it is in n8n AI Agent: What I Learned Building One.

What is my Langdock review after trying it?

I tried it, I did not run it for months. What I saw matched the docs: a tool for organizations, with administration, model choice, and approval steps. For my business, one human and a workforce of folders, I found no reason to move the employees out of their files and into an interface. That is a decision for my case.

Can I switch models in Claude Code the way I can in Langdock?

Within the Claude family yes, via /model, even mid-session. To models from other vendors, no. For that I switch the tool: Codex or OpenCode read the same files, and according to its docs Claude Code also reads AGENTS.md. In Langdock the switch is a click; at my place it is a different program in the same folder.

Do I need programming skills for Langdock or for my approach?

For Langdock, per docs, no: agents are configured in form fields or by chatting with the Agent Builder. For my approach also no: the personnel file is plain text, and you start in the Claude app. What you learn is leadership: describe the task, write down the rules, put feedback into the file. If you do not want to do that alone, you do it with me and the people in the community, in the calls or in a post.

Where to go from here

If you work in an organization that is rolling out Langdock, use it and build Frieda there along the list above. If you work alone or as a pair, start with the folder: Creating an AI Employee: How to Start shows the process in five steps, and Frieda is ready as a finished package.

In the calls of my community we rebuild your Frieda in your tool, whether Langdock, n8n, or a folder, and you see the difference on your own task instead of my table: Claude Practitioners.

Kevin Welter

Kevin Welter

Developer, IT architect, author of technical books (Kubernetes, cloud infrastructures) and speaker. Runs his business with an AI workforce of fourteen AI employees and shows solo business owners in his community how to hire their first AI employee.

More about AI employees

Your first AI employee up and running within an hour

Join the community