Since July, Langdock builds an agent for you on request. You describe in chat what it should do, and the Agent Builder asks follow-up questions, suggests suitable knowledge sources and integrations, and configures along with you live while you watch. Building one now costs roughly a sentence.

That is exactly why the same question comes up in almost every office hour: When is a Skill enough, and when do you need an Agent? We covered both building blocks separately in this series before, subagents in March and Skills in April. This month is about the choice between them, so that next time you can make it without us.

If you remember only one question, remember this one: does someone have to go somewhere for it to work? If something should apply everywhere you are already working, build a Skill. If it should happen in a specific place that people visit, build an Agent.

This difference is baked into how they are built. An Agent has its own address, you can link to it, embed it in Slack or Teams, and even open it up to people outside your company through a public link. Skills have none of that, they cannot be called anywhere. You can only carry them with you.

Everything else follows from that one question. Only a place can be controlled, which is why a fixed model, a forced input, a tested version, and usage numbers only exist for an Agent.

A Skill is an instruction with a trigger condition. You write down once how something should be done, and Langdock applies the rule as soon as it fits the conversation.

The critical point sits in that "as soon as". With every message, the model reads the descriptions of all active Skills and decides whether one of them fits your request. You do not call anything up and you do not type an @, the matching Skill just kicks in. That is exactly what "coming along" means: it is not waiting for you anywhere, it is already there.

Word the description the way you would explain to a new colleague when to reach for this instruction. That is also where most Skills fail.

Two properties that make Skills strong

• They stackIn a single conversation, the first message can pull one Skill and the third message the next, without you switching anywhere. Up to 30 active Skills are available at the same time.
• They grow with your workYou solve a case in chat, then have a Skill built out of it, and next time it kicks in on its own. If you notice something later, you sharpen the same Skill so the time after runs even better.

An Agent is its own workspace that you visit. Because it has a fixed place, it can decide what happens there, and that is where its whole equipment comes from:

• Its own knowledgeUp to 50 files, five folders from the library, and five synchronized folders that someone keeps current.
• A fixed instructionUp to 50,000 characters that apply to everyone who talks to it.
• Structured inputsForm fields with required entries make sure a case arrives complete before the model even starts.
• A fixed modelThe owner picks it, and no one can switch it in conversation.
• A publishing cycleChanges land in a draft that only you see and go live for everyone only with a deliberate click.
• Tests before publishingUp to 50 test cases per test set, evaluated by a model acting as reviewer, by checking which tools got called, or by required and forbidden phrasings.
• Numbers and feedbackActive users, most-used actions, cost per message, plus thumbs and comments right from chat.

This rigidity is what makes an Agent reliable across many people, because everyone works with the same instruction, the same knowledge, and the same version. It stays flexible where it matters: every version is kept, and you can return to an earlier one at any time.

If the "going there" question does not yet give you a clear answer, these four help.

1. Does the thing permanently need its own knowledge?

   As soon as a good answer would be worthless without a manual, a price list, or system access, you are talking about an Agent.

2. Does it need to apply to everyone, including those who do not want it?

   Expectations flip here. Only a Skill can be made mandatory, and it can be made mandatory across the whole workspace, with no one able to switch it off. Using an Agent, on the other hand, is always voluntary. A rule no one has to go somewhere for can just apply everywhere.

3. Does quality have to be measurable?

   Tests before publishing, versions with rollback, and usage numbers only exist for the Agent. As soon as a mistake can hurt someone outside your team, you need that apparatus.

4. How often does the thing change?

   A Skill takes effect immediately, which is a plus when you sharpen it weekly. An Agent only goes live when you publish, which protects you with many users and slows down quick experimentation.

A case where the line moves

To make this concrete, we follow a single use case at the fictional Quellberg GmbH across three stages.

Stage one: the Skill for your own work

Anna in sales writes several offers a week. She has a routine that works: she summarizes the request, matches the right service packages, writes a short justification for each item, and closes with the terms.

After her third offer, she asks Langdock in the same chat to build a Skill out of it. She describes it as "Use this Skill when a customer request needs to turn into an offer draft". Next time, it kicks in on its own without her looking for it. Two weeks later she notices the justifications are getting too long. She sharpens the instruction in the same Skill, and from the next offer onward the length is right.

Stage two: the tipping point

Then two colleagues ask if they can have this too. Anna shares the Skill, and at first it works well. Four weeks in, though, three observations surface: the colleagues feed the Skill a different slice of the request every time, so the drafts come out with different levels of completeness. Both keep asking Anna for the current price list, which the Skill itself does not know. And no one can say whether the drafts actually work for sales, because there is no feedback for it.

Stage three: the Agent for the team

Anna builds an Agent out of it, and the Skill moves in as a component because Skills can be attached to Agents. The Agent adds four things the Skill was missing: it asks for what it needs through form fields, meaning customer, occasion, requested services as multi-select, volume, and deadline. It has the price list and the reference texts as its own knowledge, curated in one place. Anna tests every change against fifteen real requests from the last quarter before publishing. And she can see in the numbers who is using the Agent and what feedback is coming in.

More ideas for sorting

• Skill for the whole workspace: your brand voiceA rule for salutation, tone, and sign-off that applies wherever anyone communicates externally, from the customer email to the offer to the LinkedIn post.
• Skill: the format of your meeting notesAlways attendees, decisions, and open items, regardless of who is taking the minutes.
• Skill, mandatory for everyone: the compliance note for legal topicsThis is exactly what the option to set a Skill workspace-wide and mandatory is for.
• Agent: information from the employee handbookQuestions about leave, parental leave, and travel expenses answered from a curated source instead of from memory.
• Agent: the intake for procurement requestsForm fields collect the essentials, the stored ruleset decides the next step.
• Agent for external use: the application assistantExternal Agents run through a public link, and the people on the other end do not need a license.

Let us clear up a mix-up right away, because it is what causes the question in the first place.

Wanting to roll something out does not yet tell you which building block you need. The question stays the same: does someone have to go somewhere, or should it just apply everywhere?

Three more pitfalls

• Skills compete with each otherBecause the model weighs all active descriptions against each other with every message, the selection gets fuzzier the more of them are running. The limit of 30 active Skills is rarely the real problem; the sharpness of the descriptions is.
• An Agent standardizes only as far as it is usedBecause no one can be ordered to use it, your process is exactly as consistent as the number of people who actually open it. That is exactly what the analytics view is for that shows how many of them went from having access to using it regularly.
• For hard procedures, the Workflow is the sharper toolAn Agent standardizes behavior inside a conversation where a model decides what happens next. A Workflow defines the procedure itself, step by step. When you have fixed stages with approvals, reach for the Workflow.

The reason is practical: a Skill costs you five minutes and improves in the work itself, while an Agent brings owner, knowledge curation, tests, and analytics, meaning ongoing responsibility. Anyone who sets up that apparatus before the use case is stable ends up maintaining something nobody has really understood yet.

Wait for the three signals from our example. As soon as inputs come in incomplete, you keep supplying the same source, and someone wants proof that it actually helps, the moment for the Agent has arrived. The Skill then moves in as a component, so nothing of your groundwork is lost.

And clean up once a quarter. A workspace with forty Agents, thirty of which nobody opens anymore, costs more trust than the ten good ones bring in.