Aivyx PA · ManualContents ↓

Vertical packs

A vertical pack turns the general assistant into a domain crew — a restaurant kitchen, a clinic, a workshop — without forking it. The full design is in docs/VERTICAL_PACKS.md and the distribution format in docs/FREIGHT.md.

What a pack is made of

Each part rides on something the platform already has:

The kitchen pack in crates/verticals/aivyx-kitchen* is the complete, working example: a back-of-house crew (stocktake, inventory, purchasing, food safety) over a KitchenDB backend. aivyx-pa connect kitchen sets it up.

Building your own

VERTICAL_PACKS.md §6 walks through it step by step: the dependency rule (packs depend on aivyx-vertical-sdk, never on the engine’s internals), the team crate, the toolkit crate, registering scope bases, wiring it into the daemon and onboarding, and testing. Commercial packs can live under crates/verticals-private/, which is git-ignored but still part of the workspace.

Signed bundles

Packs reach users as signed binary bundles, <name>-<version>-<target>.aivyxpack: compiled tool processes, config and a manifest in one Ed25519-signed archive. Users never need a Rust toolchain.

aivyx-pa pack keygen <keyfile>                                  # once, for publishers
aivyx-pa pack build <staging-dir> --key <keyfile> --out <file>
aivyx-pa pack inspect <bundle-file>
aivyx-pa pack install <bundle-file>

install checks the signature against the built-in Aivyx key and any keys listed in [pack] trusted_publishers, refuses a bundle built for a different platform, and wires the pack in.

Config packs

A config pack (manifest format = 2) carries configuration only — no binaries, one file for every platform — so it can only use tools Aivyx PA already has. Its aivyx-pa part is a starter aivyx-pa.toml (profile, persona seed, roles, [[schedule]] routines, [autonomy]), an optional team config, SKILL.md skill folders, and the integrations it requires or can use (optional). The format lives in the shared aivyx-pack crate, whose aivyx-pack command builds and signs packs for aivyx-pa and aivyx-coder alike.

aivyx-pa pack check <dir> checks a pack’s aivyx-pa part and lists every problem: the template must load as a real config, autonomy (global and per area) can’t go above supervised, the team config and skills must load, and integrations must be ones Aivyx PA knows (gmail, calendar, drive, contacts, notion, obsidian, n8n, toolkit, vision).

Every capability scope the pack’s [[role]] entries and team members ask for is listed by pack check, pack inspect and pack install (* marks scopes that can change things). A pack may ask only for reads, memory, web access, team messaging and a narrow set of writes (drafting mail, calendar, tasks, contacts, notes, budget, reminders); pack check and pack install refuse any other scope by name (shell, delete, send, post, file and git writes, config, role and schedule changes, MCP calls, …). The operator adds those to their own config after install if they want them.

The template may only set [agent], [profile], [persona_seed], [[role]], [autonomy], [[schedule]], [team], [memory] and [skill_defaults] — who the assistant is and what it does. Anything else is the operator’s to set after install and fails the check: how far it reaches ([access], [fs], [sandbox]), whether its Studio is exposed ([daemon]), which programs it runs ([[tool_process]], [[mcp_server]]), where its requests go ([openai], [providers], …) and whom it trusts ([pack]). In [agent], injection_scan_enabled and injection_scan_exempt are the operator’s too.

aivyx-pa pack install makes a config pack a new named instance: it unpacks into the instance’s packs/<name>/<version>/, runs the same checks, points the template at the installed team and skills, records [pack] source, and runs the setup wizard with it. The pack’s routines replace the starter routines a new agent otherwise gets. just pack-kitchen builds the kitchen pack with a development key, as a worked example of the format.