Virtual Packs

Virtual packs are host-owned capability surfaces that behave like pack tools from the caller’s point of view, but are implemented by the platform.

They exist so that a pack or workflow can use important host behavior without bypassing the platform’s control model.

Why they exist

Without virtual packs, builders would be tempted to:

• write workspace state directly
• skip the approval and audit model
• reimplement host-owned operations in pack code

Virtual packs prevent that by giving you a sanctioned tool surface for privileged operations.

Common host-owned surfaces

The most important current examples are:

• worka.runtime for agent and workflow operations
• worka.ui for workspace view operations
• worka.db for controlled data access

Treat them as part of the platform contract. If one of them already does the job you need, use it instead of inventing a bypass.