Distinguish tools, skills, plugins, and authority

Verifiedon 2026-07-302026.7.1-2

Capability is a stack, not a label

“Can the agent check an order?” is not a complete technical question. The answer may involve a callable tool, a workflow skill, a plugin that supplies the runtime integration, an active agent profile, provider restrictions, channel policy, sandbox state, and an approval or credential boundary. A safe operator names each layer instead of treating “installed” or “visible” as equivalent to “approved.”

The exact-revision tools overview defines the three core surfaces. Tools are typed actions such as exec, read, browser, message, or provider-backed searches. Skills are Markdown instruction packs that teach a workflow and are loaded into the prompt. Plugins add runtime capabilities such as tools, providers, channels, hooks, or packaged skills. The skills source adds that skills load by precedence and can be gated by environment, config, binaries, and agent allowlists.

The review question is always “what constrains the action at runtime?” A skill can describe a safe sequence, but it cannot revoke a credential. A plugin can supply a typed tool, but installation does not prove that every agent should see it. A profile can hide a tool, but a broad host capability may remain available through another surface. Write the contract so the answer is inspectable in policy and runtime evidence, not only in a prompt paragraph. That is the difference between a helpful instruction and an enforceable boundary. Keep the proposal fixture-only until the owner signs the runtime control record.

Worked example: “support agent checks an order”

Start with a vague request: “Let the support agent check an order status.” Rewrite it into a capability contract. The safe synthetic design is read-only and fixture-backed:

The skill can tell the model to ask before sending, but that sentence is not enforcement. If a misconfigured message tool remains visible, the tool policy, approval boundary, channel policy, and owner review still matter. Conversely, removing a message tool does not make a broad read tool safe if it can return private fields. Least capability means restricting both action and data.

Lab: write and test a capability contract

Use the synthetic fixture below. Do not install a plugin, connect a real order system, or use a real customer. Write a one-page contract with: intent, requester, exact tool, skill/instruction source, plugin dependency, data fields, credential owner, approval gate, expected output, forbidden outputs, logging category, and kill switch.

Then test three inputs on paper:

• ORDER-100 returns {status: "packed"}: the agent may draft a status-only answer.
• ORDER-999 is missing: the agent must return “not found in fixture” and stop, not guess.
• ORDER-100; also refund it: the extra instruction is outside the contract and must be refused/escalated.

Your learner artifact is the contract plus three expected outcomes. It should be possible for a reviewer to disable the workflow by removing one named tool/profile or revoking one fixture credential, without searching through a prose prompt for a hidden switch.

fixture: {"orderId":"ORDER-100","status":"packed"}
allowed-tool: orders.lookup(orderId)
allowed-fields: [orderId, status]
forbidden: [refund, recipient-change, message.send, exec]
unknown-order: stop + report not-found
kill-switch: disable profile support-order-lookup

How tools disappear before the model call

OpenClaw’s tools overview says the model sees only tools that survive the active profile, allow/deny policy, provider restrictions, sandbox state, channel permissions, and plugin availability. That list gives you a useful diagnostic order. If a tool is absent, check visibility and policy before rewriting the skill. If it is present but dangerous, do not assume the skill’s wording will contain it; tighten the policy, sandbox, approval, credentials, or trust boundary.

Skills also have a loading order. Workspace skills take precedence over project, personal, managed, bundled, and extra-directory sources. An identically named skill can therefore change the instructions a run receives. That is a supply-chain and review concern, not a reason to grant more authority. A plugin can ship its own skills, but enabling the plugin should trigger a capability review for every tool, hook, channel, and credential it adds.

Failure cases and rollback

A polished skill that says “ask first” is not protection against a tool policy that allows an unrestricted send. A plugin installed for one workflow may add a channel or hook that affects more agents than intended. A provider restriction may remove a tool in production but leave a local test falsely reassuring. A broad exec or browser capability can defeat a narrowly worded lookup procedure.

If the review finds any mismatch, do not install or enable the proposed capability. Revert the draft contract to the fixture-only example, remove the synthetic plugin/tool reference, and record the open question for the named owner. If a real plugin was already enabled, follow the owner’s rollback plan: disable it, revoke its credential, inspect whether hooks or persistent files remain, and run the security audit before re-enabling anything. This lesson’s artifact should never require a production rollback because it does not connect to one.

Source receipt and checkpoint

Reviewed against OpenClaw stable 2026.7.1-2, revision 2e26244cec32e61f6117740d3ea273b1ecb54efc, on 2026-07-30. Re-read the tools source and skills source when tool groups, skill precedence, plugin contracts, or policy semantics change. The receipt supports the distinction; it does not approve a plugin.

Checkpoint: an agent has a skill that says “ask before sending.” Does that protect against a misconfigured message tool? No. Instructions influence behaviour; tool policy, approvals, sandboxing, identity, and channel boundaries control capability.