The Catalyst Assistant
The Catalyst Assistant answers questions about the resources in your own organization — your projects, App IDs, workflows, agents, components and MCP servers. You ask in plain language, and it reads the same Catalyst APIs the console and the CLI read.
It is operated by Diagrid and runs server-side. You do not supply a model provider key, and nothing needs installing.
What it is for
The assistant is most useful for questions that span many records, where the answer is a search rather than a lookup:
- "Which workflows failed in the last hour?"
- "Show me the AML screenings from today."
- "Which App IDs have no access policy?"
It is not a replacement for the console or the CLI. It reads the same data and is often the faster way to find something you then open in the console.
What it can and cannot do
It is read-only. Every operation it is allowed to call is a read. It cannot start, stop, rerun, terminate or change anything. Asked to, it explains what you would run instead.
It answers only from your own resources. It has no knowledge of other organizations, and no general knowledge of your systems beyond what the Catalyst APIs return for you.
It answers as you. The assistant carries your identity, not a service account, so it can only see what your own permissions allow. This is why it requires a user login:
diagrid login
An API key will not work — an API key carries no user identity for the assistant to verify.
Where to find it
In the console — open the assistant from the launcher in the Catalyst Console. The drawer can be pinned beside your work or expanded full-screen, and it keeps a conversation history.
From the CLI — diagrid chat starts an interactive session in your terminal:
diagrid chat
What it is allowed to see
Your organization has a data-sharing level that decides which fields reach the assistant at all. Fields are removed from API responses before the assistant sees them, so this is a limit on what it can read, not a rule it is asked to follow.
| Level | What the assistant can read |
|---|---|
metadata (default) | Names, statuses, timestamps, durations and error messages — for workflows, components, topics and the rest. |
full | The above, plus workflow custom status, workflow inputs and outputs, and other resource-specific values. |
The practical difference shows up in questions about business state rather than operational state. A workflow's custom status is where your own code records where a run has reached — awaiting_analyst_review, rejected_kyc, pending_settlement. At metadata that field is withheld, so questions that depend on it cannot be answered:
- "Which onboardings are waiting for manual approval?"
- "Why was this run rejected?"
- "Which runs are stuck at the review step?"
Questions framed around workflow names and statuses work at either level, because names are never withheld. If your workflows model each stage as its own registered workflow, "how many enhanced due diligence runs are in progress" is answerable at metadata.
Changing the level is an organization-wide decision — see Manage the Catalyst Assistant.
Getting it enabled
The assistant is enabled per organization by Diagrid. If you do not see it in the console, ask your Diagrid contact to enable it for your organization.
