Skip to main content

What Is a Pack?

A pack is a unit of capability that Worka can attach to a workspace.

In practical terms, a pack may provide:

  • tools
  • optional views
  • optional data storage or migrations
  • optional workflow behavior
  • integration logic for an external service or API

The main point of a pack is not packaging for its own sake. The point is to make a capability portable, governable, and attachable.

When you should create a pack​

Create or refine a pack when a workspace needs a capability that should exist as a named reusable unit.

Examples:

  • a GitHub pack that lists issues and posts comments
  • a Twilio pack that sends and receives messages
  • an Open Library pack that exposes browse, detail, and search tools
  • a workspace-specific internal pack that wraps a company API

If the capability should be discoverable, attachable, and governed separately from one individual workflow run, it probably belongs in a pack.

What a pack is not​

A pack is not the orchestrator.

A pack does not own the overall control plane, authorization model, or workspace state machine. It lives inside that platform and contributes capability to it.

That distinction matters because pack code should use the host’s sanctioned paths for privileged operations instead of trying to own them itself.

Generated packs and hand-authored packs​

Worka supports both:

  • packs produced or extended by Forge
  • packs written or refined manually by a builder

Those are not two different runtime models. They are two ways of arriving at the same runtime shape. A generated pack still needs a manifest, a build artifact, a release, and a workspace attachment.

What makes a pack good​

A good pack has:

  • a clear capability boundary
  • tool names that make sense in a workspace
  • tight outbound and credential requirements
  • structured tool results
  • a release path that the runtime can understand

If a pack tries to do everything, it quickly becomes harder to secure, test, and reuse.