Language: Deutsch · English
Enterprise AI becomes valuable when information turns into a reviewable workflow. A maintenance alert needs to be linked to the right asset. An answer needs reliable sources. A change requires the appropriate permission. At this intersection of knowledge, process and action, SupraWorx positions itself as a modular platform for enterprise AI.
Business teams and IT need a shared view of capabilities to make informed decisions. This overview brings together the publicly documented position as of 19 October 2026. It distinguishes documented components, capabilities that need qualification for a particular deployment, and priorities for further development.
The public feature matrix
Area | Publicly documented foundation | Deployment considerations |
|---|---|---|
Model independence and choice | Workbench execution through the GenAI tool configured for the tenant; an architecture incorporating specialised and local models. | A model-flexible approach. This does not establish a complete compatibility list for every provider, model and deployment mode. |
Structured outputs | .supra packages describe JSON output contracts, required fields and quality requirements. The import evaluation documents JSON mode for contracts declared accordingly. | A defined output contract enables reviewable handovers. Factual accuracy and actual validation must be checked within each workflow. |
Workflow routing | Ordered Workbench steps and approved Shortcuts; event-driven processes are described in the platform architecture. | Process orchestration is documented. Specific branches, retries and escalation paths need qualification for each workflow. |
Observability | The architecture describes telemetry and metrics including latency, cost, queues and source coverage. | The deployment configuration must specify which metrics a module provides, their retention period and available exports. |
Permissions | Tenant context, roles and tool approvals are described. Workbench import checks registered Shortcut references. | Permission propagation through to an external target system must be verified for each integration. |
Enterprise integrations | The API Gateway documents REST, SOAP, GraphQL, gRPC and WebSockets. The SupraAgent publication describes integrating tickets, Confluence and Jira. | General interfaces and described integrations do not constitute blanket approval of every vendor product or version as a standard connector. |
Sources: public Workbench examples, import evaluation, SupraWorx architecture, API Gateway and SupraAgent knowledge integration.
Model flexibility can be tested within the workflow
For a business, model independence primarily means freedom of choice: a process should use a model suited to its quality, data protection and operational requirements. Changing a model therefore requires practical evaluation. Are required fields preserved? Are sources attributed correctly? Do runtime or costs change? Does the handover to human review still work?
A sound approval records the model version, test cases and limitations. It makes clear which combination has been qualified for which task, keeping the discussion focused on operational value.
A structured result needs a controlled follow-up action
An illustrative service process shows how the components fit together. A report is captured, organised into asset identifier, observation and evidence, and checked for completeness. If the asset reference is missing, it goes for clarification. If the evidence is sufficient, a proposal is prepared for the responsible person. Only an explicitly approved action may change an external system. This example describes a target process, rather than a universally available integration.
Quality depends on the handovers. Formally valid JSON can be factually wrong. A helpful recommendation may fall outside the user's authority. Output contracts, subject-matter review, authorisation and execution should therefore be accepted together.
From the matrix to an informed purchasing decision
A pilot can start with a small set of concrete demonstrations: a representative input, an incomplete record, a denied access request and a controlled failure in the target system. For each case, define the expected result, responsible role and visible operational evidence. This makes it possible to assess whether a workflow actually simplifies day-to-day work.
The next priority is a versioned connector catalogue specifying target systems, supported versions, read and write scope, authentication, limitations and support status. Microsoft 365/MCP and relevant ERP, MES and CMMS connections are central to this development path. The other articles in this series explain how to standardise them.
Your next step: Bring a workflow, an example output and the target system involved. Together, these provide the basis for a verifiable SupraWorx requirement. Contact SupraTix.
