Agent Architecture

Skill or Agent: Choosing the Right AI Abstraction

A practical decision guide for when to package repeatable expertise as a skill and when to build an agent that plans, uses tools, and owns a workflow.

TLDR

Skills and agents are not competing choices — they operate at different abstraction levels. Skills are composable, discoverable, versionable procedures that tell an agent how to perform a class of work. Agents are goal-directed runtimes that consume skills to navigate uncertainty across multiple steps. By mid-2026, skill engineering has emerged as a recognized third layer of AI engineering (above agent and infrastructure engineering), as named by The Turing Post. The four formal properties of a skill: composable (combines with other skills at runtime), discoverable (agents find and select dynamically), versionable (lifecycle-managed independently from the agent), and reusable (one definition works across many agents and contexts). The critical insight from the research: the policy problem — when to activate a skill inside the agent's decision loop — is architecturally separate from the skill definition. MCP is becoming the distribution layer: skills are shifting from hardcoded prompt files to protocol-native artifacts discoverable over HTTP. The unresolved security concern: a skill loaded from an external source runs inside the agent's context window and carries the same supply-chain attack risk as an npm package.

The common mistake is treating "skill" and "agent" as competing product names. They are different abstraction levels. A skill packages procedural knowledge: instructions, examples, scripts, templates, reference files, and constraints that a model can load when needed. An agent is a runtime actor: it receives a goal, observes state, plans steps, calls tools, handles feedback, and may hand work to other agents.

Recent research is converging on this split. Surveys of agent skills describe skills as reusable procedural artifacts that reduce repeated low-level reasoning. Surveys of agentic AI architectures describe agents as systems with perception, planning, memory, action, tool use, and collaboration. Official platform docs show the same pattern in practice: Anthropic Agent Skills package capability bundles, while the OpenAI Agents SDK manages tools, guardrails, handoffs, sessions, and traces.

Abstraction Ladder
Prompt One-time instruction for a task or response shape. Tool Typed capability: search, calculator, database query, shell, API, or renderer. Skill Reusable procedure that tells an agent how to perform a class of work. Agent Goal-directed loop that plans, chooses tools or skills, observes results, and adapts. Multi-agent system Several specialized agents coordinated by handoffs, routing, or orchestration.
Skills live below agents. They make agents more reliable by externalizing domain procedures. Agents live above skills. They decide when the work needs planning, state, tool use, or delegation.

What Research Says

Early agent papers explain why agents are powerful and expensive. ReAct showed that interleaving reasoning and actions helps models plan, update state, and use external sources. Toolformer showed that models can learn when and how to call external APIs. Reflexion added verbal feedback loops for improving future attempts. Voyager made the skill idea concrete: an embodied agent builds a growing library of executable skills and reuses them in new worlds.

Newer papers focus on the operational layer. Agentic Tool Use in Large Language Models organizes tool use into prompting, supervised learning, and reward-driven policy learning, and highlights failure modes in tool selection and execution. Agent Skills for Large Language Models frames skills as an emerging infrastructure layer with acquisition, architecture, deployment, and security concerns. SkillGen treats skills as interventions whose net effect should be verified, which is a useful engineering principle: a skill is only valuable if it improves task quality, cost, or repeatability.

Evidence Cards
ReAct Agents improve when reasoning and action alternate, so use an agent when observations change the next step. Voyager Reusable skill libraries reduce repeated problem solving, so extract stable procedures into skills. SkillGen Treat skills as measurable interventions; keep them only when quality, cost, or repeatability improves.

Skill Engineering: The Recognized Third Layer

By mid-2026, the practitioner community has settled on a three-layer model of AI engineering. The Turing Post names them: infrastructure engineering (compute, serving, model tooling), agent engineering (orchestration, memory, tool use), and — newest — skill engineering: giving agents reusable procedures they can discover, apply, version, and reuse across tasks. Skills are a layer above agents, not an alternative. Agents consume skills; skills do not replace agents.

Research formalizes four properties that distinguish a skill from a plain instruction file (arXiv 2602.12430v4). A skill is composable (combines with other skills at runtime), discoverable (agents find and select dynamically — not hardcoded at build time), versionable (lifecycle-managed independently so you update the skill without redeploying the agent), and reusable (one definition works across multiple agents, personas, and task contexts). A critical architectural insight: the policy problem — when to activate a skill inside the agent's decision loop — is architecturally separate from the skill definition — what the skill instructs the agent to do. A correct skill can still fire at the wrong time if the harness's selection logic is flawed.

Four Properties of a Skill + the Supply Chain Risk
Composable + Discoverable Skills combine at runtime and are selected dynamically by the agent harness. The agent does not know at build time which skills will fire — the harness governs selection. Versionable + Reusable Update a skill without redeploying the agent. One definition works across multiple agents, personas, and contexts. Skills have independent lifecycles. MCP as distribution layer Skills are shifting from hardcoded prompt files to protocol-native artifacts served over HTTP and discoverable at runtime — analogous to npm packages for agent procedures. Supply chain attack risk A skill loaded from an external source runs inside the agent's context window. A poisoned skill can exfiltrate data, issue unauthorized tool calls, or subvert the agent's decision logic.
The frontier: projects like Hivemind and Hermes Agent enable skill acquisition from experience — agents that capture successful run patterns and convert them into reusable skills without requiring humans to write every skill upfront. This is the same insight as Voyager's skill library in embodied AI, applied to language agents.

Decision Rule

Choose The Smallest Abstraction That Owns The Uncertainty
Define a skill when the path is known The organization knows the procedure, examples, quality bar, tools, and review checklist. Define an agent when the path must be discovered The system must inspect state, choose steps, recover from errors, call tools, or coordinate people. Promote a skill into an agent When the skill needs persistent state, autonomous scheduling, multi-step recovery, or independent permissions. Extract skills from an agent When repeated sub-workflows become stable enough to version, test, share, and reuse.

Comparison

Dimension Skill Agent Business implication
Complexity Lower. Mostly instructions, examples, assets, scripts, and usage rules. Higher. Needs runtime state, planning, tool routing, error handling, observability, and permissions. Start with skills unless the workflow truly needs autonomy.
Flexibility Flexible inside a known procedure; weaker when the task path changes dynamically. Flexible across changing situations because it can choose actions from observations. Use agents for variable workflows, not for every repeatable task.
Maintenance Version like documentation plus scripts. Review when policy, examples, or tools change. Maintain as software: tests, traces, evals, permissions, cost budgets, incident response, and rollback. Agents have a larger operational burden and need explicit owners.
Cost control Usually cheaper because it reduces repeated planning and narrows context. Can be expensive because loops create repeated model calls, retrieval, tool calls, and validation steps. Package stable work as skills; reserve agent loops for uncertainty.
Abstraction Capability abstraction: how to do a type of work. Responsibility abstraction: who is driving a workflow toward an outcome. Skills standardize expertise; agents own execution state.

Cost Control

Skills control cost by making the model spend fewer tokens rediscovering a procedure. They can load only the relevant checklist, examples, schema, or script. Agents control business value by navigating uncertainty, but that uncertainty creates variable cost. A single agentic workflow can include planning calls, retrieval, tool calls, retries, validation, summaries, and human review packets.

Cost Shape
Skill cost Mostly context size, script runtime, and occasional maintenance. Agent cost Planning loops, tool retries, model routing, memory, tracing, evals, and review queues. Control pattern Budget loops, cap retries, route simple steps to cheaper models, and extract stable steps into skills.

Use Cases

Scenario Prefer skill Prefer agent
Marketing and content Brand voice, product claim checklist, image prompt style, SEO checklist, legal-review format. Campaign coordinator that gathers inputs, schedules work, checks approvals, and publishes through CMS tools.
Engineering Repo-specific testing workflow, migration guide, release-note format, code-review checklist. Incident agent that watches alerts, inspects logs, opens PRs, requests approvals, and tracks rollback.
Customer support Tone guide, escalation taxonomy, refund-policy summary, CRM note format. Case-resolution agent that reads account state, calls tools, proposes resolution, and escalates exceptions.
Finance and operations Monthly-close checklist, invoice validation rules, variance-analysis template. Workflow agent that reconciles records across systems, asks for missing evidence, and routes approvals.

Maintenance Model

Lifecycle Split
Skill owner Owns procedure, examples, references, scripts, allowed tools, and quality checklist. Agent owner Owns workflow state, permissions, model routing, traces, guardrails, and incident response. Evaluation owner Measures task success, cost, latency, safety failures, drift, and reviewer burden. Business owner Decides acceptable autonomy, approval gates, risk appetite, and accountability.

When To Combine Them

The best architecture is usually not "skills or agents." It is "agents with skills." A production agent should not improvise every subtask from scratch. It should load approved skills for stable procedures, call typed tools for external action, and escalate when the situation exceeds its policy or confidence boundary. This mirrors the research pattern in Voyager's skill library and the platform pattern in modern agent SDKs: reusable procedural knowledge below, goal-directed orchestration above.

Production Pattern
Business request Goal, constraints, user identity, data scope, and success criteria. Agent runtime Plans, observes, chooses skills/tools, manages state, and records traces. Skill library Approved procedures, examples, scripts, templates, rubrics, and domain references. Tool layer APIs, databases, browser, files, code execution, CMS, CRM, and ticketing systems.

Practical Rule Of Thumb

  1. Use a prompt when the instruction is temporary.
  2. Use a tool when the model needs a typed external capability.
  3. Use a skill when the organization has a repeatable way to do the work.
  4. Use an agent when the system must own a changing workflow across time, tools, state, and exceptions.
  5. Use multiple agents only when role separation, permissions, or parallel workflows justify the coordination cost.

References