Agent Skill vs Custom Agent: Which One Should You Build?

An agent skill packages a reusable workflow that an existing agent can invoke. A custom agent packages a dedicated worker: instructions, tools, knowledge, memory, routing, permissions, user experience, and sometimes its own runtime.

Build an agent skill when the procedure should travel across agents, teams, or workspaces. Build a custom agent when the operating environment itself needs to be specialized.

That distinction is easy to lose because modern platforms blur the language. OpenAI's GPT builder lets teams configure custom versions of ChatGPT with instructions, knowledge, capabilities, actions, conversation starters, and model choices in the GPT creation documentation. OpenAI's Agents SDK guide describes agents as applications that plan, call tools, collaborate across specialists, and maintain enough state for multi-step work. Anthropic and Microsoft describe skills differently: portable packages of instructions, scripts, and resources that agents load only when relevant (Anthropic Agent Skills, Microsoft Agent Skills).

The practical question: are you packaging a repeatable job, or building a new worker around that job?

A custom agent is broader than a workflow. It is a configured operating surface that decides who the agent is, what it can access, how it behaves across turns, what happens when work becomes risky, and where the result appears.

In a no-code or low-code setting, that might mean a custom GPT for onboarding new hires, a Microsoft Copilot Studio agent connected to SharePoint knowledge, or a website support agent grounded in product documentation. Microsoft Copilot Studio groups agent creation around topics, knowledge, tools, prompts, workflows, MCP servers, child agents, testing, analytics, channels, and handoff (Microsoft Copilot Studio docs). Its knowledge-source docs cover grounding through websites, documents, SharePoint, Dataverse, and connectors, while its tool docs cover tool calls and authentication context (Copilot Studio knowledge sources, tools for custom agents). That is a runtime and product surface, not just a reusable checklist.

In a code-first setting, a custom agent might be an OpenAI Agents SDK specialist with tools, handoffs, guardrails, tracing, sessions, and human review. The OpenAI SDK docs frame that path as appropriate when your server owns deployment, tools, state storage, and approvals. Google makes the same distinction at enterprise scale: the Gemini Enterprise Agent Platform includes Agent Studio, ADK, RAG Engine, Agent Runtime, Memory Bank, Agent Identity, Agent Gateway, evaluation, and observability in the Agent Platform overview.

A custom agent may define:

• identity, role, and tone
• system instructions and routing policy
• connected knowledge sources
• tool, action, connector, or MCP access
• memory and state policies
• handoffs to humans or other agents
• runtime permissions and approval gates
• UI, API, channel, or workflow endpoints
• analytics, tracing, evaluation, and deployment

That is useful when you need a specialized worker, but every runtime choice becomes part of the product: permissions, state, escalation, monitoring, versioning, and user expectations.

An agent skill is narrower. It packages a repeatable job so a host agent can perform that job with less ambiguity. If you need the category definition first, start with What Is an Agent Skill?. The short version is that a skill is reusable operating procedure, not a whole agent identity.

Anthropic's skill docs describe skills as filesystem-based resources that provide domain-specific workflows, context, and best practices. The same page explains progressive disclosure: metadata is available up front, the main instructions load when relevant, and deeper resources or scripts load only when needed. Microsoft uses a similar structure: a skill directory contains SKILL.md plus optional scripts/, references/, and assets/ directories. OpenAI's Codex skills documentation follows the same practical pattern for reusable workflows.

A skill usually defines:

• the repeatable job
• when the skill should be used
• required inputs and trusted sources
• fastest path to evidence
• steps, examples, and templates
• scripts or reference files when useful
• completion evidence
• boundaries, stop rules, and escalation rules

The skill does not need to own the full agent runtime. It can be installed into Codex, Claude, a company agent workbench, or a custom support agent. It tells the agent how to run a job; it does not decide the whole operating environment.

That is why Agent Skill vs Tool is a related but different comparison. A tool gives the agent capability. A custom agent assembles capabilities into a worker. A skill tells a capable worker how to complete a job reliably.

OpenAI custom GPTs are a good example of custom agents for non-developers. A team might build a "Sales Proposal GPT" with branded instructions, approved case studies as knowledge, web search enabled, and an action that creates a CRM draft. That custom GPT is the agent surface. Inside it, a proposal-review skill could still define the repeatable procedure: check buyer persona, quote the source notes, match proof to industry, flag unsupported ROI claims, and return a final approval table.

OpenAI's Agents SDK shows the code-first version of the same idea. A support refund agent might have a triage specialist, a policy specialist, a payment-system tool, guardrails, tracing, sessions, and a human approval pause before refund execution. That is a custom agent because the server owns tool routing, state, and approval decisions. A refund-policy skill inside that agent would be narrower: inspect order status, classify reason, apply the policy hierarchy, cite evidence, and stop if the case requires supervisor review.

Microsoft Copilot Studio is another custom-agent surface. A company might create an HR policy agent for Teams that uses SharePoint knowledge, topics, connectors, and handoff to HR. A vacation-policy skill could still be reusable across that Copilot, an internal Claude workspace, and a Codex environment that updates policy docs. The skill is the policy workflow. The Copilot is the employee-facing agent.

Google's Agent Platform pushes the distinction into enterprise architecture. Agent Studio, ADK, Agent Runtime, Memory Bank, Agent Identity, Agent Gateway, and observability are machinery for building and governing agents. A data-quality skill might define freshness checks, grain validation, denominator review, anomaly comparison, and final evidence. The custom Google ADK agent would own BigQuery access, identity, memory, traces, and deployment.

Start with the narrow workflow. A product feedback skill can tell any capable agent how to turn customer comments, support tickets, or sales-call notes into issue candidates:

• read the feedback source
• group duplicates
• classify product area
• quote evidence
• assign severity
• produce a triage table
• stop if the source lacks enough detail

That should be a skill if the same workflow is useful in Codex, Claude, an internal chat agent, or a support operations tool. Skillfully's How to Write an Agent Skill That Actually Works goes deeper on this kind of contract: define the job, name the inputs, require evidence, and make the output reviewable.

Build a custom agent only when the environment itself becomes special:

• it continuously watches support channels
• it maintains memory about known customer accounts
• it has privileged access to CRM and issue trackers
• it routes urgent issues to humans
• it exposes a dedicated dashboard
• it posts approved issues back into Jira, Linear, or GitHub

At that point, you are building an agent product. The skill can still exist inside it as the triage procedure, but the custom agent owns the channel, permissions, memory, monitoring, and user experience.

Community examples show the same boundary. In r/OpenAI, builders treat custom GPTs as combinations of instructions, knowledge files, and API actions, while others complain about instruction-following and try moving operational rules into uploaded files (custom GPT discussion, instruction-following thread). A newer r/ArtificialInteligence thread asks how to choose among an agentic workflow, Custom GPT, skill, or prompt (workflow vs GPT vs skill thread). In r/ClaudeAI, a user describes a custom skill with separate modes and templates inside a longer project (Claude skill example). The practical split is consistent: custom agents gather environment and access; skills encode repeatable procedure.

Choose a skill when:

• the job can be described in one sentence
• multiple agents or teams could reuse the workflow
• the task needs examples, references, or scripts
• the host environment already has the tools it needs
• the main improvement loop is about output quality
• failures come from skipped steps, weak examples, or ambiguous completion criteria
• you want to compare versions of the workflow after real use

Choose a custom agent when:

• the agent needs a dedicated identity or role
• tool access and permissions are unique
• the agent must keep task-specific memory
• the workflow is always on or event-driven
• there are multiple skills, tools, and routing paths under one product surface
• the user experience, channel, or deployment is part of the value
• you need centralized observability, evals, approvals, or governance

The fastest test is to name the failure mode. If the agent cannot access a system, you probably need a tool or connector. If the agent has access but keeps doing the job inconsistently, you probably need a skill. If the work needs a dedicated identity, channel, memory policy, approval path, or always-on loop, you probably need a custom agent.

Most teams should start with a skill unless they already know they need agent-level infrastructure. A skill forces the author to answer questions a custom agent can hide: what is the exact job, which inputs are trusted, what should be inspected first, what counts as completion evidence, and when should the agent stop or escalate?

Those questions are cheap to answer in a skill file and expensive to discover after a custom agent has users, credentials, analytics, and support expectations. If a code-review assistant misses migration rules, do not start by building a new agent. First write a migration-review skill that points to the migration guide, constrains file search, requires line-specific findings, and defines blockers. If the skill succeeds across several runs, then decide whether it deserves a dedicated agent.

This also gives you a cleaner testing path. How to Test an Agent Skill Before You Publish It argues for checking the workflow before treating it as production behavior. That same idea applies here: validate the procedure before you build a product surface around it.

A custom agent is justified when the environment does real work that a portable skill cannot own. An internal finance agent may authenticate employees, read expense systems, maintain case state, route exceptions, and log audit decisions. A website support agent may own rate limits, session continuity, contact capture, CRM handoff, and brand tone. A software maintenance agent may own repository checkout, sandboxing, CI, pull-request creation, secret handling, and rollback policy. In each case, the repeatable procedure can still be a skill; the operating surface is the custom agent.

The custom agent is worth it when the value depends on the channel, permissions, memory, or automated handoff.

Do not treat this as an either-or decision forever. Strong systems often have both:

1. A custom agent owns the runtime, permissions, memory, and deployment.
2. Skills inside that agent own repeatable workflows.
3. Tools or MCP servers provide capabilities.
4. Evals and feedback loops measure whether each workflow improves.

That layering lets a team improve one part without rewriting everything.

For a practical stack, imagine a customer-success agent. The agent owns Slack, Gmail, CRM access, account memory, escalation policy, and reporting. Renewal-risk, support-escalation, and meeting-prep skills define the repeatable jobs inside that environment. Tools read systems of record, while approvals control external messages and account changes.

The first mistake is building a custom agent because one workflow is underspecified. If the agent keeps failing code review, documentation migration, or customer triage, the first fix is often a better skill, not a new agent runtime.

Ask this before starting a custom agent project:

If yes, write the skill first. It is cheaper to test, easier to share, and less likely to create platform maintenance work.

The second mistake is making one giant agent for a whole department. "Legal agent," "finance agent," or "engineering agent" sounds useful until every request needs different sources, permissions, output formats, and review standards. One governed agent surface with multiple narrow skills is usually easier to operate.

The third mistake is putting secrets, permissions, or business-critical side effects into the skill layer. A skill can say when approval is required, but it should not be the only thing preventing an email, refund, deployment, or data mutation. Put permissions in tools and runtime controls; put judgment and procedure in skills.

The fourth mistake is assuming uploaded knowledge is the same as a workflow. Knowledge gives the agent source material. It does not define what to inspect first, what to do when sources conflict, what output shape to produce, or when to stop. Treat knowledge as context, not as a substitute for a skill.

An agent skill is the portable procedure. A custom agent is the specialized worker.

Choose a skill when the work repeats and the host agent already has enough access to do it. Choose a custom agent when identity, memory, tools, approvals, channels, or deployment are part of the solution. In mature systems, use both: custom agents provide the operating environment, while skills provide reusable task expertise that can be tested, shared, and improved over time.

Build the smallest unit that solves the actual failure. If the problem is inconsistent procedure, write the skill. If the problem is a missing worker with its own access, memory, and operating surface, build the custom agent.