Operator packs

An operator pack is a named operator made installable: the prompt contract that fixes how it reasons, the capabilities it requires, the guardrail defaults it ships with, and the pricing metadata the marketplace displays. Under the hood a pack is a connector, category ai-operator, published through the same pipeline as everything else, and governed identically once installed. This page describes what goes in a pack, how packs appear in the marketplace, and how versioning works when the artifact includes a prompt.

#What a pack contains

Four things travel with a pack. Everything else, the model binding, the trust policy in force, the connectors behind each capability, belongs to the installing tenant and is deliberately not part of the artifact.

#The prompt contract

The prompt contract is the operator's fixed reasoning frame: the goal statement, the constraints, the shape of the ExecutionPlan it must return, and the refusal conditions under which it must propose nothing. It is called a contract because it is versioned and reviewed like an interface, not tuned like a knob. The model reasons inside it; nothing at runtime can rewrite it. When the contract changes, the pack version changes, and installers see the diff before upgrading.

The contract also pins what the operator may claim. An operator that answers questions over governed data, as Operations Analyst does, contracts that every number it emits carries its source, so a fallback value can never pass as a real metric.

#Capability requirements

A pack declares the capabilities it needs by intent, never by vendor. The live Order Risk listing requires a commerce connector for order state, a support connector for conversation context, and a shipping source for scan events; whether that is Magento or Shopify, Kustomer or Zendesk, is the installer's binding, not the pack's business. This is the capability-to-connector indirection that makes swapping a vendor a configuration change, and it is why an installed operator holds no credentials of its own: it acts through the connectors the tenant has already authorized.

#Guardrail defaults

A pack ships the trust-policy defaults it recommends for itself, expressed in the kernel's TrustPolicy shape: which of its proposed tools should be allowed, which should alert a human, and what value ceilings apply. Defaults are suggestions, applied only when the installer accepts them, and the tenant's own policy always has the last word. A pack cannot grant itself anything: the executor evaluates default-closed, so a tool no policy allows is blocked no matter what the pack requested.

// Shipped with the pack; applied only when the installer accepts them.
const defaults: TrustPolicy[] = [
  { tool: 'order.hold',    decision: 'ALLOW' },
  { tool: 'order.reroute', decision: 'ALERT' },              // act, and page a human
  { tool: 'order.refund',  decision: 'ALLOW', maxValue: 100 } // BLOCK above the ceiling
];
// Every pack recommends propose-only for its first two weeks in a tenant:
// plans are produced and reviewed, nothing is disposed.

#Pricing metadata

The listing carries the commercial terms the marketplace displays. Operator packs are priced from $49 per operator per month; during early access the platform itself is free and the Team plan is $240/mo. Actions the executor disposes above plan allowances meter at $0.01 per action, and that metering is read off receipts, the same records you audit with. There is no separate billing counter to disagree with the audit trail.

#The pack manifest

Because an operator pack is a connector, its manifest is a ConnectorDef with category ai-operator. The tools it declares are the actions it may propose, all side-effecting, since an operator's output is a plan; the pack-specific artifacts, the prompt contract, guardrail defaults, and capability requirements, travel alongside the def in the project directory and are read by fibric publish.

import { defineConnector, tool, none } from '@fibric/connector-sdk';

export default defineConnector({
  id: 'op-order-risk',
  version: '1.0.0',
  category: 'ai-operator',
  publisher: 'partner',

  // An operator holds no credentials of its own. It acts through the
  // connectors the installing tenant has already authorized.
  auth: none(),

  // The actions this pack may PROPOSE. Every one is side-effecting:
  // proposals only ever run through the deterministic executor.
  tools: {
    'order.hold':  tool({ sideEffecting: true, handler: () => { /* proposed, never called directly */ } }),
    'notify.send': tool({ sideEffecting: true, handler: () => { /* proposed, never called directly */ } }),
  },
});

packs/order-risk/
  index.ts            the ConnectorDef above (category: ai-operator)
  prompt.md           the prompt contract, versioned with the pack
  guardrails.ts       recommended TrustPolicy[] defaults
  requires.json       capability requirements, by intent
  listing.json        marketplace metadata (see the publishing page)
  fixtures/           recorded envelopes for review and CI

#How packs appear in the marketplace

Two operator packs are live in the marketplace today, and they are the reference for what a finished listing looks like:

A pack's detail page is generated from the same listing fields as any connector: a tagline, a two-paragraph about, three senses lines describing what it reads, an acts list describing what it proposes, the requires list of capability needs, and worksWith links to the connectors that satisfy them. Both live packs list cn-kustomer and cn-magento in worksWith, which is exactly the binding running in production. The full field reference is on the publishing page.

#Installing a pack

Installation is capability binding plus guardrail acceptance. The CLI walks the requires list, offers the tenant's existing connectors that provide each capability, and applies the guardrail defaults you accept.

$ fibric operators create --from op-order-sentinel
  op-order-sentinel@2.3.1  Order Risk  (Fibric, official)

  requires  commerce order state      -> bound to cn-magento (magento-live)
  requires  support conversations    -> bound to cn-kustomer (kustomer-live)
  requires  shipping scan events     -> bound to cn-shipstation (ships-live)

  guardrails (proposed defaults)
    order.hold     ALLOW
    order.reroute  ALERT
    notify.send    ALLOW
  accept defaults? [Y/n] y

  mode: propose-only (recommended for new installs)
  created operator order-risk in tenant paperco-prod. nothing will act
  until you set mode=live: fibric operators create --help

In propose-only mode the pack runs its full sense and reason loop and emits plans that appear in the plan queue, but the executor disposes none of them. Moving to live is a single explicit change, and even then every action still passes the trust policy per step. There is no mode in which an installed pack bypasses governance.

#Versioning

Packs use semver, and the prompt contract is part of the public interface. The rules the review process holds publishers to:

Published versions are immutable. An installed operator keeps running the version it was installed with until someone upgrades it, and receipts record the pack version that proposed every action, so an audit can always answer "which contract produced this plan".

#Local operators vs packs

Not every operator needs to be a pack. An operator you write for your own tenant with the SDK runs on the identical governed runtime, and packaging adds review, versioning, and listing overhead that only pays off when someone else installs it. The differences are operational, not architectural:

The usual path is local first: run the operator in your own tenant until the prompt contract stabilizes, then package it. Receipts record the pack version (or local) that proposed every action either way, so nothing about auditability changes when you graduate.

#Keep going

• Operators: the concept a pack packages, including the anatomy and lifecycle of a run.
• defineConnector(): the def shape a pack is built on, category ai-operator.
• Publishing to the marketplace: listing metadata, review, and the status lifecycle.
• Trust tiers: how the guardrail defaults are evaluated at run time.