Agents, Skills, Augments, Tools, and Capabilities

Evidence boundary: This page defines the canon’s public architecture vocabulary. It does not claim that a named package is installed, discoverable, invoked, healthy, published, or useful. Those are separate states requiring separate evidence.

The Short Version

A capability is an evidenced ability. An Agent is a bounded process that pursues a goal through a model-mediated loop. A Skill is a selectively loaded package of procedural context. A Tool lets the runtime read or change external state. A Persona or stance shapes model behavior but grants no authority. A Workflow governs allowed state transitions.

An Augment is the governed product architecture that makes a reusable capability operable across its declared runtime, evidence, packaging, support, and delivery lifecycle.

The category names end-to-end product responsibility rather than a folder type: the declared outcome, components, runtime paths, evidence, support, and delivery must form a coherent whole.

The Public Vocabulary

Term	What it is	What it is not	Evidence it needs
Capability	An evidence-bounded ability to produce an outcome under declared conditions.	A file, title, aspiration, or model-provider claim.	Representative task outcomes, limits, conditions, and failure evidence.
Agent	A model-mediated process operating in a goal, state, action, and observation loop under an authority and resource envelope.	A synonym for model, chatbot, autonomy, or product.	Trajectory, authority, budget, termination, recovery, and outcome evidence.
Skill	A versioned procedural-context package selectively loaded to help a model perform a class of work.	Permission, guaranteed expertise, or a complete product merely because it has a folder.	Selection, loading, dependency, behavioral contribution, and regression evidence.
Augment	A governed product architecture that composes the minimum complete set of competence, interfaces, instructions, knowledge, assets, tools, workflows, evidence, packaging, support, and delivery needed for a reusable outcome.	A large Skill, plugin, prompt bundle, persona, agent loop, or decorative product label.	Architecture-completeness evidence for the declared promise; installed, healthy, published, and valuable claims each require their corresponding lifecycle evidence.
Tool	An external affordance through which the runtime reads or changes state.	A behavioral instruction or proof that an action succeeded.	Contract, permission, input validation, execution, observation, and postcondition evidence.
Persona / stance	A recurring behavioral, epistemic, and relational prior: what to notice, how to judge, and how to engage.	Credentials, identity proof, authorization, or an Agent by itself.	Task-relevant behavioral comparison and authority-boundary tests.
Workflow	The permitted state-transition structure around one or more model invocations.	The model’s prose plan or an unbounded loop.	Transition, checkpoint, exception, termination, and replay evidence.
Worker / subagent	A separately scoped execution context receiving a delegation contract.	An independent authority or an excuse to duplicate work in parallel.	Delegation, contribution, provenance, synthesis, budget, and stop evidence.
Plugin / container	A distribution or integration envelope that carries compatible components to a host.	The capability, Skill, or Augment merely because it contains them.	Manifest, dependency, installation, permission, compatibility, and package-integrity evidence.
Adapter	A named translation between canonical behavior and a particular host, model, provider, or interface.	A silent rewrite of the canonical source.	Provenance, compatibility, differential tests, and rollback evidence.

These labels describe different responsibility axes, not mutually exclusive physical objects. A plugin may carry an Augment, while an Augment may use a Skill, Agent, Tool, Persona, or Workflow. Compound terms such as capability registry refer to capability-bearing artifacts and their evidence records; registry presence does not establish the capability itself.

How the Categories Relate

flowchart LR
    N[Human need or system outcome] --> A[Augment: complete governed product]
    A -. may compose .-> I[Interface]
    A -. may compose .-> S[Skill: procedural context]
    A -. may compose .-> P[Persona or stance]
    A -. may compose .-> G[Agent or worker loop]
    A -. may compose .-> T[Tool]
    A -. may compose .-> W[Workflow]
    A -. must include as needed .-> E[Evidence, packaging, support, and lifecycle]
    S --> C[Capability contribution]
    G --> C
    T --> C
    W --> C
    C --> O[Verified outcome under declared conditions]

The dotted relationships mean may compose, not must contain. An Augment may use one Skill and no Agent. It may use deterministic scripts and no external Tool. It may coordinate several specialists through a governed workflow. Completeness is measured against the product promise, not component count.

Why an Augment Is Its Own Category

Skills, tools, agents, workflows, personas, and plugins name component roles or delivery envelopes. Augment names responsibility for the declared end-to-end product outcome, including the runtime paths, evidence, packaging, support, and delivery required to operate it.

A Skill can teach a model how to perform work while leaving installation, interfaces, dependencies, deterministic helpers, evidence, support, and delivery unresolved. An Agent can execute a loop while knowing nothing about product documentation, package integrity, host compatibility, user recovery, or whether the result creates value. A plugin can transport files while proving almost nothing about the behavior they produce.

An Augment therefore denotes the product boundary. It begins with a declared reusable outcome and includes the minimum architecture needed to make the product’s promise, runtime paths, evidence, support, and delivery state legible.

This does not mean “put everything into one enormous bundle.” The governing shape is the smallest complete architecture:

real need
  -> reusable capability boundary
  -> minimum coherent components
  -> governed runtime paths
  -> representative evidence
  -> usable package and documentation
  -> supported delivery
  -> observed user value

Selection and Progressive Loading

Capability selection is not keyword roulette. A runtime should first determine which packages are eligible for the current user, task, environment, risk, dependencies, and authority. It can then shortlist using compact metadata, load a Skill body only after selection, and load referenced material only when the work actually requires it.

available catalog
  -> eligible for this task and authority
  -> selected for likely contribution
  -> procedural body loaded
  -> needed resources loaded progressively
  -> behavior invoked
  -> contribution and outcome evaluated

The selection record should identify candidates considered, the selected package and version, the reason, omitted alternatives where consequential, loaded resources, composition order, context cost, dependencies, tool exposure, and observed contribution.

State Claims Must Stay Separate

The shared host qualification subset—created, installed, discoverable, statically ready, invoked, and behaviorally healthy—overlays both chains. Skill packaging, eligibility, selection and loading, and Augment documentation, routing, delivery, publication, and observed value remain additional claims rather than replacements for that subset.

For a Skill or similar capability-bearing package:

created
  -> packaged
  -> installed
  -> discoverable
  -> statically ready
  -> eligible
  -> selected
  -> loaded
  -> invoked
  -> behaviorally healthy

For an Augment, product states continue beyond runtime behavior:

coherently built
  -> packaged and verified
  -> documented
  -> installed on a named host
  -> discoverable
  -> statically ready
  -> routed through a declared entry path
  -> invoked
  -> behaviorally healthy
  -> assigned to a real delivery channel
  -> published
  -> producing observed user value

These are not ceremonial vocabulary differences. “Installed” means the host received files. “Discoverable” means the host can surface the capability. “Invoked” means it entered a run. “Healthy” means representative behavior passed. “Published” means an authorized delivery edge completed. “Valuable” requires outcome evidence. Passing one state does not smuggle the others across the border in a fake mustache.

A Synthetic Composition

Imagine a fictional Maintenance Triage Augment for a small equipment team. Its product promise is to turn messy maintenance reports into an evidence-linked triage packet while preserving technician authority.

Its minimum architecture might include:

Component	Responsibility
Structured intake surface	Captures the machine, symptoms, urgency, and available evidence.
Triage Skill	Guides symptom normalization, uncertainty handling, and evidence preparation.
Equipment reference set	Supplies approved terminology and maintenance constraints.
Read-only asset lookup Tool	Retrieves the correct equipment record under scoped credentials.
Deterministic risk rule	Forces safety-related reports into the urgent human queue.
Workflow	Moves the case through intake, evidence check, triage proposal, technician review, and closure.
Evaluation fixtures	Test missing evidence, contradictory reports, unsafe certainty, and false completion.
Documentation and support path	Helps operators start, recognize results, correct mistakes, and recover.

The Augment is not the Skill in the second row. It is the governed whole that makes the outcome usable. If the Tool is unavailable, the product must have a bounded degraded mode. If the Skill is installed but never selected, the product is not healthy. If a polished packet is produced without the equipment record, it is not evidence-grounded.

Choosing the Right Layer

Need	Smallest fitting response
One stable behavior inside an existing model workflow	Prompt or reusable instruction.
Reusable procedural competence loaded only when relevant	Skill.
Exact read or state-changing reach	Tool with a deterministic contract.
A bounded multi-step goal/action/observation loop	Agent.
Fixed transitions, approvals, retries, and recovery	Workflow.
Host-specific compatibility without changing canonical intent	Adapter.
Transport and installation of compatible components	Plugin or package container.
A complete reusable product outcome with runtime, evidence, packaging, support, and delivery custody	Augment.

Use the smallest layer that completely owns the need. A larger noun is not a maturity level.

Canonical Follow-Through

Use AI-ENG-M — Agentic Orchestration for the governing architecture, AI-ENG-B — Context Architecture for selective loading, AI-ENG-N — Tool Contracts for executable affordances, AI-ENG-U — AI Supply Chain Security for package trust, AI-ENG-AA — Evals Architecture for behavioral evidence, and AI-ENG-AB — Verification Artifacts for lineage.

← Back to the Canon Map · How to Use This Canon