A practical guide for deciding whether you are building a skill or an agent.
A skill is a bounded capability that follows a known pattern, even if it is complex and touches many systems.
An agent is a goal-directed system that decides what to do next based on context, uncertainty, or changing conditions.
The main boundary is not complexity. The main boundary is control of the workflow.
- If the workflow is mostly known in advance, you are probably building a skill.
- If the system must choose or adapt the workflow at runtime, you are probably building an agent.
People often assume that:
- simple = skill
- complex = agent
That is the wrong mental model.
A thing can be extremely complex and still be a skill if it remains bounded, repeatable, and structurally predictable.
Likewise, a thing can be fairly small and still be an agent if it is responsible for deciding strategy, sequencing, or next actions dynamically.
The real question is:
Is this system mainly executing a defined capability, or is it deciding how to pursue a goal?
A skill is a focused, bounded capability that performs a defined job.
A skill may:
- take inputs
- gather data
- transform information
- call APIs
- read files
- invoke other skills
- produce structured output
But it is still a skill if its overall role is to perform a known function within a known boundary.
A skill is usually:
-
Bounded
It has a clear purpose and scope. -
Predictable in structure
The exact output may vary, but the general workflow is known ahead of time. -
Execution-oriented
It is primarily doing work, not deciding broader strategy. -
Reusable
It can be called as a component inside a larger system. -
Narrow in responsibility
Even if it touches multiple systems, it is still serving one well-defined purpose.
A skill does not have to be trivial.
A skill can:
- traverse linked documents
- collect screenshots
- consolidate comments from multiple systems
- normalize messy inputs
- validate outputs
- perform several substeps internally
That still does not make it an agent.
An agent is a system responsible for pursuing a goal by deciding what actions to take, in what order, based on context.
An agent may:
- choose which skill to call
- decide whether more information is needed
- change plans based on new findings
- reprioritize work
- loop until a goal is satisfied
- escalate, stop, retry, or branch based on judgment
An agent is usually:
-
Goal-directed
It is trying to achieve an outcome, not just perform one capability. -
Adaptive
It changes behavior depending on what it encounters. -
Decision-oriented
It owns at least some of the logic for what should happen next. -
Orchestrative
It may coordinate multiple skills, tools, or even other agents. -
Open-ended in workflow
The path is not fully known in advance.
The boundary is best understood like this:
“How do I perform this specific task?”
“Given this goal and this context, what should I do next?”
That is the real divide.
Not size.
Not code length.
Not number of API calls.
Not whether it feels sophisticated.
The deciding factor is who owns the decision-making about the workflow.
This is a useful lens, but it must be used carefully.
A skill usually follows a known operational pattern:
- parse the input
- fetch the data
- transform the data
- return the result
Even if the contents vary, the shape of execution is mostly fixed.
An agent typically has to decide:
- whether to gather more information
- which capability to invoke next
- whether the current result is sufficient
- whether to retry, change direction, or escalate
Its path is more open-ended because it is choosing among alternatives at runtime.
Not every tiny choice makes something an agent.
A skill can still contain local decision logic such as:
- choosing one parser over another
- selecting a CSS rule pattern
- handling fallback data sources
- branching on expected edge cases
That does not make it an agent.
Local bounded choices inside a fixed-purpose workflow are still normal skill behavior.
The system becomes agent-like when it owns meaningful control over the broader plan.
Use this test when deciding whether something is a skill or an agent.
- you can describe its job in one clear sentence
- the workflow is mostly known ahead of time
- it exists to perform a capability, not pursue a broad goal
- any branching is tightly bounded and task-specific
- you would comfortably expose it as a reusable function/tool/module
- it must decide what tasks are needed to reach the goal
- the order of operations depends heavily on context
- it may loop, replan, or change strategy dynamically
- success depends on judgment, not just execution
- it acts more like a coordinator than a single capability
Input text goes in, translated text comes out.
This is a classic bounded capability.
It transforms CSS into a compressed form using a known process.
No real strategic planning is involved.
It takes an image and produces a resized version according to rules or settings.
Clear job, clear boundary.
It reads a file, identifies headings/tables/images, and returns normalized structured content.
This can be sophisticated, but it is still a bounded task.
This is a strong example of a complex skill that is still a skill.
It may:
- accept one or more ticket IDs
- fetch titles, descriptions, comments, and metadata
- follow linked documents and references
- pull in screenshots or supporting artifacts
- extract and consolidate context across multiple sources
- normalize and merge everything into a single intake artifact
That is a lot of work. But it is still a skill because its mission is stable:
gather and consolidate all relevant ticket-related context into one structured output
It is not deciding which business problem matters most.
It is not determining what work should be executed first.
It is not dynamically inventing a strategy for delivery.
It is performing a bounded intake function.
That is exactly the kind of example people need, because it shows that complexity does not automatically imply agency.
Your ticket-intake skill is a skill because:
-
Its purpose is singular
Intake and consolidation. -
Its workflow is structurally known
Even if different tickets contain different data, the job is still to harvest, follow references, collect artifacts, and synthesize the result. -
Its branching is bounded
It may branch to follow links, fetch comments, or read referenced documents, but all of that branching serves the same predefined intake process. -
It does not own delivery strategy
It prepares context for later planning and execution; it does not decide the larger course of action. -
It is a reusable capability
Another system, human, skill, or agent can call it whenever consolidated ticket context is needed.
So yes: a skill can be deep, multi-step, cross-system, and expensive, and still remain a skill.
Your ticket-intake system would start crossing into agent territory if it began doing things like:
- deciding which tickets are worth processing first
- determining whether a ticket should be rejected, escalated, split, or merged
- deciding whether engineering, product, design, or support should own the work
- planning execution steps after intake
- iteratively gathering more information until some higher-level success condition is met
- choosing between multiple competing next actions based on judgment
At that point, it would no longer be “just intake.”
It would be taking ownership of broader decision-making.
That is the shift from capability execution to goal-directed orchestration.
It receives an issue and decides:
- whether the issue is product, billing, or technical
- whether more information is needed
- whether to answer directly or escalate
- which downstream capability to invoke
That is agent behavior because it owns the decision flow.
It receives a goal like “implement this feature” and decides:
- what information must be gathered
- what subtasks exist
- what dependencies matter
- what sequence of work makes sense
That is not a single capability. That is orchestration.
It analyzes a failing CI run and decides:
- whether the issue is lint, test, build, or environment
- what evidence to gather
- which fix strategy to try first
- whether to retry or stop
That is agent behavior because it navigates uncertainty.
It evaluates budget, preferences, and tradeoffs, then chooses what to recommend.
It is not simply retrieving products; it is deciding among alternatives.
It monitors goals, conditions, and changes over time, then adjusts actions accordingly.
That is inherently strategy-driven.
When you are about to build something, ask these questions.
- the responsibility is clear and bounded
- the workflow can be mostly specified in advance
- the system is meant to be a reusable building block
- branching stays inside a narrow task boundary
- the value comes from reliable execution of a capability
- the responsibility is achieving a broader goal
- the system must choose among multiple possible next steps
- the workflow cannot be fully known in advance
- context materially changes the plan
- the value comes from judgment, prioritization, or orchestration
If the thing you are building can be described as:
“This system knows how to do X.”
it is probably a skill.
If it is better described as:
“This system figures out how to achieve Y.”
it is probably an agent.
That distinction is clean, useful, and holds up well in practice.
A skill is not a lesser version of an agent.
It is not “an agent, but smaller.”
A skill is a bounded capability.
An agent is a goal-seeking orchestrator.
A complex skill is still a skill if it remains within a known mission and known workflow boundary.
Your ticket-intake example is a perfect illustration of that principle:
- it is sophisticated
- it is multi-step
- it spans systems
- it may gather a large amount of context
- and it is still a skill, because it does not own the broader plan
That is the boundary people should remember.