Agent Skill vs Workflow: What Is the Difference?

An agent skill is a packaged procedure that teaches an agent how to perform one repeatable job. A workflow is the broader sequence of steps, systems, states, people, approvals, and automations that produces an outcome.

Put simply: a skill can live inside a workflow, but a workflow is not automatically a skill.

That distinction matters because the words are starting to collide. OpenAI describes Codex skills as packages of instructions, resources, and optional scripts that help Codex follow a workflow reliably (OpenAI Codex skills). Anthropic describes skills as folder-based procedural knowledge for agents, with SKILL.md, metadata, scripts, and resources loaded through progressive disclosure (Anthropic engineering). Workflow platforms and orchestration frameworks use workflow language for something larger: tool calls, state, integrations, approvals, and handoffs.

The clean mental model is this: the workflow is the operating system for a process; the skill is one reusable operating procedure the agent can run inside it.

Dimension	Agent skill	Workflow
Unit	Reusable agent procedure	End-to-end process
Owner	Skill author or enablement team	Team, function, or business process owner
Scope	One repeatable job	Many jobs, handoffs, and states
Format	Instructions plus optional scripts, references, and assets	Docs, automations, tools, queues, approvals, people
Trigger	User request, agent selection, or task context	Business event, schedule, ticket, webhook, deploy, incident
Success proof	Task-level completion evidence	Process-level outcome
Best metric	Did the agent do the job correctly?	Did the process reach the intended state?
Failure mode	Vague procedure, missing inputs, weak stop rules	Broken integration, bad routing, missing owner, unclear approval

For example, "prepare a release readiness summary" can be a skill. "Ship a product release" is a workflow. The release workflow might include planning, code freeze, QA, docs, deployment, monitoring, support training, and customer communication. Several skills can help inside it, but none of them should pretend to own the whole release process.

If you are still defining the category, start with What Is an Agent Skill?. If you already know the job is repeatable and need to package it, read How to Write an Agent Skill That Actually Works.

People confuse skills and workflows because agent platforms increasingly combine both.

In Codex or Claude, a skill can contain instructions, scripts, and references. Anthropic's agent architecture guidance draws a useful line: workflows orchestrate LLMs and tools through predefined code paths, while agents dynamically direct their own process and tool use (Building effective agents). LangChain's LangGraph docs use a similar distinction: workflows have predetermined paths, while agents define their own tool usage (LangGraph workflows and agents).

In n8n, the AI Agent node can decide which connected tool or API to use inside a visual workflow, but it still sits inside a workflow graph with triggers, nodes, credentials, and outputs (n8n AI Agent node). Zapier Agents shows the same blend: specialized agents can connect company knowledge to work across thousands of apps (Zapier Agents).

Those products are not wrong. They are describing different layers of the same stack.

• Workflow automation answers: what happens when this business event occurs?
• Agent orchestration answers: how should model calls, tools, memory, state, and approvals coordinate?
• Agent skills answer: what reusable procedure should the agent follow for this specific job?

A support refund process is a workflow. It may start when a customer opens a ticket, check order status in Shopify, route exceptions to a support lead, update Stripe, send an email, and log a note in the CRM. A "refund eligibility review" skill is narrower. It tells the agent how to inspect the policy, order history, customer message, fraud flags, and refund thresholds, then return an approval recommendation with evidence.

The workflow owns process state. The skill owns agent procedure.

Turn part of a workflow into a skill when the same judgment-heavy task repeats with similar inputs and the agent needs a known way to do it.

Good skill candidates have five traits:

• the job can be named in one sentence
• the required inputs are knowable
• the agent has a clear first place to inspect
• success can be checked at the task level
• failures produce useful feedback for the next version

Do not turn the whole business process into one giant skill. A "run enterprise onboarding" skill is too broad to test or trust. A "turn a kickoff transcript into onboarding risks and next actions" skill is easier to run and improve.

This is the same lesson in a different form as agent skills vs prompts: the artifact is useful when it becomes reusable procedure, not when it becomes a longer instruction blob.

A release documentation workflow might include:

1. read the merged pull requests for the release
2. compare changed APIs against current docs
3. identify breaking changes and deprecations
4. draft migration notes
5. update examples
6. run the sample app or docs checks
7. publish with owner approval

Possible skills:

Workflow step	Skill
Source review	Release-diff summary skill
Migration note	Breaking-change documentation skill
Example update	SDK example verification skill
Review	Docs accuracy review skill
Publish	Release docs checklist skill

This separation matters because each skill has different inputs and evidence. A release-diff skill should return changed APIs and source links. An example-verification skill should return commands run and failures found. A publishing skill should return approval state and final URLs.

If you tried to make one "release documentation workflow skill" that does all of this, it would have to read code, decide product significance, draft docs, run examples, manage approvals, and publish. That is usually the wrong unit. The workflow can sequence those jobs. The skills should make each repeatable job sharper.

The difference is even clearer in agent orchestration.

LangGraph is built for long-running, stateful agent systems. Its docs frame the human-in-the-loop pattern around pausing before actions like sending an email, deleting a record, executing a financial transaction, or performing another irreversible action (LangGraph human-in-the-loop).

In that kind of system, a workflow might look like this:

1. research a target account
2. draft a personalized email
3. pause for sales rep approval
4. send the email
5. log the activity in the CRM
6. schedule a follow-up task

The workflow needs state, retries, approvals, and integration behavior. A skill inside it might handle only one part: "turn account notes, website evidence, and recent hiring signals into a first-touch email draft with cited reasons." That skill should not decide when the CRM task is due or whether the rep has approved the send.

This is the practical line between "agent skill" and "agent workflow." The skill improves one agent-performed job. The workflow decides what happens before and after it.

A workflow diagram can describe steps without making them executable by an agent. A skill needs operational detail:

• what to inspect first
• what inputs are required
• what tools or files are safe to use
• what output shape is expected
• when to stop or escalate
• how to prove completion

Anthropic's engineering post compares skills to onboarding guides for agents because they capture procedural knowledge in a reusable form. That is a useful distinction. A workflow diagram shows the route. A skill teaches the agent how to drive one leg of it.

That is also why community skepticism is useful. In one Reddit discussion about Anthropic Agent Skills, a developer asked whether skills are "just conditional context loading" plus a standard folder structure (Reddit discussion). That criticism is fair at the mechanics layer. A skill may be "just" instructions and files. The value is standardizing reusable procedure so an agent can discover it, load it only when relevant, and follow it consistently.

The same skepticism shows up around Codex skills. In a Codex subreddit thread, the announcement was summarized as reusable bundles of instructions, scripts, and resources, while commenters pushed on whether templates add enough value (Reddit Codex thread). That is the right bar. A weak skill is just a file. A strong skill is a tested operating procedure.

It helps to separate three terms that often get blended together.

Term	What it coordinates	Good example	What not to expect
Automation workflow	Apps, triggers, records, scheduled steps	A Zapier automation that creates a CRM lead from a form, enriches it, and notifies Slack	Deep judgment unless an AI step or human review is added
Agent orchestration workflow	Model calls, tools, state, memory, approvals	A LangGraph flow that researches, drafts, pauses for approval, and resumes after review	Reusable procedural quality by itself
Agent skill	Agent instructions, references, scripts, examples	A skill that reviews release notes against changed APIs and returns evidence	Owning the whole business process

n8n and Zapier are strongest when the process has recognizable inputs and external systems. LangGraph is strongest when agent state, approvals, and runtime control matter. Skills are strongest when a repeatable piece of agent work needs better instructions than a prompt.

For example, a marketing operations team might use Zapier to move a demo request from Typeform to HubSpot, Slack, and a calendar queue. That is workflow automation. The team might use an agent step to research the company and draft an account brief. That step could use a skill that says which sources to inspect, how to separate facts from guesses, and what evidence to return.

Use a skill when:

• the job is bounded enough to finish in one run
• the agent needs reusable procedural guidance
• the result can be inspected by another person
• the same task appears across multiple workflows or teams
• you want feedback on how the procedure performs in real use

Use a broader workflow when:

• multiple systems need to coordinate
• state must persist across time
• approvals, retries, or routing decisions matter
• the process includes several distinct jobs
• the business outcome matters more than one task result

Use both when the process has deterministic rails but one or more steps require judgment. That is the most common useful pattern: the workflow handles triggers, routing, state, and system updates; the skill handles a specific agent job that benefits from expert procedure.

The wrong abstraction creates predictable problems.

If you force a workflow into one giant skill, you get scope creep. The skill asks for too many inputs, touches too many systems, and becomes hard to evaluate. A failure could mean the instructions were unclear, the source data was missing, an integration broke, an approval was skipped, or the business policy was wrong.

If you force a skill into a workflow node with no reusable procedure, you get brittle automation. Every workflow builder has to rediscover the same instructions, edge cases, and stop rules. The procedure stays hidden in a prompt field instead of becoming a maintainable asset.

If you skip the workflow layer entirely, the skill may produce a useful artifact that never reaches the process. A good account brief is not enough if it is not attached to the CRM record, routed to the rep, reviewed before outreach, and measured after the campaign.

The better design is usually layered:

1. Put deterministic routing, integrations, scheduling, and approvals in the workflow.
2. Put model/tool coordination and durable state in orchestration when the agent run is long-lived or sensitive.
3. Put repeatable expert procedure in skills.
4. Measure each layer separately.

Ask these questions before deciding what to build:

Question	If yes, lean toward
Does the same agent task repeat across contexts?	Skill
Does the process need triggers, retries, routing, or approvals?	Workflow
Does the agent need to pause and resume with state?	Orchestration workflow
Does the procedure need scripts, examples, or references?	Skill
Does the business process span several teams or systems?	Workflow
Can the output be judged at the task level?	Skill
Is the main risk a wrong external action?	Workflow with human approval

The release documentation example leans toward several skills inside one workflow. The refund example leans toward a workflow with a policy-review skill and a human approval gate. The account research example leans toward an automation workflow that calls a research-and-drafting skill before creating CRM artifacts.

Skillfully is most useful at the skill layer because skills can be measured from real runs. A workflow may be too broad to diagnose as one object. A skill can produce feedback: did it trigger correctly, follow the procedure, return useful evidence, or fail at a known step?

That makes agent skills a practical unit for improvement. Workflows still matter, but skills give teams something concrete to publish, run, observe, and revise.

For skill authors, this is the key product question: what reusable procedure deserves feedback? Not every automation deserves a skill, and not every skill deserves a complex workflow. But if bad execution of a repeated agent task hurts the business, it probably deserves to be packaged and observed.

That is why How to Write an Agent Skill That Actually Works pushes authors toward a clear contract: required inputs, truth path, completion evidence, stop rules, and feedback. A workflow dashboard might tell you that a process stalled. Skill feedback can tell you whether the agent used the wrong source, skipped a check, misunderstood the output shape, or needed a better escalation rule.

An agent skill is not a replacement for workflow automation. It is not a LangGraph graph, an n8n canvas, or a Zapier automation. It is the reusable procedure an agent follows when one part of the work requires judgment, context, and evidence.

Use workflows to coordinate the process. Use orchestration when agent state, approvals, and durable execution matter. Use skills to make the agent's repeatable work reliable enough to run, inspect, share, and improve.

The workflow is the whole chain. The skill is the repeatable unit inside the chain. Good teams need both.