Manage the Catalyst Assistant
The Catalyst Assistant answers questions about your organization's own Catalyst resources. This page covers what an operator decides about it: whether it is on, what it may read, where it runs, and how much it may spend.
Enabling it
The assistant is enabled per organization by Diagrid. There is no self-serve switch today — ask your Diagrid contact.
Two things are set when it is enabled:
- Entitlement — your organization's plan gains the assistant.
- Opt-in — the assistant is turned on for the organization, with a data-sharing level and an operating mode.
The defaults are metadata and read-only.
Users also need an organization-wide Catalyst role. Someone whose access is scoped to a single project does not get the assistant, deliberately: it answers across the whole organization, so it is gated on organization-wide access.
Operating mode
The assistant is read-only and cannot be set otherwise. Every operation it may call is a read; write operations are absent from its tool set rather than blocked at runtime. It cannot start, stop, rerun or terminate anything.
Data-sharing levels
The data-sharing level decides which fields leave the platform and reach the model. Enforcement is on the API response, before the assistant sees it — so this is a limit on what can be read, not an instruction the assistant is asked to obey.
| Level | Exposed | Withheld |
|---|---|---|
metadata (default) | Resource names, statuses, timestamps, durations, error messages | Workflow custom status, workflow input, workflow output, other resource-specific values |
full | The above, plus custom status, inputs and outputs | Credentials and secret values, at every level |
Credentials are never shared, at either level.
Choosing a level
metadata is the conservative default and is the right choice when workflow payloads may carry regulated or personal data. It answers operational questions — what ran, when, how long, what failed.
full is needed for questions about business state. Your workflows' custom status is where your own code records progress — awaiting_analyst_review, rejected_kyc. At metadata that field is withheld, so questions like "which onboardings are waiting for manual approval" cannot be answered.
Two things are worth knowing before choosing:
- The level is all-or-nothing. Exposing custom status also exposes workflow inputs and outputs — the payloads themselves. There is no middle setting today.
- Workflow names are never withheld. If your workflows register each stage as its own workflow name, stage questions are answerable at
metadataby name and status alone. This is often the better design regardless of level.
At metadata, a withheld field and an absent one look the same to the assistant. Ask a question that depends on custom status and it may report that there is nothing, rather than that it cannot see. Frame such questions by workflow name and status, or move the organization to full.
Where it runs
One assistant serves every entitled organization in a Catalyst region, and your organization's home region decides where yours runs. Where several regions could host it, the choice is not made for you — that decision carries data-residency meaning, so it is pinned explicitly.
Conversation history belongs to the region it was created in and does not travel if the organization moves.
Spend
Two caps apply, and both are set by Diagrid:
- A per-run token cap, so one question cannot consume a month's budget.
- A monthly token budget per organization.
Turning it off
Ask your Diagrid contact. Disabling is supported and does not strand resources — the assistant's infrastructure is removed with it.
