Agent skills
An agent skill is a packaged, reusable unit of capability that an agent invokes to accomplish a focused task. Agent skills are how expertise is captured once and reused, authored, versioned, published, and invoked under the same governance as every other asset on the platform.
The platform uses the word skill in exactly one sense, and it is this one: a capability an agent invokes. It is named agent skill throughout this documentation because a data platform and an agent platform sharing one catalog give the bare word too many plausible readings. A vertical's industry pack ships agent skills, and the catalog's skill registry is where they live.
This page covers what an agent skill is, how skills are authored and packaged, how agents invoke them, and one honest limit at the edge.
What an agent skill is
An agent skill turns a capability into a first-class, governed asset rather than an ad-hoc prompt or a raw connector call. Agent skills are:
- packaged: a self-contained unit of capability with a defined interface;
- versioned: a skill has a lifecycle, and updates are tracked; and
- governed: a skill is reached through the same grant machinery, tool ceilings, and classification handling as any other capability.
Skills sit alongside two neighbours in the Tool Catalog: raw tools (the primitives an agent acts through) and functions (user code an agent may call). A skill is the reusable, higher-level capability composed on top of them.
Authoring and packaging
Agent skills are built, and there is a dedicated authoring surface (the Studio) for building them: a skill catalog, detail, and editor, plus a skill picker used wherever a skill is attached to an agent, a billet, or a workflow node.
Agent skills are not only hand-written. The platform's skill machinery can:
- acquire a skill from demonstrations, documentation, or successful completions;
- compose skills into compound skills, and chain them;
- evolve a skill through use, tracking success rates over time;
- transfer a skill between agents to bootstrap specialisation;
- certify a skill and validate it before deployment; and
- publish an existing catalog asset as a skill, along a visibility ladder.
A published skill becomes discoverable through the catalog like any other capability, so a skill authored once can equip many agents.
Invoking an agent skill
An agent reaches a skill in two main ways:
- As a workflow node.
skillis a core node type in the workflow graph, so a skill is a first-class step in an orchestration, invoked through a catalog skill invoker. - As a projected tool. Through tool-to-skill projection, an external tool can be promoted into a skill (see Tools & MCP), so an integration becomes a governed, reusable capability rather than a raw connector call.
Every invocation carries the invoking agent's classification and tool ceiling, and is subject to the gate at the action boundary.
Agent skills at the edge
A governed skill reaches a device as a signed catalog object, and runs there
under the same gates it runs under on a cell. The delivery path invents no new
transport, package format or signature: a skill travels as a catalog object whose
kind is skill, and the device's existing fail-closed admission gate admits it.
That gate verifies the context-bound hybrid signature offline against pinned
trust roots, then re-derives the effective isolation tier rather than believing
the one the object declared for itself, checking it against the host and against
every capability the object asks to broker. Only an object that clears all of
that is readable as a skill definition, and a body whose skill_id or version
contradicts the signed envelope is refused rather than reconciled.
On the device the plane keeps the two stores the catalog-object layer does not
provide: the per-agent binding and the invocation log. A skill the acting
agent is bound to is equipped into the agent loop as a skill.<name> tool, so it
is called the same way any other tool is. Skills whose body is a prompt or a model
call run on the same on-device model-serving runtime the agent reasons with, which
is what lets a governed skill run air-gapped.
The invoker decides the same questions in the same order as the cell's, with the same refusal names, because a skill one runtime runs and the other refuses would be a governance surface that does not exist:
| Order | Gate | Refusal |
|---|---|---|
| 0 | An acting agent is named | Missing acting agent |
| 1 | The definition resolves by schema and name | Skill not found |
| 2 | It is visible to the acting entity | Skill not visible |
| 3 | Its status is active | Skill not active |
| 4 | A binding exists, and is enabled | Skill not bound / skill disabled |
Definition and binding configuration are then merged, with the binding winning on a key conflict, before dispatch, and the invocation is recorded. The ordering is load-bearing and part of the cross-language contract: a device that checked binding before visibility would tell an unauthorized caller "you are not bound to it", which is more than it should learn.
A device that has never been delivered a catalog object equips no skill tools and writes no stores, and a store that cannot be opened leaves the skill surface off with the agent loop still running.
Alongside this, the Edge Agent performs substantial on-device work through its own tool set: reasoning, the coding surface, document and entity extraction, and on-device recall.
See also
- Tools & MCP: tools, functions, and tool-to-skill projection.
- Orchestration & Agent Teams, the
skillnode in the workflow graph. - Agent Platform concepts, the authoring lifecycle and how agents are equipped.
- Industry packs, which ship a vertical's agent skills as part of a deployable bundle.