Verifiedon 2026.7.1-2
Action boundary
Before you act
- Expected result
- A workflow proposal names the action, required tool, instruction source, plugin dependency if any, data scope, approval condition, and kill switch.
- Failure mode
- A skill instruction is treated as enforcement, or a plugin install is treated as permission for every agent and sender to use its capability.
- Rollback
- Do not install or enable the proposed capability. Remove the draft proposal and return to a read-only synthetic example.
Capability is not one thing
A tool is a typed action an agent can call. A skill is an instruction pack that teaches a repeatable workflow. A plugin adds runtime surfaces such as tools, providers, channels, hooks, or packaged skills. These categories answer different questions:
| Question | Correct surface |
|---|---|
| Can the agent perform an action? | Tool, subject to policy and runtime conditions |
| Does the agent know the approved workflow? | Skill |
| Does the runtime need a new integration? | Plugin |
A model receives only tools that survive the active profile, allow/deny policy, provider restrictions, sandbox state, channel permissions, and plugin availability. That means “the plugin is installed” is not a sufficient approval record.
Lab: turn a vague request into a capability contract
Start with: “Let the support agent check an order status.” Rewrite it into seven fields: source of request; read-only data needed; exact tool; approved skill or procedure; identity allowed to invoke it; redaction rule; and a disable condition. Do not use a real order system. A mock JSON response is enough to test the design.
The correct contract should say what cannot happen too: no refunds, no recipient changes, no filesystem or shell access, and no reuse of a support lookup as authority to message a customer.
Checkpoint
An agent has a polished skill that says “ask before sending.” Does that protect against a misconfigured message tool? No. Instructions influence behaviour; tool policy and approvals control capability. Conversely, a visible tool does not make a workflow safe unless its input scope, requester, output route, and rollback are defined.
Source provenanceVerification and sources
Review receipt rr_foundations_capability_boundaries
- Outcome
- approved
- Method
- source-review
- Reviewer
- forge-independent-review
- Reviewed
Evidence
- openclaw-capabilities — openclaw-main-2e26244-tools; snapshot
45745bd5f200…
Limitations
- Primary-source editorial review; no plugin or tool policy was enabled.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.