FLOWX.AI vs Wonderful (2026)

Full. The platform names the core banking systems it reaches, Jack Henry, FIS, Finastra and Temenos, alongside mainframes, databases, transportation systems and APIs, leaving the legacy estate in place rather than replacing it. The connector documentation shows how: a connector is an independently deployable microservice over Kafka, built step by step from a published quickstart and invoked from the process designer, with replies landing in process variables.

FlowX is a process and workflow engine before it is an agent platform. The documentation's first two entry paths are creating a process with a UI in the visual designer and building a workflow, and the architecture is a layered microservices platform with process execution as its own named concern, communicating through Apache Kafka. Multi step orchestration is the platform's original function rather than a capability added for agents. Control flow is documented in the BPMN building blocks: exclusive (XOR) gateways route each instance down one path on evaluated conditions, and parallel gateways run concurrent branches. A Custom Agent node and a BPMN integration page place AI agents inside processes, and the Agent Builder adds typed AI nodes such as intent classification and context retrieval. The agent layer is multi agent by construction. The architecture names business agents that power end user experiences at runtime, and agent stacks combine cooperating agents against a single process, nine for mortgage underwriting being the vendor's own example. The FlowX.AI 5 launch announcement adds an evolving architecture in which agents propose system changes that builder agents implement after approval, so agents can modify the workflow rather than only execute it. The grade rests on the process engine, its gateways and the multi agent stacks.

Every trigger class has its own page in the 5.9 documentation. Schedule. Scheduled processes automate process instance creation on specific dates, times or intervals using Start Timer Event nodes and predefined schedules, with timer expressions in cron syntax for scheduling or ISO 8601 for durations and timeouts. Timer start, intermediate and boundary events are documented separately. Inbound webhook. Incoming Webhooks start a process from an external HTTP POST or resume a running instance and inject the payload, secured with API keys, event driven, with no polling. Email. Email Trigger connects to IMAP mail servers and monitors specific mailboxes to start workflows, and Message Start Event starts an instance on a message, incoming email or incoming webhook. Inbound API. Four documented REST endpoints start processes, including by workspace and process name, described as the simplest public entry point for triggering from a backend or scheduled job. Event. Manage Triggers is a centralized interface to view, activate and deactivate event based triggers that automatically start process instances, and message catch boundary events interrupt or run alongside a user task on an incoming message. Channel. A Chat UI component enables interactive AI agent conversations with end users, and client SDKs cover web, iOS and Android. The Manage Triggers page points to operation rather than capability: an interface for activating and deactivating triggers across builds is built for customers running enough of them to need governing. Kafka carries communication between the platform's own services and is not counted as a trigger.

FlowX documents a Knowledge Base integration that agents query during workflow execution. Documents are ingested into Knowledge Bases searched with vector embeddings using hybrid, semantic or keyword search, across multiple stores with relevance scoring. Append, replace and delete operations carry an audit trail and entries are versioned with the app, so the knowledge base is a maintained structure rather than context assembled per request. Companion pages cover managing stores, using Knowledge Bases in workflows and testing queries. The vendor also names an ontology layer as one of three platform components on which every catalog agent is composed, alongside Agent Builder and Observatory. An ontology is a maintained structure describing entities and their relationships. The platform's stated function is integrating thousands of disjointed legacy systems into a single source of truth, and agents are trained on the institution's own data under its own rules and compliance. Grounding on operational systems of record rather than only on an uploaded document corpus is the shape that matters here: an underwriting agent needs the current state of the core banking system, not a snapshot. Unified case files that aggregate and correlate evidence across source systems, the AML product's deliverable, are grounding output too. Zero Hallucination technology is a proprietary marketing name for a claim no system can make absolutely, so it is not counted here. The vendor's more careful current phrasing, "hallucination controls measured in production", is a governance claim rather than a grounding one.

FlowX documents agent output as durable, addressable state. A documentation page titled "Passing data between nodes" describes how outputs from subprocesses, workflows, AI agents and business rules land in process variables and how downstream nodes read them, so the state is named for agents specifically rather than inferred from a general data model. The state outlives a run in two ways. Within a process, variables persist for the life of the instance, and BPMN instances in this domain run for days or weeks: the platform documents updating process variables on active instances to resolve production issues without restarts, and migrating running instances between builds. Across processes, FlowX Database stores structured data across processes and apps, which is durable shared state any later agent can read. Knowledge Bases add a third surface, holding static documents and dynamic data feeds with documented create, append, replace, delete and edit metadata operations, so an agent's accumulated context is a maintained object rather than a transient one. The limit is precise: this is process state that agents read and write, not a named per agent memory primitive with retention or per user scoping, and nothing documents an agent recalling a prior conversation with a particular person. For a BPMN platform that is the coherent shape.

Full on product documentation. Approval gates can sit after AI steps as User Task nodes, so a reviewer sees and can correct the output before it feeds the next step, and low confidence results can tighten thresholds or be routed to manual review. A second gate covers the platform itself: agents propose workflow changes and builder agents implement them only after a designated operator approves. Observatory adds Guards that check content before it reaches users.

Full on both halves. The trust page states ISO 27001 certification, a completed SOC 2 Type I examination as of 17 June 2026 covering Security, Availability and Confidentiality, Type II in progress, and GDPR, with report and certificate details available under NDA. The documentation carries the control half: Keycloak and Microsoft Entra ID identity, role based access at organization, workspace and project level, project scoped runtime authorization, a dedicated Audit service, and a Personal Information Guard that redacts personal data before it reaches a model. Perimeter and residency facts are graded on deployment.

Full on the Observatory documentation. An SDK traces every agent, chain and tool call in real time with cost and latency analytics, drift detection and threshold alerts, and a policy engine and per app risk score sit on the same telemetry. Compliance maps EU AI Act, NIST AI RMF and ISO 42001 controls to the runtime with an exportable audit pack, and retention is configurable up to a seven year setting. These mappings govern the customer's own AI estate and are not read as an attestation of FlowX itself.

FlowX documents installation in the customer's own infrastructure. The documentation landing page carries a named path, "I need to deploy FlowX, install and configure FlowX in your infrastructure", and the 5.9 setup guides cover the FlowX Engine, Application Manager, Runtime Manager, Kafka authentication, Redis, ingress routing and authorization. That is an installation route offered to customers rather than a bespoke deployment the vendor performs. The architecture makes it credible rather than asserted. All backend services, more than twenty three of them, are containerized and deployed on Kubernetes, with Kafka for communication between services and a published data architecture page covering database to service mapping, storage types and sizing guidance. Sizing guidance in particular is something a vendor writes only for customers who run the software themselves. FlowX also publishes SaaS terms beside its license terms. For the buyers FlowX serves, this is the load bearing property. Banks such as its named clients National Bank of Canada, OTP and Banca Transilvania are unlikely to run mission critical lending on a multi tenant SaaS, and the premise of leaving legacy core banking untouched requires the platform to sit beside it. One limit: no region selection or managed cloud residency options are documented, so the grade rests on installation in the customer's infrastructure rather than on a residency menu.

Full. The documentation enumerates 246 predesigned agents across banking, insurance and logistics, each with its function and a deployment effort estimate, grouped into named multi agent stacks such as a nine agent mortgage underwriting stack and a seven agent fraud investigation stack. The vendor frames them as blueprints built from documented platform capabilities rather than shipped components, which is the precise version of the claim, and the marketing site carries the same catalog as a browsable surface.

Full. The customer configures model providers at the organization level, with bring your own key across OpenAI, Azure OpenAI, Mistral and any OpenAI compatible endpoint, and whitelists which models are available by capability. A default and fallback model is set per capability and per workspace type, and a workflow designer can override the model on an individual AI node. The buyer chooses, which is the Full bar on this axis. New provider additions reach SaaS first and self hosted deployments with the next LTS release family.

FlowX documents its developer surface as a first class route. The documentation landing page offers a named path, "I want to integrate APIs, use the SDKs (Angular, React, iOS, Android) or REST APIs", and the 5.9 SDK overview lists React, React Native, Angular, iOS and Android SDKs for embedding FlowX processes in client applications. API reference pages cover platform resources such as storage buckets and objects. The architecture page corroborates it. The platform runs 23 plus backend microservices, and client applications connect through an API gateway that handles OAuth2 token validation and request routing. A published gateway with a named auth standard is what makes the API usable by something other than the vendor's own front end. An MCP API reference for managing MCP servers and tools is also published, marked as internal paths under review. The documentation publishes an /llms.txt index of the complete documentation, which is unusually open for a vendor selling into banks. The Agent Builder itself is the product rather than an extensibility surface, so the grade rests on the SDKs and APIs.

Full. Evaluations attach a dataset of test cases with expected outputs to a specific AI node, including cases captured from real production runs, and score experiments with ten built in evaluators plus custom ones through a judge service that shows its reasoning per test case. Regression testing between agent versions is documented: each experiment freezes the node configuration, so a baseline run and a post change run can be compared evaluator by evaluator. The artifact under test is the customer's own agent.

Full on product documentation. FlowX documents a Browser Automation workflow node, available from release 5.13.0 on SaaS, that drives a real browser through web applications with no API from a task written in plain language. Outcomes are checked against the target site's recorded state rather than the agent's own report, sessions persist across workflow steps, and every run is logged. Self hosted customers receive the node with the next LTS release family.