Slots

A Slot is a named gap in a Package that the installing Organization fills with its own model, credential, documents, speech provider or phone trunk. A Package declares Slots; it never contains what goes in them.

The rule: anything that differs per installer, or is a secret, is a Slot. Everything else is baked into the Package.

Declaring a Slot

slots:
  - id: calendar-access # how the installer and other files refer to it
    type: credential # one of the six types below
    required: true # must the installer fill it?
    description: The practice's own calendar account.
    boundTo: [tools.calendar] # which objects use it (optional)
    scheme: oauth2 # type-specific options

Definition files point at Slots by id, e.g. an Agent's llm.slot: reasoning, a Tool's credentialSlot: calendar-access, a Knowledge Base's embedding.slot: embedding.

The six types

llm

- id: reasoning
  type: llm
  required: true
  description: The model the Team lead and intake think with.
  constraints:
    minContextWindow: 128000

• Never deferrable. Nothing in a Package runs without its models, so the installer must answer every llm Slot before the install continues.
• constraints.regions is checked against the region recorded on the installer's LLM Configuration. A value of EU, US, Local or Other matches that group (EU is eu or any EU member country); any other value must equal the recorded two-letter country code. A Configuration whose region is unknown is refused (SLOT_LLM_CONSTRAINT_UNVERIFIABLE) until its owner sets the region. Every region a Slot permits must also be declared in compliance.regions; a chip there such as EU covers Slot regions naming its member countries (e.g. de), not the other way round.

LLM Slots: how many?

Each required llm Slot is a question the installer must answer. Use one for the model most things think with, add a cheaper tier only where it pays, and a separate one for embeddings when the Package has a Knowledge Base. More than three required llm Slots triggers a MANIFEST_SLOT_LLM_TIER_COUNT warning, asking you to justify it.

credential

- id: ledger-access
  type: credential
  required: true
  scheme: api_key
  description: An API key for your ledger, with read access.

The installer binds it to a {{secret.KEY}} reference to a Secret in Settings → Secrets. The value itself never touches the Package, the CLI or the artifact. oauth2 credentials can only be connected in the Studio wizard, not from a terminal.

A Slot may not carry any field that holds a secret value (apiKey, token, password, value and similar). That fails with MANIFEST_SLOT_INLINE_CREDENTIAL.

knowledge-source

Bind with boundTo: [knowledgeBases.<name>]. At install, the operator uploads their own files, connects a source, or skips. A skipped Knowledge Base is created empty and listed as outstanding until it has content.

stt and tts

- id: speech-in
  type: stt
  required: true
  allowedProviders: [soniox]

allowedProviders limits which providers the installer may pick. Omit it to allow any the platform supports. The provider keys are listed in Voice and SIP → Providers.

sip-trunk

The installer chooses one of their own inbound trunks and the number the Package answers. A Package never brings a carrier account or a number. Every inbound-call trigger names a sip-trunk Slot.

Where a Package's output goes (an email report, for example) is not a Slot: put a Send Email node in the Workflow. Its server and recipients are left out of the artifact and filled in by the installer after install. See Triggers → Sending the result. The delivery-channel Slot type of earlier versions has been removed.

Required, optional, deferred

• required: false Slots can be left empty.
• Any Slot except llm can be deferred at install ("Skip for now" in the wizard, --slot.<id>=defer in the CLI). The Package installs as installed-incomplete (Needs finishing in Studio), its entry point still runs, and the Slot is listed on the Package's page until it's bound.