When an agent reaches beyond its workspace

QwenPaw becomes useful when it can do more than generate text: load a skill, inspect a project, call an external service, or deliver an outcome through a channel. But “installed” is not the same as “available,” and “available” is not the same as “authorized.” This chapter follows the path from extension to execution, distinguishing Skills, Plugins, Drivers, and channels before showing how governance, approval, scanning, and sandboxing constrain a consequential tool call.

Capability is not the same as availability

A Skill is a workspace-scoped way to add knowledge or behavior to an agent. QwenPaw resolves effective skills from the workspace, channel, and configuration, and can preload selected skills while leaving others available for later viewing or loading. The local workspace then filters tools according to active modes, skills, enabled features, configuration gates, and—when the agent is a subagent—an explicit whitelist.

This creates two useful separations. First, a skill can exist on disk without being active for every channel or agent. Second, an active skill does not automatically mean every tool associated with the application is visible in the prompt. The model sees an effective toolkit assembled for the current request. That is a narrower and more intelligible boundary than dumping every installed instruction and callable function into every context.

Plugin-provided skills follow the same workspace logic. A plugin can provision them into workspaces, mark their source in the workspace manifest, apply default enablement and channel scope, and remove the skills it owns when it is uninstalled. Source ownership matters here. Without it, uninstalling a plugin could leave behind ambiguous files that still influence an agent while appearing to belong to the user or to the core system.

A Plugin is broader than a Skill. QwenPaw's plugin model has explicit categories for tools, providers, hooks, commands, channels, memory backends, frontend bundles, and full applications. A manifest describes entry points, dependencies, and version compatibility. The loader validates the manifest, isolates plugin imports, serializes lifecycle operations for the same plugin, and cleans registry and module state on unload. Tool registration claims ownership and synchronizes governance before the tool is exposed; if later registration fails, the loader rolls back the partial state.

That lifecycle is part of the capability contract. A new function is easy to demonstrate. A managed extension must also answer: who owns its name, which workspaces receive it, what happens when it is reloaded, how its dependencies are installed, and how its files and runtime modules are removed. QwenPaw reduces namespace collisions and stale hot-reload state through isolation and cleanup, but it does not make third-party code trustworthy. A declared plugin dependency is still a supply-chain and maintenance decision for the operator.

Drivers make external capabilities legible

A Driver is the boundary QwenPaw uses to normalize an external capability. The current concrete protocol is MCP, but the DriverManager presents capabilities through a protocol-neutral contract. It owns Driver cards, credentials, handler lifecycle, capability discovery, and invocation. External tools can therefore be named, enabled, scoped, reloaded, and policy-checked without every protocol inventing a completely separate authorization path.

This is valuable because an external service is more than an endpoint.